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 attachment 77151 [details, diff] 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 attachment 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 attachment 77154 [details, diff] generate-wrapper-config call in prepall
Created attachment 77534 [details, diff] patch to make ebuild.sh call the wrapper-generator some bugsfixes
Created attachment 77535 [details] new generate-config-wrapper some bugfixes and error checking
Created attachment 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 attachment 78799 [details, diff] 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 attachment 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 attachment 78858 [details, diff] ebuild.sh patch Thanks Brian, all issues addressed now :)
Created attachment 78859 [details] generate-config-wrapper
Created attachment 81990 [details, diff] 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 attachment 82310 [details, diff] 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 attachment 82955 [details, diff] multilib-wrappers.patch the last patch doesn't apply to trunk anymore (since r2973), this one does though
LATER
