Bug 62640

Summary: libtool invocations should use --tag=CC
Product: APR Reporter: Michael Osipov <michaelo>
Component: APRAssignee: Apache Portable Runtime bugs mailinglist <bugs>
Status: RESOLVED FIXED    
Severity: major CC: michaelo
Priority: P2    
Version: 1.6.3   
Target Milestone: ---   
Hardware: All   
OS: HP-UX   
Bug Depends on:    
Bug Blocks: 62641    

Description Michael Osipov 2018-08-20 15:19:32 UTC 
This issue is pretty much like https://bz.apache.org/bugzilla/show_bug.cgi?id=47691.

tcnative relies on libtool from libapr. Though, all libtool invocations miss '--tag=CC'. If you use libtool on a different environment libtcnative is not properly linked against libapr. If you use an external libtool it complains that tag is missing.

> $ uname -a
> HP-UX blnn724x B.11.31 U ia64 HP-UX
> osipovmi@blnn724x:/tmp/tomcat-native-1.2.17-src/native []
> $ find . -name \*.so
> ./.libs/libtcnative-1.so
> osipovmi@blnn724x:/tmp/tomcat-native-1.2.17-src/native []
> $ ldd ./.libs/libtcnative-1.so
> 
> ./.libs/libtcnative-1.so:
>         libssl.so.1.0.0 =>      /usr/lib/hpux32/libssl.so.1.0.0
>         libcrypto.so.1.0.0 =>   /usr/lib/hpux32/libcrypto.so.1.0.0
>         Unable to find library 'libapr.so.6'.

Now lets reconfigure with ./configure LIBTOOL="libtool" instead the one from apr:
> libtool --silent --mode=compile aCC -Ae -g -mt   -DHAVE_CONFIG_H  -DHPUX11 -D_REENTRANT -D_HPUX_SOURCE -D_LARGEFILE64_SOURCE   -g -DHAVE_OPENSSL   -I./include -I/opt/java8/include -I/opt/java8/include/hpux -I/opt/openssl/include  -I/opt/apr/include   -o src/lock.lo -c src/lock.c && touch src/lock.lo
> libtool: compile: unable to infer tagged configuration
> libtool: compile: unable to infer tagged configuration
> libtool: compile: unable to infer tagged configuration
> libtool: compile: unable to infer tagged configuration
> libtool: compile: unable to infer tagged configuration
> libtool: compile: unable to infer tagged configuration
> libtool: compile: unable to infer tagged configuration
> libtool: compile: unable to infer tagged configuration
> libtool:   error: specify a tag with '--tag'
> /tmp/tomcat-native-1.2.17-src/native/build/rules.mk:206: recipe for target 'src/lock.lo' failed
> gmake[1]: *** [src/lock.lo] Error 1
> gmake[1]: *** Waiting for unfinished jobs....
> libtool:   error: specify a tag with '--tag'
> libtool:   error: specify a tag with '--tag'
> /tmp/tomcat-native-1.2.17-src/native/build/rules.mk:206: recipe for target 'src/address.lo' failed
> gmake[1]: *** [src/address.lo] Error 1
> /tmp/tomcat-native-1.2.17-src/native/build/rules.mk:206: recipe for target 'src/dir.lo' failed
> gmake[1]: *** [src/dir.lo] Error 1
> libtool:   error: specify a tag with '--tag'
> /tmp/tomcat-native-1.2.17-src/native/build/rules.mk:206: recipe for target 'src/file.lo' failed
> gmake[1]: *** [src/file.lo] Error 1
> libtool:   error: specify a tag with '--tag'
> libtool:   error: specify a tag with '--tag'
> /tmp/tomcat-native-1.2.17-src/native/build/rules.mk:206: recipe for target 'src/info.lo' failed
> gmake[1]: *** [src/info.lo] Error 1
> /tmp/tomcat-native-1.2.17-src/native/build/rules.mk:206: recipe for target 'src/error.lo' failed
> gmake[1]: *** [src/error.lo] Error 1
> libtool:   error: specify a tag with '--tag'
> libtool:   error: specify a tag with '--tag'
> /tmp/tomcat-native-1.2.17-src/native/build/rules.mk:206: recipe for target 'src/bb.lo' failed
> gmake[1]: *** [src/bb.lo] Error 1
> /tmp/tomcat-native-1.2.17-src/native/build/rules.mk:206: recipe for target 'src/jnilib.lo' failed
> gmake[1]: *** [src/jnilib.lo] Error 1
> gmake[1]: Leaving directory '/tmp/tomcat-native-1.2.17-src/native'
> /tmp/tomcat-native-1.2.17-src/native/build/rules.mk:118: recipe for target 'all-recursive' failed
> gmake: *** [all-recursive] Error 1
Comment 1 Michael Osipov 2018-08-20 15:34:31 UTC 
Here is a decent patch: https://github.com/apache/apr/pull/12
Comment 2 William A. Rowe Jr. 2018-08-30 13:52:23 UTC 
Repeating my question from the github pull request;

I'm confused by the docs link you provided;

