You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@attglobal.net> on 2002/04/10 14:07:35 UTC

an old Darwin issue... what is the solution?

I was testing the patch you mentioned and ran into an old problem...
I see myself and Pier asking about this very problem last year
(August) but I can't find the solution anywhere.

If I start httpd via the libtool shell script (./httpd from httpd-2.0
directory) it starts fine.  If I start httpd via apachectl it fails
with this error message:

[localhost:~/apache/httpd-2.0] trawick%
/Users/trawick/apacheinst/bin/apachectl start
dyld: /Users/trawick/apacheinst/bin/httpd can't open library: .libs/libaprutil.dylib  (No such file or directory, errno = 2)
/Users/trawick/apacheinst/bin/apachectl start: httpd could not be started

Any clues?  glibtoolize is in PATH and the easy patch for glibtool
seems to be in the right place:

[localhost:~/apache/httpd-2.0] trawick% diff
/usr/share/libtool/ltconfig.bak /usr/share/libtool/ltconfig
1375c1375,1376
<     allow_undefined_flag='-undefined warning'
---
> # hack on next line is from Sander Temme
>     allow_undefined_flag='-undefined suppress -flat_namespace'

I have 10.1.3 and the December developer tools package.

Thanks for any hints (I'll doc this for our users as well).
-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Re: an old Darwin issue... what is the solution?

Posted by Pier Fumagalli <pi...@betaversion.org>.
"Jeff Trawick" <tr...@attglobal.net> wrote:

> Pier Fumagalli <pi...@betaversion.org> writes:
> 
>> "Jeff Trawick" <tr...@attglobal.net> wrote:
> 
>>> Pier's solution results in a cleaner build (a bunch of bogus
>>> basename invocations went away).  Neither version of libtool gets the
>>> library path into httpd for some reason (Darwin limitation?).
>> 
>> ???? That's odd... With my most recent build:
> 
> I was apparently misinterpreting a symptom :)  My
> understanding/experience was that I had to set DYLD_LIBRARY_PATH to
> get the libraries found from the non-default location.  I figured that
> was because the executable din't have the right search path built in.
> But if the path is in httpd as you show, that shouldn't be the case.
> I'll try again when I get a moment.

Nah, you don't need DYLD_LIBRARY_PATH configured... The Mach-O library
structure is very well done, once you get around and actually understand how
it works, you can just basically build anything you like and forget about
broken libs dependancies...

The only problem is doing it right, check out some of my patches on my home
page for the packages: for BerkeleyDB I have to re-link the libraries at the
end of the process because they don't get built right with their makefiles,
but then they work like a breeze anywhere you want to put them...

You should only need DYLD_LIBRARY_PATH when you linked against a library
which was in one place, and have been moved elsewhere after you built...

>>> *other than wasting a fair amount of time because APR configure bombs
>>> when I use --enable-mods-shared="foo1 foo2 foo3 foo4"
>>> 
>>> Perhaps the logic to build the command-line for the APR sub-configure
>>> is busted on Darwin...  more research required :(
>> 
>> Hmm... Can you give me some more info? What's wrong with it?
> 
> Here's an example symptom:
> 
> ------------cut here------------
> trawick@localhost:~/apache/httpd-2.0% rm *cache
> trawick@localhost:~/apache/httpd-2.0% ./configure --prefix=/tmp/gobble
> --enable-mods-shared="autoindex dir"
> creating cache ./config.cache
> checking for chosen layout... Apache
> checking host system type... powerpc-apple-darwin5.3
> checking target system type... powerpc-apple-darwin5.3
> checking build system type... powerpc-apple-darwin5.3
> 
> Configuring Apache Portable Runtime library ...
> updating cache ./config.cache
> configuring package in srclib/apr now
> loading cache /Users/trawick/apache/httpd-2.0/./config.cache
> checking host system type... Invalid configuration `dir': machine
> `dir' not recognized
> 
> checking target system type... Invalid configuration `dir': machine
> `dir' not recognized
> 
> checking build system type... Invalid configuration `dir': machine
> `dir' not recognized
> 
> Configuring APR library
> ....
> -------cut here--------

Freaky ! :) Gotcha... It's an error in line 82 of
srclib/apr/build/apr_common.m4... Debugging it it comes out as:

