On 28.12.2010 13:11, Frank B. Brokken wrote:
Dear Matthias Klose, you wrote:
Package: bobcat
Version: 2.10.01-2
Severity: normal
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu natty
User: debian-...@lists.debian.org
Usertags: ld-as-needed
with ld --as-needed fails to build with:
gcc -shared -Wl,-z,def,-soname,libbobcat.so.2 -lmilter
-L/usr/lib/libmilter -lX11 -lssl -lreadline -o
tmp/lib/libbobcat.so.2.10.02 */os/*.o
^^^ the mistake is that shared libraries are placed before the
object files on the command line.
^^^ this is the think to fix
chmod -x libbobcat.so.2.10.02
ln -sf libbobcat.so.2.10.02 libbobcat.so.2
ln -sf libbobcat.so.2 libbobcat.so
./build lcgen
and the fails later with ...
g++ --std=c++0x -isystem tmp -o tmp/bin/bobcatlcgen lc/lcgen/main.cc
lc/lcgen/o/* -lbobcat -Ltmp/lib/
tmp/lib//libbobcat.so: undefined reference to `OpenSSL_add_all_digests'
tmp/lib//libbobcat.so: undefined reference to `history_length'
tmp/lib//libbobcat.so: undefined reference to `BN_init'
tmp/lib//libbobcat.so: undefined reference to `BN_num_bits'
tmp/lib//libbobcat.so: undefined reference to `BN_exp'
[...]
attached is what I would suspect would fix the problem but it
doesn't. any further ideas?
I'm not sure why you're using ld --as-needed. When I add -Xlinker --as-needed
to the library construction phase lcgen indeed fails to link.
hmm, no, it should not fail. how does it for you?
When adding the
libraries defining the missing entries (e.g., -lssl) to the lcgen link command
the lcgen program links fine:
g++ --std=c++0x -isystem tmp -o tmp/bin/bobcatlcgen lc/lcgen/main.cc
lc/lcgen/o/* -lssl -lbobcat -Ltmp/lib/
yes, this would be only a workaround.
I guess you will experience the same problem with other programs depending on
bobcat.
I don't know why linking against ssl is required: lcgen doesn't use the ssl
lib, and objdump processing the generated lcgen program doesn't show any ssl
references.
right, but the shared library uses ssl symbols. You do link with it, but the
dependency isn't picked up, because the .o files appear *after* the libraries
which are used to resolve the symbols. And this fails with traditional linker
behaviour too (however not GNU ld without --as-needed), so you may see this kind
of failure on non Linux systems too.
But it does want to link against, e.g., libreadline, libX11 and
libssl, which are required by bobcat. Something to figure out.... What you
want/would expect is that bobcat's additional libraries are only needed if
there are external references to code from those libraries. Which isn't the
case with lcgen.
So, in short:
- if don't know why you want to use --as-needed, if you don't use it the
linking proceeds fine, and although the executable doesn't need symbols from
these libraries the executable links against the dynamic libs required by
bobcat.
- right now I have no other solution but to avoid --as-needed. I'll keep
your problem in mind and if/when I have a solution I'll let you know.
Thanks for bringing this problem to my attention. Once I have a solution
(other than: don't use --as-needed) I'll let you know.
well, I think I attached a patch what is the correct solution, but the somewhat
unfamiliar build system doesn't like that patch in this place, or it requires
another similiar one which I am still missing.
Matthias
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
