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 hekkelman
PS: 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.
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d345021.6030...@cmbi.ru.nl