/Users/pier/Desktop/httpd-2.0/srclib/apr/configure --prefix=/tmp/gobble
'--enable-mods-shared=autoindex dir' --cache-file=/dev/null
--srcdir=/Users/pier/Desktop/httpd-2.0/srclib/apr  --prefix=/tmp/gobble
--exec-prefix=${prefix} --libdir=${exec_prefix}/lib
--includedir=${prefix}/include --bindir=${exec_prefix}/bin
--datadir=${prefix} --with-installbuilddir=${datadir}/build

You see how --enable-mods-shared=autoindex dir is "quoted"? Well, the
problem is that that sucker is not expanded by a shell (DOH), so the two
parameters are read as "'--enable...." and "dir'"...

Patch to make it work:

cvs server: Diffing .
Index: apr_common.m4
===================================================================
RCS file: /home/cvspublic/apr/build/apr_common.m4,v
retrieving revision 1.29
diff -U3 -r1.29 apr_common.m4
--- apr_common.m4       23 Mar 2002 16:18:35 -0000      1.29
+++ apr_common.m4       11 Apr 2002 21:26:34 -0000
@@ -79,7 +79,7 @@
   esac
 
   # The eval makes quoting arguments work.
-  if eval $ac_abs_srcdir/configure $ac_configure_args
--cache-file=$ac_sub_cache_file --srcdir=$ac_abs_srcdir $2
+  if eval /bin/sh -c "$ac_abs_srcdir/configure $ac_configure_args
--cache-file=$ac_sub_cache_file --srcdir=$ac_abs_srcdir $2"
   then :
     echo "$1 configured properly"
   else

--
I think that it's extremely foolish to name a server after the current U.S.
President.                                                 B.W. Fitzpatrick



Re: an old Darwin issue... what is the solution?

Posted by Jeff Trawick <tr...@attglobal.net>.
Pier Fumagalli <pi...@betaversion.org> writes:

> "Jeff Trawick" <tr...@attglobal.net> wrote:

> > Pier's solution results in a cleaner build (a bunch of bogus
> > basename invocations went away).  Neither version of libtool gets the
> > library path into httpd for some reason (Darwin limitation?).
> 
> ???? That's odd... With my most recent build:

I was apparently misinterpreting a symptom :)  My
understanding/experience was that I had to set DYLD_LIBRARY_PATH to
get the libraries found from the non-default location.  I figured that
was because the executable din't have the right search path built in.
But if the path is in httpd as you show, that shouldn't be the case.
I'll try again when I get a moment.

