Bugzilla Bug 118815

On multilib-arches like amd64, it should be possible to merge both 32bit and
64bit libraries. The problem we currently have is that -config scripts
installed by many libraries print out ABI-specific data which can't be
controlled, e.g.:

$ /usr/bin/glib-config --cflags
-I/usr/include/glib-1.2 -I/usr/lib64/glib/include

This would break any 32bit app trying to link against a 32bit glib, as it would
include /usr/lib64/glib/inlude instead of /usr/lib32/glib/include.

A work-around to this problem: the scripts must either be moved to different
locations or get different names. I suggest to use suffixes, as binaries should
stay in /usr/bin and not get moved to /usr/lib{32,64}, IMO.

Portage should make a copy of those scripts, so that e.g.

/usr/bin/glib-config can be used for stuff out of portage's scope
/usr/bin/glibc-config-{amd64,x86} could be used when calling from portage.

Then we could "overwrite" these scripts with a bash function that decides which
script is the right one for the particular ABI:

for configscript in /usr/bin/*-config ; do 
        eval "$(basename ${configscript})() { /usr/bin/$(basename
{configscript}-\$\{ABI\}) \$@ ; }"
done

Why should portage do this and not the relevant ebuilds?

This won't work for configure scripts.  They have hardcoded calls...
Either you have to wrap it with your own PATH indirection, or you have to hack
up the config scripts so that they support ABI directives.

he already said we'd over write the original one with a wrapper script ...

it'd be better if it pointed to a file like
/usr/lib/portage/bin/abi-wrapper-config  so that when we change our ABI
handling, we dont have to worry about stale config scripts ...

/usr/bin/booga-config -> /usr/lib/portage/bin/abi-wrapper-config
/usr/bin/booga-config-<ABI>

(In reply to comment #3)
> he already said we'd over write the original one with a wrapper script ...
> 
> it'd be better if it pointed to a file like
> /usr/lib/portage/bin/abi-wrapper-config  so that when we change our ABI
> handling, we dont have to worry about stale config scripts ...
> 
> /usr/bin/booga-config -> /usr/lib/portage/bin/abi-wrapper-config
> /usr/bin/booga-config-<ABI>
Agreed, I just don't think this is portages job- overhauling pkgconfig alone,
so everything works falls to to maintainers.  Perhaps bouncing the bug to
other's would've been ebtter...

the reason it was proposed to be done in portage is because it's much cleaner
to throw in a post-install hook in portage to do the change than to change
every single ebuild with installs a -config script

and we're not talking about pkgconfig here, that is related to .pc files

(In reply to comment #1)
> Why should portage do this and not the relevant ebuilds?

I think it is a much cleaner solution to add ~5 lines to portage than doing
ugly  hacks for every packages that supplies a config script.  Also, what if we
ever change our ABI handling? We would have to go and edit every ebuild again.
I'm not a friend of doing punctual patching if there is a nice global solution.

(In reply to comment #2)
> This won't work for configure scripts.  They have hardcoded calls...
> Either you have to wrap it with your own PATH indirection, or you have to hack
> up the config scripts so that they support ABI directives.

I doubt that, at least it was you who brought up that idea of overwriting the
real scripts with bash functions back in May 2005 when we discussed the issue
:P

(In reply to comment #3)
> it'd be better if it pointed to a file like
> /usr/lib/portage/bin/abi-wrapper-config  so that when we change our ABI
> handling, we dont have to worry about stale config scripts ...

That's true, seems far better to me :)

7am, pardon if chunks of this are insane..

(In reply to comment #6)
> (In reply to comment #1)
> > Why should portage do this and not the relevant ebuilds? 
> I think it is a much cleaner solution to add ~5 lines to portage than doing
> ugly  hacks for every packages that supplies a config script.  Also, what if we
> ever change our ABI handling? We would have to go and edit every ebuild again.
> I'm not a friend of doing punctual patching if there is a nice global solution.
Not denying a central solution would be cleaner, that said I'd like to see the
5 liner please.  This is not going to be a simple modification from everything
I know about this problem (it's been around as long as multilib has offhand).

> (In reply to comment #2)
> > This won't work for configure scripts.  They have hardcoded calls...
> > Either you have to wrap it with your own PATH indirection, or you have to hack
> > up the config scripts so that they support ABI directives.
> 
> I doubt that, at least it was you who brought up that idea of overwriting the
> real scripts with bash functions back in May 2005 when we discussed the issue
> :P
Try it- configure uses /bin/sh, which is going to lose your func definitions. 
No gurantee the configure script is using loose path lookups for the calls
also- definite possibility it's doing forced path lookups, thus bypassing the
function angle.

(In reply to comment #5)
> the reason it was proposed to be done in portage is because it's much cleaner
> to throw in a post-install hook in portage to do the change than to change
> every single ebuild with installs a -config script
How's this post install hook going to work?  Again, I'm not stating a _clean_
approach isn't desired, I'm just not seeing concrete details of how the clean
implementation is going to work (aside from it would be nice...).

> and we're not talking about pkgconfig here, that is related to .pc files
I'm talking about *config; if you're not talking about one of the major cases,
curious what exactly you're proposing be modified then.

Created an attachment (id=77151) [details]
generate-wrapper-config call in prepall

After a discussion with Brian on IRC it seems to a bad idea to use bash
functions, since they will get lost when ./configure and won't work when one
*-config script calls another. Instead, tweaking the scripts is required. This
patch simply calls a script 'generate-wrapper-config'.

Created an attachment (id=77152) [details]
generate-wrapper-config

I still think this should be handled through portage, there are simply too many
affected packages to justify an eclass for this.

Created an attachment (id=77154) [details]
generate-wrapper-config call in prepall

Created an attachment (id=77534) [details]
patch to make ebuild.sh call the wrapper-generator

some bugsfixes

Created an attachment (id=77535) [details]
new generate-config-wrapper

some bugfixes and error checking

Created an attachment (id=77537) [details]
generate-config-wrapper

sorry for the bugspam, i checked the script three times before commiting, but
didn't see that the ABI ordering is the wrong way around

Created an attachment (id=78799) [details]
ebuild.sh patch

this one should be the last version, giving the ebuild as much power as
possible, in case we're handling some strange config script

note that i've been running portage with these patches for quite some time now,
and the only ebuild that broke because of it was dev-php4/pecl-yaz, because it
sources yaz-config instead of using yaz-config --version to figure out the
installed version.

Created an attachment (id=78800) [details]
generate-config-wrapper

sample output:

 $ cat /usr/bin/python-config
#!/bin/bash
if [[ -n "${ABI}" ]] ; then
abi="${ABI}"
elif [[ -n "${DEFAULT_ABI}" ]] ; then
abi="${DEFAULT_ABI}"
elif [[ -f /usr/bin/python-config-amd64 ]] ; then
abi="amd64"
elif [[ -f /usr/bin/python-config-x86 ]] ; then
abi="x86"
fi

/usr/bin/python-config-${abi} ${@}

issues...

doesn't work with symlinks pointing at the wrapped script...

Also don't like the hardcoded paths; imo, it should abide by PATH lookups. 
Moving the script (sounds insane, but it occurs) will break it..

doesn't preserve quoting when calling the abi specific config ("$@" solves it).

Worry about the potential for a fork bomb here if someone did someone special
like symlinking an abi specific config to the main config; exec would negate
that (just would be rapid replacement rather then spawning of kids).

Created an attachment (id=78858) [details]
ebuild.sh patch

Thanks Brian, all issues addressed now :)

Created an attachment (id=78859) [details]
generate-config-wrapper

Created an attachment (id=81990) [details]
multilib-wrappers.patch

since pretty much everything got factored out to misc-functions.sh the old
patch didn't apply anymore. I used that opportunity and stole the gawk code
spanky used for QA_TEXTREL, so that MULTILIB_WRAPPER_IGNORE now supports regex
:)

Created an attachment (id=82310) [details]
multilib-wrappers.patch

solar asked that the whole multilib-cruft is only executed on multilib systems.
Also, the generated scripts are replaced with a simple symlink to
/usr/lib/portage/bin/abi-wrapper-config to avoid having to remerge all the
packages when the multilib behaviour changes.. should have done this long ago
:|

Created an attachment (id=82955) [details]
multilib-wrappers.patch

the last patch doesn't apply to trunk anymore (since r2973), this one does
though

LATER