>>Is it really correct to use the CC tag also for --mode=link?
> As far as I understood the documentation -- yes. We are requesting libtool to link C objects with CC (the compiler). See here;
> https://www.gnu.org/software/libtool/manual/html_node/Tags.html

"If it can’t infer a tag, then it defaults to the configuration for the C language."

So, --tag=CC is default behavior already. I'm puzzled precisely what problem this solves?
Comment 3 Rainer Jung 2018-08-30 14:09:19 UTC 
As far as I remember from having similar troubls long ago, the libtool script runs into the "unable to infer tagged configuration" error, when you compile with compiler or CC which is not a leading substring of what is set as "CC" (or "LTCC"?) in the libtool script itself.

So in some sense libtool, when created, records compiler info and refuses to compile if you change the compiler later in an incompatible way (adding flags at the end of CC would be compatible).

What I do not know, if custom CC will overwrite libtool builtin CC when you add the --tag flag.

To get the piture clear, we would need to know, what the definition of CC and LTCC is in the various libtool scripts involved (platform one, APR one), what CC was used to compile APR and what CC should be used to compile the artefact that fails compilation.
Comment 4 Michael Osipov 2018-08-30 19:17:41 UTC 
(In reply to Rainer Jung from comment #3)
> As far as I remember from having similar troubls long ago, the libtool
> script runs into the "unable to infer tagged configuration" error, when you
> compile with compiler or CC which is not a leading substring of what is set
> as "CC" (or "LTCC"?) in the libtool script itself.
> 
> So in some sense libtool, when created, records compiler info and refuses to
> compile if you change the compiler later in an incompatible way (adding
> flags at the end of CC would be compatible).
> 
> What I do not know, if custom CC will overwrite libtool builtin CC when you
> add the --tag flag.
> 
> To get the piture clear, we would need to know, what the definition of CC
> and LTCC is in the various libtool scripts involved (platform one, APR one),
> what CC was used to compile APR and what CC should be used to compile the
> artefact that fails compilation.

This is actually the issue I am expriencing on HP-UX with aCC.

The libtool generated differs from the libtool on my system. Especially 'available_tags' are empty.

LTCC is not set by me, but CC=/opt/aCC/bin/aCC. The CC assumed at time of packaging libapr is a different one used by me and this does not work.

I can provide the output of the failures on Monday as soon as I get access to the HP-UX servers at work.
Comment 5 Michael Osipov 2018-08-30 19:19:13 UTC 
(In reply to William A. Rowe Jr. from comment #2)
> Repeating my question from the github pull request;
> 
> I'm confused by the docs link you provided;
> 
> >>Is it really correct to use the CC tag also for --mode=link?
> > As far as I understood the documentation -- yes. We are requesting libtool to link C objects with CC (the compiler). See here;
> > https://www.gnu.org/software/libtool/manual/html_node/Tags.html
> 
> "If it can’t infer a tag, then it defaults to the configuration for the C
> language."
> 
> So, --tag=CC is default behavior already. I'm puzzled precisely what problem
> this solves?

The default configuration applies to the config at the host system build the libapr tarball which does not match my configuration, different OS, CPU arch and compiler. It is not portable if you don't provide the tag for the language.
Comment 6 Michael Osipov 2019-01-09 13:33:41 UTC 
Guys, can we settle this somehow? I don't see any harm by this. I have tested on three OSes. I don't really want to maintain a fork of a portable library (sic).
Comment 7 Graham Leggett 2019-08-17 10:11:51 UTC 
Committed revision 1865343.

I tested this on MacOS Mojave and Fedora, and both builds worked fine.

I'm assuming both apr v1.7 and apr-util 1.7 will need backports, can you take a look?
Comment 8 Michael Osipov 2019-08-18 10:27:29 UTC 
Do you want me to provide a PR for 1.7.x? If yes, no issue. I will provide one.

If 1.6.x is still supported, I will provide it too.
Comment 9 Michael Osipov 2019-08-19 10:55:44 UTC 
Created two backport PRs:

Works with APR 1.7.x, APR-Util 1.6.x, Tomcat Native trunk:

$ ldd libaprutil.so.6.2 libapr.so.7.0 libtcnative-1.so.2.23

libaprutil.so.6.2:
        libapr.so.7 =>  /net/home/osipovmi/opt/lib/hpux32/libapr.so.7
        librt.so.1 =>   /usr/lib/hpux32/librt.so.1
        libm.so.1 =>    /usr/lib/hpux32/libm.so.1
        libpthread.so.1 =>      /usr/lib/hpux32/libpthread.so.1
        libc.so.1 =>    /usr/lib/hpux32/libc.so.1
        librt.so.1 =>   /usr/lib/hpux32/librt.so.1
        libm.so.1 =>    /usr/lib/hpux32/libm.so.1
        libpthread.so.1 =>      /usr/lib/hpux32/libpthread.so.1
        libc.so.1 =>    /usr/lib/hpux32/libc.so.1
        libdl.so.1 =>   /usr/lib/hpux32/libdl.so.1

libapr.so.7.0:
        librt.so.1 =>   /usr/lib/hpux32/librt.so.1
        libm.so.1 =>    /usr/lib/hpux32/libm.so.1
        libpthread.so.1 =>      /usr/lib/hpux32/libpthread.so.1
        libc.so.1 =>    /usr/lib/hpux32/libc.so.1
        libdl.so.1 =>   /usr/lib/hpux32/libdl.so.1

libtcnative-1.so.2.23:
        libssl.so.1.0.0 =>      /usr/lib/hpux32/libssl.so.1.0.0
        libcrypto.so.1.0.0 =>   /usr/lib/hpux32/libcrypto.so.1.0.0
        libapr.so.7 =>  /net/home/osipovmi/opt/lib/hpux32/libapr.so.7
        librt.so.1 =>   /usr/lib/hpux32/librt.so.1
        libm.so.1 =>    /usr/lib/hpux32/libm.so.1
        libpthread.so.1 =>      /usr/lib/hpux32/libpthread.so.1
        libc.so.1 =>    /usr/lib/hpux32/libc.so.1
        libdl.so.1 =>   /usr/lib/hpux32/libdl.so.1
        librt.so.1 =>   /usr/lib/hpux32/librt.so.1
        libm.so.1 =>    /usr/lib/hpux32/libm.so.1
        libpthread.so.1 =>      /usr/lib/hpux32/libpthread.so.1
        libc.so.1 =>    /usr/lib/hpux32/libc.so.1
        libdl.so.1 =>   /usr/lib/hpux32/libdl.so.1

Works with APR 1.6.x, APR-Util 1.6.x, Tomcat Native trunk:

$ ldd libaprutil.so.6.2 libapr.so.6.6 libtcnative-1.so.2.23

libaprutil.so.6.2:
        libapr.so.6 =>  /net/home/osipovmi/opt/lib/hpux32/libapr.so.6
        librt.so.1 =>   /usr/lib/hpux32/librt.so.1
        libm.so.1 =>    /usr/lib/hpux32/libm.so.1
        libc.so.1 =>    /usr/lib/hpux32/libc.so.1
        librt.so.1 =>   /usr/lib/hpux32/librt.so.1
        libm.so.1 =>    /usr/lib/hpux32/libm.so.1
        libpthread.so.1 =>      /usr/lib/hpux32/libpthread.so.1
        libc.so.1 =>    /usr/lib/hpux32/libc.so.1
        libdl.so.1 =>   /usr/lib/hpux32/libdl.so.1

libapr.so.6.6:
        librt.so.1 =>   /usr/lib/hpux32/librt.so.1
        libm.so.1 =>    /usr/lib/hpux32/libm.so.1
        libpthread.so.1 =>      /usr/lib/hpux32/libpthread.so.1
        libc.so.1 =>    /usr/lib/hpux32/libc.so.1
        libdl.so.1 =>   /usr/lib/hpux32/libdl.so.1

libtcnative-1.so.2.23:
        libssl.so.1.0.0 =>      /usr/lib/hpux32/libssl.so.1.0.0
        libcrypto.so.1.0.0 =>   /usr/lib/hpux32/libcrypto.so.1.0.0
        libapr.so.6 =>  /net/home/osipovmi/opt/lib/hpux32/libapr.so.6
        librt.so.1 =>   /usr/lib/hpux32/librt.so.1
        libm.so.1 =>    /usr/lib/hpux32/libm.so.1
        libpthread.so.1 =>      /usr/lib/hpux32/libpthread.so.1
        libc.so.1 =>    /usr/lib/hpux32/libc.so.1
        libdl.so.1 =>   /usr/lib/hpux32/libdl.so.1
        librt.so.1 =>   /usr/lib/hpux32/librt.so.1
        libm.so.1 =>    /usr/lib/hpux32/libm.so.1
        libpthread.so.1 =>      /usr/lib/hpux32/libpthread.so.1
        libc.so.1 =>    /usr/lib/hpux32/libc.so.1
        libdl.so.1 =>   /usr/lib/hpux32/libdl.so.1


Looks good to me now!
Comment 10 Michael Osipov 2019-08-21 19:58:47 UTC 
All remaining PRs have been delivered.
Comment 11 Graham Leggett 2019-08-23 22:31:27 UTC 
Backported to apr 1.7 in 1865793 and apr-util 1.7 in 1865794.
Comment 12 Michael Osipov 2019-08-24 07:14:02 UTC 
(In reply to Graham Leggett from comment #11)
> Backported to apr 1.7 in 1865793 and apr-util 1.7 in 1865794.

Thanks,

why not 1.6.x for both? PRs are there.
Comment 13 William A. Rowe Jr. 2019-09-06 19:18:32 UTC 
Largely because there is little likelihood of a revised 1.6.x apr-util,
and we won't release another 1.6.x apr now that 1.7.0 is out in the wild.
Comment 14 Michael Osipov 2019-09-07 09:08:31 UTC 
(In reply to William A. Rowe Jr. from comment #13)
> Largely because there is little likelihood of a revised 1.6.x apr-util,
> and we won't release another 1.6.x apr now that 1.7.0 is out in the wild.

OK, this means that I need 1.7.x fixed on HP-UX because does compile, regardless if this change. Something has been broken around thread muteces. I need to investigate.