> > *other than wasting a fair amount of time because APR configure bombs
> > when I use --enable-mods-shared="foo1 foo2 foo3 foo4"
> > 
> > Perhaps the logic to build the command-line for the APR sub-configure
> > is busted on Darwin...  more research required :(
> 
> Hmm... Can you give me some more info? What's wrong with it?

Here's an example symptom:

------------cut here------------
trawick@localhost:~/apache/httpd-2.0% rm *cache
trawick@localhost:~/apache/httpd-2.0% ./configure --prefix=/tmp/gobble --enable-mods-shared="autoindex dir"
creating cache ./config.cache
checking for chosen layout... Apache
checking host system type... powerpc-apple-darwin5.3
checking target system type... powerpc-apple-darwin5.3
checking build system type... powerpc-apple-darwin5.3

Configuring Apache Portable Runtime library ...
updating cache ./config.cache
configuring package in srclib/apr now
loading cache /Users/trawick/apache/httpd-2.0/./config.cache
checking host system type... Invalid configuration `dir': machine
`dir' not recognized

checking target system type... Invalid configuration `dir': machine
`dir' not recognized

checking build system type... Invalid configuration `dir': machine
`dir' not recognized

Configuring APR library
...
-------cut here--------

Thanks!
-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Re: an old Darwin issue... what is the solution?

Posted by Pier Fumagalli <pi...@betaversion.org>.
"Chuck Murcko" <ch...@topsail.org> wrote:

> 
> On Thursday, April 11, 2002, at 02:41 PM, Pier Fumagalli wrote:
> 
>> "Jeff Trawick" <tr...@attglobal.net> wrote:
> 
>> The only thing I complain about now is versioning (done by libtool,
>> it's all
>> so screwed)...
>> 
>>> *other than wasting a fair amount of time because APR configure bombs
>>> when I use --enable-mods-shared="foo1 foo2 foo3 foo4"
>>> 
>>> Perhaps the logic to build the command-line for the APR sub-configure
>>> is busted on Darwin...  more research required :(
>> 
>> Hmm... Can you give me some more info? What's wrong with it?
>> 
> 
> Pier do you also exclude the pcre lib from the build? This is also
> required on 1.3 (--disable-rule=WANTHSREGEX).

Nope...

Oddly enough now that you mention it, PCRE is built as a nonshared library
(ar archive, I suppose).... And it complains a little bit for a duplicate
definition of if when it links. Apparently at the end doesn't get compiled
in (otool -rv /usr/sbin/httpd2 doesn't contain any reference to the regexp
functions)...

Is that a problem? The baby runs fine :)

    Pier

--
I think that it's extremely foolish to name a server after the current U.S.
President.                                                 B.W. Fitzpatrick



Re: an old Darwin issue... what is the solution?

Posted by Chuck Murcko <ch...@topsail.org>.
On Thursday, April 11, 2002, at 02:41 PM, Pier Fumagalli wrote:

> "Jeff Trawick" <tr...@attglobal.net> wrote:

> The only thing I complain about now is versioning (done by libtool, 
> it's all
> so screwed)...
>
>> *other than wasting a fair amount of time because APR configure bombs
>> when I use --enable-mods-shared="foo1 foo2 foo3 foo4"
>>
>> Perhaps the logic to build the command-line for the APR sub-configure
>> is busted on Darwin...  more research required :(
>
> Hmm... Can you give me some more info? What's wrong with it?
>

Pier do you also exclude the pcre lib from the build? This is also 
required on 1.3 (--disable-rule=WANTHSREGEX).

Chuck


Re: an old Darwin issue... what is the solution?

Posted by Pier Fumagalli <pi...@betaversion.org>.
"Jeff Trawick" <tr...@attglobal.net> wrote:

> "Roy T. Fielding" <fi...@apache.org> writes:
> 
>> See also <http://fink.sourceforge.net/doc/porting/libtool.php>
> 
> Thanks for the link to fink.  It looks useful in general, beyond the
> libtool information.
> 
> I didn't have any trouble* getting either Sander's or Pier's solution
> working once Sander told me about DYLD_LIBRARY_PATH :)
> 
> Pier's solution results in a cleaner build (a bunch of bogus
> basename invocations went away).  Neither version of libtool gets the
> library path into httpd for some reason (Darwin limitation?).

???? That's odd... With my most recent build:

$ otool -L /Library/Services/Apache2/Binaries/httpd
/Library/Services/Apache2/Libraries/libapr.dylib
/Library/Services/Apache2/Binaries/httpd:
        /Library/Services/Apache2/Libraries/libaprutil.0.dylib
        /Library/Services/Apache2/Libraries/libapr.0.dylib
        /usr/lib/libSystem.B.dylib
        /usr/lib/libdb.3.3.11.dylib
        /Library/Services/Apache2/Libraries/libexpat.0.dylib
/Library/Services/Apache2/Libraries/libapr.dylib:
        /Library/Services/Apache2/Libraries/libapr.0.dylib
        /usr/lib/libSystem.B.dylib

It _is_ in HTTPD... (Or you're thinking about something else?)
The only thing I complain about now is versioning (done by libtool, it's all
so screwed)...

> *other than wasting a fair amount of time because APR configure bombs
> when I use --enable-mods-shared="foo1 foo2 foo3 foo4"
> 
> Perhaps the logic to build the command-line for the APR sub-configure
> is busted on Darwin...  more research required :(

Hmm... Can you give me some more info? What's wrong with it?

    Pier

--
I think that it's extremely foolish to name a server after the current U.S.
President.                                                 B.W. Fitzpatrick



Re: an old Darwin issue... what is the solution?

Posted by Jeff Trawick <tr...@attglobal.net>.
"Roy T. Fielding" <fi...@apache.org> writes:

> See also <http://fink.sourceforge.net/doc/porting/libtool.php>

Thanks for the link to fink.  It looks useful in general, beyond the
libtool information.

I didn't have any trouble* getting either Sander's or Pier's solution
working once Sander told me about DYLD_LIBRARY_PATH :)

Pier's solution results in a cleaner build (a bunch of bogus
basename invocations went away).  Neither version of libtool gets the
library path into httpd for some reason (Darwin limitation?).

*other than wasting a fair amount of time because APR configure bombs
when I use --enable-mods-shared="foo1 foo2 foo3 foo4"

