Re: svn commit: r384715 - /apr/apr/trunk/test/Makefile.in

[Joe Orton <jo...@redhat.com>]

On Fri, Mar 10, 2006 at 06:40:53AM -0000, William Rowe wrote:
> Author: wrowe
> Date: Thu Mar  9 22:40:52 2006
> New Revision: 384715
> 
> URL: http://svn.apache.org/viewcvs?rev=384715&view=rev
> Log:
> 
>   Throw away a horrible change; each time we layer on more garbage to libtool
>   et al we've caused apr to fail in more peculiar ways on more platforms.
> 
>   In this case, let libtool do exactly what we want, which is to resolve the
>   build-path flavor of libapr-1.la and test exactly what we've most recently
>   changed (and, for that matter, to have make check function whatsoever before
>   the library has been installed.)

Without -no-install I was seeing spurious test failures on some 
platforms, because all the test programs (which get exec'ed by APR; 
oc_child) end up as libtool wrapper shell scripts.

What failure are you seeing?

joe

Re: svn commit: r384715 - /apr/apr/trunk/test/Makefile.in

[Joe Orton <jo...@redhat.com>]

On Fri, Mar 10, 2006 at 02:12:12AM -0600, William Rowe wrote:
> Joe Orton wrote:
> >On Fri, Mar 10, 2006 at 01:59:50AM -0600, William Rowe wrote:
> >>Uhmmm.... without this change, the tools are linked to the install path
> >>of the apr library, and they don't load the version just compiled into
> >>the .libs/ directory - causing problems with commits like your 
> >>optimization
> >>from this morning.
> >
> >On what platform, using what version of libtool?  That's exactly the 
> >opposite of what -no-install should do (and does, and always has, for 
> >me).
> 
> Stock flavor 1.5 installed on OS/X 10.3.
> 
> The -no-install flag appears to be incompatible with the fact that we built
> the libapr-1.dylib as -rpath, both the .la flavors in apr/ and apr/.libs/
> (a symlink) abspath the linkage location to the system path, ergo any linked
> binary to those .la's are similarly hard-pathed to the system path of the
> libraries' final target location.

With no sane linker will you get hard-coded paths to the installed 
library, but I remember hearing about other cases where the OS X linker 
cannot be made to do the right thing (I think it bites SVN in a similar 
way).

But the rest of us need not suffer, I'll add a configure check for this.  
Without -no-install you also cannot just "gdb ./testall" which is a 
major pain.

Please revert the change on 1.2.x at least, it's a regression.

joe

Re: svn commit: r384715 - /apr/apr/trunk/test/Makefile.in

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Joe Orton wrote:
> On Fri, Mar 10, 2006 at 01:59:50AM -0600, William Rowe wrote:
> 
>>Joe Orton wrote:
>>
>>>Without -no-install I was seeing spurious test failures on some 
>>>platforms, because all the test programs (which get exec'ed by APR; 
>>>oc_child) end up as libtool wrapper shell scripts.
>>>
>>>What failure are you seeing?
>>
>>Uhmmm.... without this change, the tools are linked to the install path
>>of the apr library, and they don't load the version just compiled into
>>the .libs/ directory - causing problems with commits like your optimization
>>from this morning.
> 
> 
> On what platform, using what version of libtool?  That's exactly the 
> opposite of what -no-install should do (and does, and always has, for 
> me).

Stock flavor 1.5 installed on OS/X 10.3.

The -no-install flag appears to be incompatible with the fact that we built
the libapr-1.dylib as -rpath, both the .la flavors in apr/ and apr/.libs/
(a symlink) abspath the linkage location to the system path, ergo any linked
binary to those .la's are similarly hard-pathed to the system path of the
libraries' final target location.

Re: svn commit: r384715 - /apr/apr/trunk/test/Makefile.in

[Joe Orton <jo...@redhat.com>]

On Fri, Mar 10, 2006 at 01:59:50AM -0600, William Rowe wrote:
> Joe Orton wrote:
> >
> >Without -no-install I was seeing spurious test failures on some 
> >platforms, because all the test programs (which get exec'ed by APR; 
> >oc_child) end up as libtool wrapper shell scripts.
> >
> >What failure are you seeing?
> 
> Uhmmm.... without this change, the tools are linked to the install path
> of the apr library, and they don't load the version just compiled into
> the .libs/ directory - causing problems with commits like your optimization
> from this morning.

On what platform, using what version of libtool?  That's exactly the 
opposite of what -no-install should do (and does, and always has, for 
me).

joe

Re: svn commit: r384715 - /apr/apr/trunk/test/Makefile.in

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Joe Orton wrote:
> 
> Without -no-install I was seeing spurious test failures on some 
> platforms, because all the test programs (which get exec'ed by APR; 
> oc_child) end up as libtool wrapper shell scripts.
> 
> What failure are you seeing?

Uhmmm.... without this change, the tools are linked to the install path
of the apr library, and they don't load the version just compiled into
the .libs/ directory - causing problems with commits like your optimization
from this morning.

In this particular case, libtool should do just what libtool does.

Now, we can talk about compiling a specific module like oc_child as a raw
binary, in -theory- libtool should set up the envvars to search for the
shared .libs/ location and anything that the app then invokes should load
correctly.  So if you would like to reintroduce this hack just for the
sub-children then we should be ok.

Other alternative, system() them instead of exec()ing them?

Bill