Thanks for the detailed answer, I understand why passing -lc is a bad
idea now after reading your response and thinking on it.
I removed -Wl,--no-undefined from AM_LDFLAGS, and it worked perfectly.
Philip Guenther <mailto:guent...@gmail.com>
Wednesday, May 15, 2013 8:26 PM
OpenBSD does not, in general, support shared-library dependencies on
libc or libpthread. Doing so requires either
a) every library change is a flag day, with significant ordering
issues during the build, OR
b) symbol versioning hell.
This is from bitter experience. We tried it briefly and the ordering
issues broke builds and left build machines hosed until they had their
/usr/lib directories scrubbed from single-user mode. Bad Mojo.
As for symbol versioning, it's a nasty slope of backwards compat (==
bug compat) and attack surfaces that we do not have the desire to
provide, much less the time to do so. Note also that it would kill
all static-only platforms, as static linking doesn't support symbol
versioning.
With that background, it should perhaps make sense why the -lc option
is vanishing.
So, why does your link break? Because you're passing it the
-Wl,-z,defs option (using its GNU spelling, -Wl,--no-undefined). I
understand why you are doing that, but given the constraints of the
above, it ain't gonna work.
Philip Guenther
William Orr <mailto:w...@worrbase.com>
Wednesday, May 15, 2013 8:00 PM
Thanks for the quick response!
Even with the OpenBSD libtool, the problem persists. If I rerun the
command that it outputted with the -lc flag passed on the command
line, it works perfectly. Both libtools strip it out, as I discovered
in this mailing list post[1]. I'm not sure why I need to pass in -lc,
as I don't most other times when building software.
Here's the updated gist: https://gist.github.com/worr/5565142
Thanks so much for the help, I really appreciate it.
[1] http://lists.gnu.org/archive/html/bug-gnu-utils/2005-11/msg00010.html
Stuart Henderson <mailto:s...@spacehopper.org>
Wednesday, May 15, 2013 5:02 PM
try telling it to use /usr/bin/libtool instead of gnu libtool.
William Orr <mailto:w...@worrbase.com>
Wednesday, May 15, 2013 4:16 PM
Hello,
I'm having trouble building some software (out of ports) with libtool.
The libtool linking step always fails reporting that it cannot find
strchr or strlen when linking, depending on the component I'm
compiling. However, gcc finds all of the other functions from libs
(glib, gio, pcre, etc), just fine.
So far, I've tried manually adding a -L/usr/lib and -lc to LDFLAGS.
Compiling different components of the software yields similar errors.
The rev I'm using compiles fine on Linux (which means little).
I've spent a few days trying to figure out what's wrong, but I haven't
found anything.
The libtool that autotools ends up using is GNU's libtool v2.4.2 in
/usr/local/lib.
[ will on ponyexpress ] ( ~ ) % uname -a
OpenBSD ponyexpress.csh.rit.edu 5.3 GENERIC#50 i386
Here is the output of the build, as well as a test program that I
wrote with some output as well.
https://gist.github.com/worr/5565142
Any help or insight would be much appreciated; thanks!
Thanks,
William Orr