Perhaps the logic to build the command-line for the APR sub-configure
is busted on Darwin...  more research required :(

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Re: an old Darwin issue... what is the solution?

Posted by "Roy T. Fielding" <fi...@apache.org>.
See also <http://fink.sourceforge.net/doc/porting/libtool.php>

....Roy


Re: an old Darwin issue... what is the solution?

Posted by Jeff Trawick <tr...@attglobal.net>.
Jeff Trawick <tr...@attglobal.net> writes:

> Did you set DYLD_LIBRARY_PATH to the directory with your libraries?

I meant "to the directory where libapr and libaprutil are installed?"


-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Re: an old Darwin issue... what is the solution?

Posted by Justin Erenkrantz <je...@apache.org>.
On Sun, Apr 21, 2002 at 09:08:56AM -0400, Jim Jagielski wrote:
> Pier Fumagalli wrote:
> > Big -1 on setting DYLD_LIBRARY_PATH in ENVVARS... That's just a hack...
> > 
> 
> Agreed... 

Indeed.  I haven't seen any problems where I've needed to set
DYLD_LIBRARY_PATH on my box.  So, I'm not sure why he has
to.  -- justin

Re: an old Darwin issue... what is the solution?

Posted by Pier Fumagalli <pi...@betaversion.org>.
Jens-Uwe Mager <ju...@anubis.han.de> wrote:

> On Sat, Apr 20, 2002 at 08:15:17AM -0400, Jeff Trawick wrote:
>> "Gregory (Grisha) Trubetskoy" <gr...@ispol.com> writes:
>> 
>>> This fixed it, thanks.
>>> 
>>> Seems to me though that httpd ought to know where the libs are without my
>>> help :)
>> 
>> I think Pier Fumagalli explained it recently.  IIRC, the need for the
>> envvar is because we link against the libraries before they were
>> installed.
>> 
>> I don't remember whether or not we discussed the appropriateness of
>> setting DYLD_LIBRARY_PATH in the envvars file that apachectl uses.  It
>> would seem to me to be a reasonable thing to do.
> 
> Isn't the -install_name option to the Darwin libtool supposed to handle
> that case? This way you can embed the final install destination in the
> shared library.

Yes, and that what it does with MY version of GNU libtool... He seems to be
using the one shipping w/ the developer tools...

Big -1 on setting DYLD_LIBRARY_PATH in ENVVARS... That's just a hack...

    Pier


Re: an old Darwin issue... what is the solution?

Posted by Jens-Uwe Mager <ju...@anubis.han.de>.
On Sat, Apr 20, 2002 at 08:15:17AM -0400, Jeff Trawick wrote:
> "Gregory (Grisha) Trubetskoy" <gr...@ispol.com> writes:
> 
> > This fixed it, thanks.
> > 
> > Seems to me though that httpd ought to know where the libs are without my
> > help :)
> 
> I think Pier Fumagalli explained it recently.  IIRC, the need for the
> envvar is because we link against the libraries before they were
> installed.
> 
> I don't remember whether or not we discussed the appropriateness of
> setting DYLD_LIBRARY_PATH in the envvars file that apachectl uses.  It
> would seem to me to be a reasonable thing to do.

Isn't the -install_name option to the Darwin libtool supposed to handle
that case? This way you can embed the final install destination in the
shared library.

-- 
Jens-Uwe Mager	<pgp-mailto:62CFDB25> <ja...@jabber.com>

Re: an old Darwin issue... what is the solution?

Posted by Jeff Trawick <tr...@attglobal.net>.
"Gregory (Grisha) Trubetskoy" <gr...@ispol.com> writes:

> This fixed it, thanks.
> 
> Seems to me though that httpd ought to know where the libs are without my
> help :)

I think Pier Fumagalli explained it recently.  IIRC, the need for the
envvar is because we link against the libraries before they were
installed.

I don't remember whether or not we discussed the appropriateness of
setting DYLD_LIBRARY_PATH in the envvars file that apachectl uses.  It
would seem to me to be a reasonable thing to do.

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Re: an old Darwin issue... what is the solution?

Posted by "Gregory (Grisha) Trubetskoy" <gr...@ispol.com>.
This fixed it, thanks.

Seems to me though that httpd ought to know where the libs are without my
help :)

I'm an OSX newbie, so forgive me if I'm missing some obvious reason why it
couldn't work this way.

Grisha


On 19 Apr 2002, Jeff Trawick wrote:

