You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Henry Jen <he...@ztune.net> on 2006/04/01 02:50:57 UTC
Patch for checking expat on Solaris
Hi,
Attached patch allows to build apr-util with system provided libexpat on
OpenSolaris.
On the machine, there is a expat.h and libexpat.so.* in /usr/sfw/include
and /usr/sfw/lib. But there is no .a or .la file.
It should not be required to have a .la file, not to mention a .a file.
.a is, afaik, an archive file for static link.
The attached patch check only the header file, and add the -L and -R
flags accordingly.
I believe this should also applicable to the FreeBSD system, in that
case, we may combine the FreeBSD and Solaris section added in this patch.
Cheers,
Henry
Re: Patch for checking expat on Solaris
Posted by Henry Jen <sl...@gmail.com>.
Joe Orton wrote:
> On Tue, May 02, 2006 at 01:10:44PM -0700, Henry Jen wrote:
>> Joe Orton wrote:
>>> On Fri, Apr 28, 2006 at 07:06:07PM -0700, Henry Jen wrote:
>>>> Attached please find a new patch using AC_CHECK_LIB to find the correct
>>>> library path.
>>> If you want to rewrite this code then look at dbm.m4 for how to do it
>>> properly.
>>>
>>> - you can't just call AC_CHECK_LIB, you need to cache and display
>>> results properly
>> Uh? The result are cached in expat_xxx as they were before. Am I missing
>> something?
>
> Doing:
>
> + for d in $1/lib $1/libdir ; do
> + CFLAGS="$old_cflags -I$1/include"
> + LDFLAGS="$old_ldflags -L$d -R$d"
> + AC_CHECK_LIB(expat, XML_ParserCreate, [
>
> does not work as you might think. AC_CHECK_LIB will cache the test
> result the first time through the for loop; the second test will always
> have the same result as the first.
>
Hmm, it won't because there is a break for the first match. Otherwise,
no result is set.
>>> - the -R flag should really never be used, especially like this - at the
>>> very least, you can't assume all linkers support it. You generally can
>>> rely on libtool to add RPATHs iff necessary.
>> Hmm, I don't know about how libtool add RPATH. Does it apply to
>> situation like this(solve dependencies on some other share libraries
>> without a .la) or it only works for *creating* a .la?
>
> libtool will add an RPATH to libaprutil if it is linked against a
> libexpat.la where the libexpat.la is in a directory which is not in the
> standard system library search path.
>
OK, what if it is not link against with libexpat.la but a libexpat.so?
My experiment on Solaris does not add -R automatically. (Solaris only
provides libexpat.so, no libexpat.la)
Cheers,
Henry
Re: Patch for checking expat on Solaris
Posted by Joe Orton <jo...@redhat.com>.
On Tue, May 02, 2006 at 01:10:44PM -0700, Henry Jen wrote:
> Joe Orton wrote:
> >On Fri, Apr 28, 2006 at 07:06:07PM -0700, Henry Jen wrote:
> >>Attached please find a new patch using AC_CHECK_LIB to find the correct
> >>library path.
> >
> >If you want to rewrite this code then look at dbm.m4 for how to do it
> >properly.
> >
> >- you can't just call AC_CHECK_LIB, you need to cache and display
> >results properly
>
> Uh? The result are cached in expat_xxx as they were before. Am I missing
> something?
Doing:
+ for d in $1/lib $1/libdir ; do
+ CFLAGS="$old_cflags -I$1/include"
+ LDFLAGS="$old_ldflags -L$d -R$d"
+ AC_CHECK_LIB(expat, XML_ParserCreate, [
does not work as you might think. AC_CHECK_LIB will cache the test
result the first time through the for loop; the second test will always
have the same result as the first.
> >- the -R flag should really never be used, especially like this - at the
> >very least, you can't assume all linkers support it. You generally can
> >rely on libtool to add RPATHs iff necessary.
>
> Hmm, I don't know about how libtool add RPATH. Does it apply to
> situation like this(solve dependencies on some other share libraries
> without a .la) or it only works for *creating* a .la?
libtool will add an RPATH to libaprutil if it is linked against a
libexpat.la where the libexpat.la is in a directory which is not in the
standard system library search path.
Regards,
joe
Re: Patch for checking expat on Solaris
Posted by Henry Jen <he...@ztune.net>.
Joe Orton wrote:
> On Fri, Apr 28, 2006 at 07:06:07PM -0700, Henry Jen wrote:
>> Attached please find a new patch using AC_CHECK_LIB to find the correct
>> library path.
>
> If you want to rewrite this code then look at dbm.m4 for how to do it
> properly.
>
> - you can't just call AC_CHECK_LIB, you need to cache and display
> results properly
>
Uh? The result are cached in expat_xxx as they were before. Am I missing
something?
> - the -R flag should really never be used, especially like this - at the
> very least, you can't assume all linkers support it. You generally can
> rely on libtool to add RPATHs iff necessary.
>
Hmm, I don't know about how libtool add RPATH. Does it apply to
situation like this(solve dependencies on some other share libraries
without a .la) or it only works for *creating* a .la?
Cheers,
Henry
Re: Patch for checking expat on Solaris
Posted by Joe Orton <jo...@redhat.com>.
On Fri, Apr 28, 2006 at 07:06:07PM -0700, Henry Jen wrote:
> Attached please find a new patch using AC_CHECK_LIB to find the correct
> library path.
If you want to rewrite this code then look at dbm.m4 for how to do it
properly.
- you can't just call AC_CHECK_LIB, you need to cache and display
results properly
- the -R flag should really never be used, especially like this - at the
very least, you can't assume all linkers support it. You generally can
rely on libtool to add RPATHs iff necessary.
Regards,
joe
Re: Patch for checking expat on Solaris
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Henry Jen wrote:
> William A. Rowe, Jr. wrote:
>
>> Henry Jen wrote:
>>
>> After patch, my solaris binary can no longer be redeployed to /opt/httpd/, but
>> your binary finds your expat in /opt/sfw/lib or where ever.
>
> This should not be true, but I could be overlooking. Would you please
> elaborate?
If you are correct, and the search order remains LD_LIBRARY_PATH + -R path
+ default system locations, then I don't think I have an issue from that
perspective. but...
This leaves me wondering, if we passed -L and successfully link, why isn't
libtool doing what libtool is supposed to be doing? Are we trying to hack
around a libtool flaw?
> Before we sort out the problem, how about let's remove the -R and commit
> the rest? That at least allows configure to locate the lib correctly. I
> will try to ping you on irc to have some discussion if you get some time.
++1, let me review the rest and commit after giving the rest a bit more
consideration.
> It's the advise I got from Solaris engineers to use -R instead of change
> my system default setting with crle, and don't set LD_LIBRARY_PATH.
Yes, I understand that. On target machines where the same builds need to
be deployed relocatably in parallel, and where no build tools exist, that
suggestion is not practical.
> Following two URLs have covered the topic.
Thanks for the links!
Bill
Re: Patch for checking expat on Solaris
Posted by Henry Jen <he...@ztune.net>.
William A. Rowe, Jr. wrote:
> Henry Jen wrote:
>> William A. Rowe, Jr. wrote:
>>
>>> The issue I have is that your -enforcing- -R destroys my
>>> -portability-. We
>>> need to find a happy comprimize to build to a manditory -prefix
>>> versus the
>>> usual -prefix, yet relocatable (with LD_LIBRARY_PATH).
>>
>> Hmm, I am curious what portability is destroyed. :-)
>
I misunderstood the portability you referring to, thought it means other
platforms. Glad to know that you are using Solaris and SunStudio. :-P
> IIUC, before patch, my solaris binary can deployed at an arbitrary
> /opt/apache2/
> location, apachectl resolves the LD_LIBRARY_PATH. Before patch, your
> arbitrary
> solution (linked to a thirdparty build of expat installed in
> /usr/local/lib or
> some other, nonstandard, location) fails to resolve libexpat.so at run
> time.
>
-R gives a default search path, LIB_LIBRARY_PATH still can be used when
needed.
Quote `man ld.so.1` on Solaris:
The runtime linker uses a prescribed search path for locat-
ing the dynamic dependencies of an object. The default
search paths are the runpath recorded in the object, fol-
lowed by a series of defaults. For 32-bit objects, the
defaults are /lib followed by /usr/lib. For 64-bit objects,
the defaults are /lib/64 followed by /usr/lib/64. These
defaults component can be modified using a configuration
file that is created with crle(1). The runpath is specified
when the dynamic object is constructed using the -R option
to ld(1). The environment variable LD_LIBRARY_PATH can be
used to indicate directories to be searched before the
default directories.
I work out the patch because I want to use the default expat installed
by Solaris system(in /usr/sfw/lib, which is not in the default search
path), not custom built or the one come with apr-util.
> After patch, my solaris binary can no longer be redeployed to
> /opt/httpd/, but
> your binary finds your expat in /opt/sfw/lib or where ever.
>
This should not be true, but I could be overlooking. Would you please
elaborate?
The difference between with or without -R is the -R will be searched
before the system default. Unless you got a different copy in the -R
pointed path, there should be no difference. But I wonder how could that
happen, -R is about to make sure you are getting the correct copy.
> So my point is, if you want to add -R explicitly to your ldflags, that's
> cool.
> If you want to come up with a proposal to make this automatic but optional,
> that's cool too. If you unilaterally decide your way is right, that's
> not cool.
>
Your comment is very much appreciated, gives me a chance to exam my
understanding. :-)
Before we sort out the problem, how about let's remove the -R and commit
the rest? That at least allows configure to locate the lib correctly. I
will try to ping you on irc to have some discussion if you get some time.
As the coolness, I want to work with the community to make sure I am
doing the correct thing, which is why I always consult upstream team.
It's the advise I got from Solaris engineers to use -R instead of change
my system default setting with crle, and don't set LD_LIBRARY_PATH.
Following two URLs have covered the topic.
http://www.visi.com/~barr/ldpath.html
http://linuxmafia.com/faq/Admin/ld-lib-path.html
Thanks again for the comment, I really appreciate.
Cheers,
Henry
Re: Patch for checking expat on Solaris
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Henry Jen wrote:
> William A. Rowe, Jr. wrote:
>
>> The issue I have is that your -enforcing- -R destroys my -portability-. We
>> need to find a happy comprimize to build to a manditory -prefix versus the
>> usual -prefix, yet relocatable (with LD_LIBRARY_PATH).
>
> Hmm, I am curious what portability is destroyed. :-)
IIUC, before patch, my solaris binary can deployed at an arbitrary /opt/apache2/
location, apachectl resolves the LD_LIBRARY_PATH. Before patch, your arbitrary
solution (linked to a thirdparty build of expat installed in /usr/local/lib or
some other, nonstandard, location) fails to resolve libexpat.so at run time.
After patch, my solaris binary can no longer be redeployed to /opt/httpd/, but
your binary finds your expat in /opt/sfw/lib or where ever.
So my point is, if you want to add -R explicitly to your ldflags, that's cool.
If you want to come up with a proposal to make this automatic but optional,
that's cool too. If you unilaterally decide your way is right, that's not cool.
:)
Bill
Re: Patch for checking expat on Solaris
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Henry Jen wrote:
>
> I mean, based on my limited platform experience, gcc supports -R and
> Windows is not using autotools, right? And if you built with the -L
> path, isn't it should be the same for -R?
What on earth do windows, or gcc, have to do with anything? We are talking
about Solaris, and SunStudio cc.
Bill
Re: Patch for checking expat on Solaris
Posted by Henry Jen <he...@ztune.net>.
William A. Rowe, Jr. wrote:
> Henry Jen wrote:
>> > -L and -R should be redundant, no?
>>
>> No, they are not. -L is for link time, -R for runtime. For the
>> default
>> linker on Solaris, the -R is taking the value from -L as gnu ld.
>>
>> I meant to say Solaris default linker does not behave the same as GNU ld.
>> -R is recommended practice on Solaris. crle or LD_LIBRARY_PATH can do
>> the trick, but those practice are discouraged.
>
> The issue I have is that your -enforcing- -R destroys my -portability-. We
> need to find a happy comprimize to build to a manditory -prefix versus the
> usual -prefix, yet relocatable (with LD_LIBRARY_PATH).
>
>
>
Hmm, I am curious what portability is destroyed. :-)
I mean, based on my limited platform experience, gcc supports -R and
Windows is not using autotools, right? And if you built with the -L
path, isn't it should be the same for -R?
I can work around this by using LDFLAGS but that may not be as precise
as this.
Any other suggestions?
Cheers,
Henry
Re: Patch for checking expat on Solaris
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Henry Jen wrote:
> > -L and -R should be redundant, no?
>
> No, they are not. -L is for link time, -R for runtime. For the default
> linker on Solaris, the -R is taking the value from -L as gnu ld.
>
> I meant to say Solaris default linker does not behave the same as GNU ld.
> -R is recommended practice on Solaris. crle or LD_LIBRARY_PATH can do
> the trick, but those practice are discouraged.
The issue I have is that your -enforcing- -R destroys my -portability-. We
need to find a happy comprimize to build to a manditory -prefix versus the
usual -prefix, yet relocatable (with LD_LIBRARY_PATH).
Re: Patch for checking expat on Solaris
Posted by Henry Jen <he...@ztune.net>.
On 4/10/06, Henry Jen <he...@ztune.net> wrote:
>
> William A. Rowe, Jr. wrote:
> > Henry Jen wrote:
> >>
> >> + elif test -r "$1/include/expat.h"; then + dnl Expat 1.95.*
> >> installation (without libtool)
> >> + dnl Solaris
> >> + expat_include_dir="$1/include"
> >> + expat_ldflags="-L$1/lib -R$1/lib"
> >> + expat_libs="-lexpat"
> >
> > Here's my essential problems with growing this cruft further :(
> >
> > -L and -R should be redundant, no?
>
> No, they are not. -L is for link time, -R for runtime. For the default
> linker on Solaris, the -R is taking the value from -L as gnu ld.
I meant to say Solaris default linker does not behave the same as GNU ld.
-R is recommended practice on Solaris. crle or LD_LIBRARY_PATH can do the
trick, but those practice are discouraged.
> Further, there's this lovely assumption
> > that because we find an expat .h in X/include/ we infer without any
> testing
> > whatsoever there is a ld in X/lib.
> >
> > These sorts of fragile assumptions *throughout* the build system (not
> > singling out specifically your patch), e.g. the old uuid detection code,
> > ongoing debates
> > about lib64 (you assume $1/lib, how do you know X/include/ isn't
> > X/lib64/'s?)
> > Make me really hesitate to touch the code further without a real
> > test-compile
> > and test-link as the new uuid code performs (before bailing with 'I
> > surrender!')
> >
>
> Thank you for the feedback, I will redo the patch.
>
> IMHO, we should do AC_CHECK_LIB with the default LDFLAGS/CFLAGS appended
> by the value of --with-expat suffixed with /include|/liband then make
> sure those flags are passed into the result Makefiles.
>
> Depending on the .a or .la file is in the place and readable is not more
> correct, I would think. Even if we want to do that, should we check for
> .so rather than .la or .a? Because the .a or .la should not be necessary
> if the libexpat.so is built correctly. Take the Solaris example, there
> is no .la or .a, only .so exist in /usr/sfw/lib, and the link will
> succeed.
Attached please find a new patch using AC_CHECK_LIB to find the correct
library path.
Cheers,
Henry
Re: Patch for checking expat on Solaris
Posted by Henry Jen <he...@ztune.net>.
William A. Rowe, Jr. wrote:
> Henry Jen wrote:
>>
>> + elif test -r "$1/include/expat.h"; then + dnl Expat 1.95.*
>> installation (without libtool)
>> + dnl Solaris
>> + expat_include_dir="$1/include"
>> + expat_ldflags="-L$1/lib -R$1/lib"
>> + expat_libs="-lexpat"
>
> Here's my essential problems with growing this cruft further :(
>
> -L and -R should be redundant, no?
No, they are not. -L is for link time, -R for runtime. For the default
linker on Solaris, the -R is taking the value from -L as gnu ld.
> Further, there's this lovely assumption
> that because we find an expat .h in X/include/ we infer without any testing
> whatsoever there is a ld in X/lib.
>
> These sorts of fragile assumptions *throughout* the build system (not
> singling out specifically your patch), e.g. the old uuid detection code,
> ongoing debates
> about lib64 (you assume $1/lib, how do you know X/include/ isn't
> X/lib64/'s?)
> Make me really hesitate to touch the code further without a real
> test-compile
> and test-link as the new uuid code performs (before bailing with 'I
> surrender!')
>
Thank you for the feedback, I will redo the patch.
IMHO, we should do AC_CHECK_LIB with the default LDFLAGS/CFLAGS appended
by the value of --with-expat suffixed with /include|/liband then make
sure those flags are passed into the result Makefiles.
Depending on the .a or .la file is in the place and readable is not more
correct, I would think. Even if we want to do that, should we check for
.so rather than .la or .a? Because the .a or .la should not be necessary
if the libexpat.so is built correctly. Take the Solaris example, there
is no .la or .a, only .so exist in /usr/sfw/lib, and the link will succeed.
Cheers,
Henry
Re: Patch for checking expat on Solaris
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Henry Jen wrote:
>
> + elif test -r "$1/include/expat.h"; then
> + dnl Expat 1.95.* installation (without libtool)
> + dnl Solaris
> + expat_include_dir="$1/include"
> + expat_ldflags="-L$1/lib -R$1/lib"
> + expat_libs="-lexpat"
Here's my essential problems with growing this cruft further :(
-L and -R should be redundant, no? Further, there's this lovely assumption
that because we find an expat .h in X/include/ we infer without any testing
whatsoever there is a ld in X/lib.
These sorts of fragile assumptions *throughout* the build system (not singling
out specifically your patch), e.g. the old uuid detection code, ongoing debates
about lib64 (you assume $1/lib, how do you know X/include/ isn't X/lib64/'s?)
Make me really hesitate to touch the code further without a real test-compile
and test-link as the new uuid code performs (before bailing with 'I surrender!')