Statically Linked Shared Object? or a Corrupt File

statically linked shared object? Or a corrupt file?

Am I safe to assume this .so is botched

Yes, a .so file without a .dynamic section is almost certainly botched.

Did someone do an ASCII ftp transfer on it?

Statically linked application - invalid or corrupt dll

"Static Linking" is the process of including the code in your application. By nature, a DLL is a dynamic link library and therefore no, including the DLL in the directory of your application is not static linking - it remains dynamic. The reason for placing it in the directory of the application is so that the application can find it without the need for install.

I don't suppose it is the DLL that is "corrupt" - I suspect you are attempting to static link the DLL into the application which cannot happen. You need instead to include the correct .lib file, whatever that is, in the additional libraries to link with and ensure that the lib file you link with is not the DLL exports package for wininet.dll

Can a dynamically linked library override a static one?

So how come can nokogiri access libxml2.so's variables?

This is by design (and due to the fact that nokogiri was built incorrectly).

UNIX shared libraries are designed to emulate archive libraries. This means that the first ELF image to export a given symbol wins (there are some complications for libraries linked with -Bstatic flag, but we'll ignore them for now).

Does that mean that loading libxml2.so overrides any statically linked versions?

Yes, if statically linked version is also exported and calls to it go though PLT.

Can that happen in the middle of code execution?

With lazy symbol resolution (which is default, except when LD_BIND_NOW or -z now are in effect) it will always happen in the middle of code execution.

Now, the problem is that if nokogiri links in a static copy of libxml.a, it should hide that fact by localizing that copy within itself and not exporting any of its symbols. That would prevent end users from having to deal with symbol conflicts.

Your best bet is to either build your own nokogiri compiling and linking it against the same version of libxml, or to contact nokogiri maintainers and ask them to fix their builds.

Proper way to link a static library using GCC

Thanks for the replies! Turns out the problem was due to link order. Apparently, if you use a library which in turn has other library dependencies, those other dependencies must be listed after the library, not before as I had been doing. Learned something new!

When to use dynamic vs. static libraries

Static libraries increase the size of the code in your binary. They're always loaded and whatever version of the code you compiled with is the version of the code that will run.

Dynamic libraries are stored and versioned separately. It's possible for a version of the dynamic library to be loaded that wasn't the original one that shipped with your code if the update is considered binary compatible with the original version.

Additionally dynamic libraries aren't necessarily loaded -- they're usually loaded when first called -- and can be shared among components that use the same library (multiple data loads, one code load).

Dynamic libraries were considered to be the better approach most of the time, but originally they had a major flaw (google DLL hell), which has all but been eliminated by more recent Windows OSes (Windows XP in particular).

Linking a MinGW library to a MSVC app with a C interface

I figured out what works for me, so I'll share.

I was not able to link a static library between compilers as I originally attempted. My understanding is that the extra info kept in the lib to allow link-time code generation is compiler-specific. Brecht Sanders's answer outlines a few possible reasons why the code wouldn't be compatible.

I was, however, able to link to a shared library, with a few extra steps.

Using the same suite (see the question), I compiled as shared and got libopenal.dll, libopenal.dll.a, and libopenal.def. In my case, the .def file was generated by the suite. Accoding to this answer, you can generate a .def file with gcc using:

gcc -shared -o your_dll.dll your_dll_src.c -Wl,--output-def,your_dll.def

Trying to link to libopenal.dll.a still gave me errors (I don't know exactly why, and I already discarded the logs.) What I did instead was generate a .lib file from the .def file. In Visual Studio's built-in terminal:

lib /machine:x64 /def:libopenal.def

This generated a libopenal.lib file in the working directory. Linking to this file worked perfectly, and I was able to successfully load the dll at runtime.

I've tested this same method with many other MinGW-compiled libraries from the suite, including libavformat, libavcodec, libavutil, libavdevice, swresample, and swscale, and thus far all of them have worked.

Kind of convoluted, but it seems to work well for me, so I hope this helps anyone else with the same problem.

---

Related Topics