> "Gregory (Grisha) Trubetskoy" <gr...@ispol.com> writes:
>
> > There still appears to be a problem - I just went through all the
> > steps Pier described below, and I still get:
> >
> > $ ./apachectl start
> > dyld: /Users/grisha/www/bin/httpd can't open library: .libs/libaprutil.dylib  (No such file or directory, errno = 2)
> > ./apachectl start: httpd could not be started
>
> Did you set DYLD_LIBRARY_PATH to the directory with your libraries?
>
> --
> Jeff Trawick | trawick@attglobal.net
> Born in Roswell... married an alien...
>


Re: an old Darwin issue... what is the solution?

Posted by Jeff Trawick <tr...@attglobal.net>.
"Gregory (Grisha) Trubetskoy" <gr...@ispol.com> writes:

> There still appears to be a problem - I just went through all the
> steps Pier described below, and I still get:
> 
> $ ./apachectl start
> dyld: /Users/grisha/www/bin/httpd can't open library: .libs/libaprutil.dylib  (No such file or directory, errno = 2)
> ./apachectl start: httpd could not be started

Did you set DYLD_LIBRARY_PATH to the directory with your libraries?

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Re: an old Darwin issue... what is the solution?

Posted by "Gregory (Grisha) Trubetskoy" <gr...@ispol.com>.
There still appears to be a problem - I just went through all the
steps Pier described below, and I still get:

$ ./apachectl start
dyld: /Users/grisha/www/bin/httpd can't open library: .libs/libaprutil.dylib  (No such file or directory, errno = 2)
./apachectl start: httpd could not be started

This is OSX 10.1.3, libtool 1.4.2 and autoconf 2.52 from the link below,
apache 2.0.35

Has anyone been able to compile on OS X?

Grisha

On Wed, 10 Apr 2002, Pier Fumagalli wrote:

> > I have 10.1.3 and the December developer tools package.
> >
> > Thanks for any hints (I'll doc this for our users as well).
>
> That's a glibtool issue... You have to re-generate your buildconf using an
> updated version of GNU libtool _NOT_ the one in the developers tools...
>
> Download my copy at http://www.apache.org/~pier/macosx (both libtool 1.4.2
> and autoconf 2.52), get in to your apache source tree, run ./buildconf,
> re-run ./configure, re-make all and install...
>
> # cd $(APACHE_2_SRC)
> # make distclean
> # ./buildconf
> # ./configure.....
> # make depend
> # make all
> # sudo make install
>
>     Pier
>


Re: an old Darwin issue... what is the solution?

Posted by Pier Fumagalli <pi...@betaversion.org>.
"Jeff Trawick" <tr...@attglobal.net> wrote:

> I was testing the patch you mentioned and ran into an old problem...
> I see myself and Pier asking about this very problem last year
> (August) but I can't find the solution anywhere.
> 
> If I start httpd via the libtool shell script (./httpd from httpd-2.0
> directory) it starts fine.  If I start httpd via apachectl it fails
> with this error message:
> 
> [localhost:~/apache/httpd-2.0] trawick%
> /Users/trawick/apacheinst/bin/apachectl start
> dyld: /Users/trawick/apacheinst/bin/httpd can't open library:
> .libs/libaprutil.dylib  (No such file or directory, errno = 2)
> /Users/trawick/apacheinst/bin/apachectl start: httpd could not be started
> 
> Any clues?  glibtoolize is in PATH and the easy patch for glibtool
> seems to be in the right place:
> 
> [localhost:~/apache/httpd-2.0] trawick% diff
> /usr/share/libtool/ltconfig.bak /usr/share/libtool/ltconfig
> 1375c1375,1376
> <     allow_undefined_flag='-undefined warning'
> ---
>> # hack on next line is from Sander Temme
>>     allow_undefined_flag='-undefined suppress -flat_namespace'
> 
> I have 10.1.3 and the December developer tools package.
> 
> Thanks for any hints (I'll doc this for our users as well).

That's a glibtool issue... You have to re-generate your buildconf using an
updated version of GNU libtool _NOT_ the one in the developers tools...

Download my copy at http://www.apache.org/~pier/macosx (both libtool 1.4.2
and autoconf 2.52), get in to your apache source tree, run ./buildconf,
re-run ./configure, re-make all and install...

# cd $(APACHE_2_SRC)
# make distclean
# ./buildconf
# ./configure.....
# make depend
# make all
# sudo make install

    Pier