Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build the MariaODBC driver as a module #38

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

AdamMajer
Copy link
Contributor

When built as a module instead of a shared library, the library is
no longer exporting an unversioned soname. Since this is library is
only meant to be dynamically loaded by the ODBC manager, the soname
is unused anyway.

objdump -x libmaodbc.so | grep SONAME

@lawrinn
Copy link
Collaborator

lawrinn commented Oct 12, 2020

Some people do link against odbc drivers directly to remove overhead introduced by a DM. Thus I don't want to remove SONAME export and inclined to reject this PR.

@AdamMajer
Copy link
Contributor Author

Hmmm, my instinct tells me that soname-less libraries have implicit "soname" equal to their filename. The soname is only used to write a different filename into the executable header than the filename from the linker. And I've just verified this. For example, a very simply test that uses a symbol from the library (wrongly, of course),

extern void SQLTables();

int main()
{
SQLTables();
return 0;
}

Will link with the library without explicit soname.

objdump -x a.out | grep NEEDED
  NEEDED               libmaodbc.so
  NEEDED               libc.so.6

So my commit message is incorrect. The explicit soname set to the filename (unversioned) is superfluous and unnecessary in all use-cases. You can also see this in the manpage of ld(1)

   -h name
   -soname=name
       When creating an ELF shared object, set the internal DT_SONAME field to the specified name.  
       When an executable is linked with a shared object which has a DT_SONAME field,
       then when the executable is run the dynamic linker will attempt to load the shared object specified 
       by the DT_SONAME field rather than the using the file name given to the linker.

@AdamMajer
Copy link
Contributor Author

I've corrected the commit message. For our packaging, the presence of a soname breaks some automatic packaging checks.

When built as a module instead of a shared library, the library is
no longer exporting an unversioned soname. Building the library with
an unversioned soname is superfluous as the linker will use the
filename for linking. The soname is only necessary when the library
linked during build has different filename than the library to be
used at runtime.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants