apr-1-config on mixed 32/64bit build server

[Daniel Pocock <da...@pocock.com.au>]

I notice that the spec file installs apr*config to bindir

Makefile.in declares the filename:
APR_CONFIG = apr-$(APR_MAJOR_VERSION)-config

However, on an x86_64 platform, it may be necessary to install both 32
and 64 bit packages concurrently.

On RHEL, the 64 bit libraries can go under prefix/lib64 instead of
prefix/lib, using the macro %_lib in the spec file.  On Debian amd64,
the 32 bit libraries can go under a lib32 directory.

The only thing that seems out of place is apr-1-config, as there is no
bin64 or bin32 directory.  If the 32 bit and 64 bit packages are
installed concurrently, then one of them overwrites the other's
apr-1-config.

Regards,

Daniel

Re: apr-1-config on mixed 32/64bit build server

[Bojan Smojver <bo...@rexursive.com>]

On Wed, 2009-04-08 at 14:14 +0100, Daniel Pocock wrote:
> The only thing that seems out of place is apr-1-config, as there is no
> bin64 or bin32 directory.  If the 32 bit and 64 bit packages are
> installed concurrently, then one of them overwrites the other's
> apr-1-config.

You can have a look at the RPMs shipped with Fedora to see how Joe fixed
this using pkg-config.

-- 
Bojan

Re: apr-1-config on mixed 32/64bit build server

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

Daniel.Pocock@barclayscapital.com wrote:
>  
> 
> 
>> | - the output of `apr-X-config --ld-flags' will always be .../lib or 
>> | .../lib64, depending on which version of apr-X-config was installed 
>> | most recently
>>
>> You should not add the -L path if it's part of the system 
>> search path as that'll confuse gcc in some cases.
> 
> In my case, apr is being installed to a non-standard location (under
> /opt) with some enterprise management tools (e.g. Ganglia).  Therefore,
> -L is required, and the gmond binaries (e.g. gmond) use the RPATH to
> find apr.

Only if apr-X-config hasn't been hacked, appropriately, to find the right
answer.

>> In Debian, if you want to build for another environment, use 
>> a chroot (or a VM).
> 
> What about the special case of creating 32 bit libs for an amd64
> install?  In this case, the 32 bit libs go under /usr/lib32 or something
> similar (opposite to Redhat, which puts the 64 bit libs under
> /usr/lib64)

And thus you understand why the apr project isn't seeking actively to
solve this.  Whichever answer we choose is wrong for another group of
folks, so it becomes your puzzle to solve for {insert distro here}

RE: apr-1-config on mixed 32/64bit build server

[Da...@barclayscapital.com]

 


> | - the output of `apr-X-config --ld-flags' will always be .../lib or 
> | .../lib64, depending on which version of apr-X-config was installed 
> | most recently
> 
> You should not add the -L path if it's part of the system 
> search path as that'll confuse gcc in some cases.

In my case, apr is being installed to a non-standard location (under
/opt) with some enterprise management tools (e.g. Ganglia).  Therefore,
-L is required, and the gmond binaries (e.g. gmond) use the RPATH to
find apr.

> 
> | I'm not suggesting apr needs to implement something special 
> for every 
> | weird setup.  Rather, it just needs a generalisation that can be 
> | applied in the most popular cases (probably RHEL and Debian).  Some 
> | possible solutions that I haven't completely thought through:
> 
> In Debian, if you want to build for another environment, use 
> a chroot (or a VM).

What about the special case of creating 32 bit libs for an amd64
install?  In this case, the 32 bit libs go under /usr/lib32 or something
similar (opposite to Redhat, which puts the 64 bit libs under
/usr/lib64)
_______________________________________________

This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing.  Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP.  This email may relate to or be sent from other members of the Barclays Group.
_______________________________________________

Re: apr-1-config on mixed 32/64bit build server

[Tollef Fog Heen <tf...@err.no>]

]] Daniel Pocock 

| > The only variation to gcc is the -64 flag - this should be transparent,
| > you should have to do nothing special until you overload your box with
| > multiple flavors.
| >   
| The real issue is not the -64 flag - that is usually added by the
| configure script that is calling apr-X-config anyway.  The real issues
| that arise:
| 
| - the output of `apr-X-config --ld-flags' will always be .../lib or
| .../lib64, depending on which version of apr-X-config was installed
| most recently

You should not add the -L path if it's part of the system search path as
that'll confuse gcc in some cases.

| I'm not suggesting apr needs to implement something special for every
| weird setup.  Rather, it just needs a generalisation that can be
| applied in the most popular cases (probably RHEL and Debian).  Some
| possible solutions that I haven't completely thought through:

In Debian, if you want to build for another environment, use a chroot
(or a VM).

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: apr-1-config on mixed 32/64bit build server

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

Daniel Pocock wrote:
> 
> - depending upon how fussy the packaging system is, it may not be
> thrilled about one package overwriting another package's files - RHEL
> hasn't complained about this, but maybe future versions will be more
> attentive to such issues

They were plenty attentive; their apr-1-configure is identical for both
packages from the fedora 10 -devel packages.

Hint-hint ... use the source luke :)

You'll find they did something very fedora-specific.

> I'm not suggesting apr needs to implement something special for every
> weird setup.  Rather, it just needs a generalisation that can be applied
> in the most popular cases (probably RHEL and Debian). 

I don't solve problems for popular cases.  We solve for all cases, or
we solve for none.

> Some possible solutions that I haven't completely thought through:
> 
> - make apr-X-config part of the noarch package (it is just a script
> anyway), and have a command line option for specifying architecture,
> e.g, on RHEL, I could do the following:

No need, if they are identical.

> - alternatively, have different versions of apr-X-config, e.g.
> apr-2-config-x86_64 or apr-2-config-64; the end user would need to make
> sure that they invoked the right one

-1.  Counterintuitive, not conforming to build semantics of other packages.
If we want apr-2-trueconfig launched from the apr-2-config symlink, that
would make sense, where apr-2-trueconfig exists in the build/ dir.

Their solution is very elegant, and wish it were offered for backport.
Check it out ;-)

Re: apr-1-config on mixed 32/64bit build server

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

On Wed, Apr 08, 2009 at 05:48:24PM -0500, William Rowe wrote:
> Daniel Pocock wrote:
> > - alternatively, have different versions of apr-X-config, e.g.
> > apr-2-config-x86_64 or apr-2-config-64; the end user would need to make
> > sure that they invoked the right one
> 
> -1.  If we want apr-2-trueconfig launched from the apr-2-config symlink,
> that would make sense, where apr-2-trueconfig exists in the build/ dir.
> 
> Their solution is very elegant, and wish it were offered for backport.
> Check it out ;-)

Which bit, the tricks to use pkg-config?  I think the premise of that 
work (that build env scripts in $bindir should be arch-neutral) is 
dubious and I don't think it's appropriate to have upstream projects 
maintain the fugly hacks necessary to uphold that premise.

There's a better argument that the contents of $includedir should be 
arch-neutral, something that APR fails on also, but a general solution 
for that would be hard too.

Regards, Joe

Re: apr-1-config on mixed 32/64bit build server

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

Daniel Pocock wrote:
> 
> - depending upon how fussy the packaging system is, it may not be
> thrilled about one package overwriting another package's files - RHEL
> hasn't complained about this, but maybe future versions will be more
> attentive to such issues

They were plenty attentive; their apr-1-configure is identical for both
packages from the fedora 10 -devel packages.

Hint-hint ... use the source luke :)

You'll find they did something very fedora-specific.

> I'm not suggesting apr needs to implement something special for every
> weird setup.  Rather, it just needs a generalisation that can be applied
> in the most popular cases (probably RHEL and Debian). 

I don't solve problems for popular cases.  We solve for all cases, or
we solve for none.

> Some possible solutions that I haven't completely thought through:
> 
> - make apr-X-config part of the noarch package (it is just a script
> anyway), and have a command line option for specifying architecture,
> e.g, on RHEL, I could do the following:

No need if they are identical.

> - alternatively, have different versions of apr-X-config, e.g.
> apr-2-config-x86_64 or apr-2-config-64; the end user would need to make
> sure that they invoked the right one

-1.  If we want apr-2-trueconfig launched from the apr-2-config symlink,
that would make sense, where apr-2-trueconfig exists in the build/ dir.

Their solution is very elegant, and wish it were offered for backport.
Check it out ;-)

Re: apr-1-config on mixed 32/64bit build server

[Daniel Pocock <da...@pocock.com.au>]

> The only variation to gcc is the -64 flag - this should be transparent,
> you should have to do nothing special until you overload your box with
> multiple flavors.
>   
The real issue is not the -64 flag - that is usually added by the 
configure script that is calling apr-X-config anyway.  The real issues 
that arise:

- the output of `apr-X-config --ld-flags' will always be .../lib or 
.../lib64, depending on which version of apr-X-config was installed most 
recently

- depending upon how fussy the packaging system is, it may not be 
thrilled about one package overwriting another package's files - RHEL 
hasn't complained about this, but maybe future versions will be more 
attentive to such issues

I'm not suggesting apr needs to implement something special for every 
weird setup.  Rather, it just needs a generalisation that can be applied 
in the most popular cases (probably RHEL and Debian).  Some possible 
solutions that I haven't completely thought through:

- make apr-X-config part of the noarch package (it is just a script 
anyway), and have a command line option for specifying architecture, 
e.g, on RHEL, I could do the following:

$host=x86_64-....
apr-2-config --host=$host --link-ld   # output: -L/usr/lib64 -lapr-2

$host=i386-....
apr-2-config --host=$host --link-ld   # output: -L/usr/lib -lapr-2

- alternatively, have different versions of apr-X-config, e.g. 
apr-2-config-x86_64 or apr-2-config-64; the end user would need to make 
sure that they invoked the right one

Regards,

Daniel

Re: apr-1-config on mixed 32/64bit build server

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

Daniel Pocock wrote:
> 
> I notice that the spec file installs apr*config to bindir
> 
> Makefile.in declares the filename:
> APR_CONFIG = apr-$(APR_MAJOR_VERSION)-config
> 
> However, on an x86_64 platform, it may be necessary to install both 32
> and 64 bit packages concurrently.
> 
> On RHEL, the 64 bit libraries can go under prefix/lib64 instead of
> prefix/lib, using the macro %_lib in the spec file.  On Debian amd64,
> the 32 bit libraries can go under a lib32 directory.
> 
> The only thing that seems out of place is apr-1-config, as there is no
> bin64 or bin32 directory.  If the 32 bit and 64 bit packages are
> installed concurrently, then one of them overwrites the other's
> apr-1-config.

The only variation to gcc is the -64 flag - this should be transparent,
you should have to do nothing special until you overload your box with
multiple flavors.

Keep in mind we are not here to address packager's design mistakes, such
that we have one set of solutions for fedora and another for debian, or
similarly across bsd flavors.

So... two ideas, one is to support -32 or -64 flags to apr-2-config, and
the other would be to respect uname -m / setarch.  How to accomplish this,
though... perhaps apr-2-config.arch packages with apr-2-config resolving
to whichever it believes is correct?

Re: apr-1-config on mixed 32/64bit build server

[Max Bowsher <ma...@ukf.net>]

Daniel Pocock wrote:
> 
> I notice that the spec file installs apr*config to bindir
> 
> Makefile.in declares the filename:
> APR_CONFIG = apr-$(APR_MAJOR_VERSION)-config
> 
> However, on an x86_64 platform, it may be necessary to install both 32
> and 64 bit packages concurrently.
> 
> On RHEL, the 64 bit libraries can go under prefix/lib64 instead of
> prefix/lib, using the macro %_lib in the spec file.  On Debian amd64,
> the 32 bit libraries can go under a lib32 directory.
> 
> The only thing that seems out of place is apr-1-config, as there is no
> bin64 or bin32 directory.  If the 32 bit and 64 bit packages are
> installed concurrently, then one of them overwrites the other's
> apr-1-config.

Right... but when you're parallel-installing i386 libraries on an amd64
system, you usually install *only the libraries*, not the rest of the
files the package would install, so there's no problem... is there?

IIUC, actually building complex assemblies of i386 software on an amd64
host would generally require a chroot?

Max.