Problems building with libtool

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Problems building with libtool

William Orr-2
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

Reply | Threaded
Open this post in threaded view
|

Re: Problems building with libtool

Stuart Henderson
On 2013-05-15, William Orr <[hidden email]> wrote:

> 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.

try telling it to use /usr/bin/libtool instead of gnu libtool.

Reply | Threaded
Open this post in threaded view
|

Re: Problems building with libtool

William Orr-2
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:[hidden email]>
> Wednesday, May 15, 2013 5:02 PM
>
> try telling it to use /usr/bin/libtool instead of gnu libtool.
>
> William Orr <mailto:[hidden email]>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: Problems building with libtool

Philip Guenther-2
On Wed, May 15, 2013 at 5:00 PM, William Orr <[hidden email]> wrote:
> 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.

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

Reply | Threaded
Open this post in threaded view
|

Re: Problems building with libtool

William Orr-2
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:[hidden email]>
> 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:[hidden email]>
> 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:[hidden email]>
> Wednesday, May 15, 2013 5:02 PM
>
> try telling it to use /usr/bin/libtool instead of gnu libtool.
>
> William Orr <mailto:[hidden email]>
> 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