0

Here's the poop.

We are compiling the mysql++ 3rd party library on two different Linux deploments: Red Hat 5.8 and SuSE Sles10.

The compilation logic is exactly the same on the two systems. However, the file command on the Red Hat system indicates that the resulting library is a "Linux/i386 core file" while on SuSE it correctly shows as "ELF 32-bit LSB shared object"

>  cat /etc/issue
Welcome to SUSE Linux Enterprise Server 10 SP1 (i586) - Kernel \r (\l).

>  file Obj/libdbums.so 
Obj/libdbums.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped

>  cat /etc/issue
Red Hat Enterprise Linux Server release 5.8 (Tikanga)
Kernel \r on an \m

>  file Obj/libdbums.so
Obj/libdbums.so: Linux/i386 core file, not stripped

The linking is done as follows:

g++ -m32 -fPIC -shared -Wl,-soname -Wl,libdbums.so.1.0.0 -o Obj/libdbums.so \
<list of Obj/xyz.o files> \
-Wl,-rpath-link \
/usr/server/CommonLib/lib \
-L/usr/server/CommonLib/lib \
-lLogging \
-lboost_date_time \
-lumsxmlapi \
-lmysqlpp

Any idea on why this would happen? Other libraries compiled on the RedHat machine are correctly found to be "Elf 32-bit LSB shared objects" just not this library.

Oh, and the .so works. The applications that use libdbums.so work utilizing functionality from the library.

Some of you may be asking why does it matter, if it works, it works.

We found this to be a problem because the auto dependency detection logic for building RPMS will filter out any .so files that are not "Elf". We found that our SuSE RPMS installed fine because the RPMS correctly indicated they provided libdbums.so, but on RedHat it fails, because file shows libdbums.so as a not "ELF" and so doesn't include it in the provides list.

I know that I can manually add a provides clause for this one library, but I'd prefer to get to the root cause and simply have the library detected correctly. Which is to have it so the file command correctly classifies it as an ELF.

10/02/2013 12:14 JRR Edit

On a whim, I found that if I link with gcc instead of g++ it gets the ELF 32 file type.

John Rocha
  • 1,656
  • 3
  • 19
  • 30
  • Look for a file called "magic". It used to live in /etc/magic, but now I think it's in /usr/share/mime/magic or /usr/share/misc/magic - it controls how files are identified. – Paul Tomblin Oct 02 '13 at 19:12
  • Thanks for the info Paul, but this appears to be a reference file. The problem I'm having is trying to make the resulting .so file correctly categorized as an ELF. I think this would be some compiler/linker option. I'm not certain how the magic files will help me with this. Thanks. – John Rocha Oct 02 '13 at 19:17
  • 2
    My point is that differences between how the two systems recognize files would mean that the same file would look like ELF on one system and a core on the other, since both categorizations rely on specific magic bytes in specific locations. It's possible that the generated file has the magic bytes for core files as well as the magic bytes for ELF files, and one file/libmagic is looking at the core magic before the ELF magic. – Paul Tomblin Oct 02 '13 at 19:33
  • Ah! Thank Paul. That was interesting. I copied the RH .so to SuSE and the SuSE file command shows the RH.so as ELF, then I copied the SuSE .so to RH and RH file command shows the Suse.SO as ELF. So there I think its a combination of the .so along with the file command now. I'm leaning towards a gcc/g++ linker issue, since if I switch from g++ to gcc, on RH it appears correctly. – John Rocha Oct 02 '13 at 20:05

0 Answers0