Op 17-01-11 12:39, Niels Thykier schreef:
Today I found out something is still wrong, when I tried to link to the libzeep.a file the linker was not able to find the symbols. Trying to get rid of the lintian error: 'unstripped-binary-or-object
Libraries are always a heap of fun! I have not had this particular problem before, though I checked lintian and it checks for the following. If the output of "file library" contains "not stripped". If it does not match that, Lintian further checks for the presence of some unneeded sections (particularly ".comment" and ".note").
Well, 'ld -r' generates an ELF file and you cannot strip this file completely, since you would lose the symbol table needed to link it. And so the use of the 'file' command by lintian is not correct in this case (IMHO of course), it should be a bit smarter than that.
A workaround is to create a temporary .o file with 'ld -r -o libxxx.o ...' and then use 'ar rcs libxxx.a libxxx.o'. The resulting file is an archive file, slightly larger than the .a created directly by ld. Including this ar file removes the lintian error message.
However, since using libzeep in an application introduces a dependency on boost, you would have to link against the correct boost static libraries as well, the C++ ABI is fragile and using the wrong boost libraries is a certain way to difficult to track down bugs. And when you know how to link statically properly--and really want to do this--you probably won't be using a -dev package anyway. So I decided to drop the .a file from the package.
I uploaded a new package. Best regards, -maarten hekkelmanPS: There is a reason to use 'ld -r' instead of 'ar rcs *.o': when building large C++ application, linking time can be very long and using libraries that are linked using 'ld -r' reduce this time considerably. Of course there are more advantages.