Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 75420 - [TRACKER] eradicator's massive multilib bug
Summary: [TRACKER] eradicator's massive multilib bug
Status: RESOLVED WONTFIX
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Conceptual/Abstract Ideas (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords: Tracker
Depends on:
Blocks:
 
Reported: 2004-12-23 01:38 UTC by Jeremy Huddleston (RETIRED)
Modified: 2017-01-19 18:47 UTC (History)
13 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
patch of portage/bin to use LIBDIR_${ABI} instead of CONF_LIBDIR if it is defined (portage-bin-multilib.patch,2.04 KB, patch)
2004-12-23 01:40 UTC, Jeremy Huddleston (RETIRED)
Details | Diff
gcc-wrapper-multilib.patch (gcc-wrapper-multilib.patch,3.40 KB, patch)
2004-12-24 01:23 UTC, Jeremy Huddleston (RETIRED)
Details | Diff
FEATURES=distcc patch to ebuild.sh for CFLAGS_${ABI} (ebuild.sh-distcc-multilib.patch,722 bytes, patch)
2004-12-24 20:31 UTC, Jeremy Huddleston (RETIRED)
Details | Diff
updated libdir patch for current portage/bin (libdir-portage.patch,2.10 KB, patch)
2004-12-31 03:15 UTC, Jeremy Huddleston (RETIRED)
Details | Diff
FEATURES=multilib-pkg patch (RFC) (portage-multilibpkg.patch,7.46 KB, patch)
2005-01-03 00:01 UTC, Jeremy Huddleston (RETIRED)
Details | Diff
FEATURES=multilib-pkg patch (RFC) (portage-multilibpkg.patch,8.31 KB, patch)
2005-01-03 00:38 UTC, Jeremy Huddleston (RETIRED)
Details | Diff
updated FEATURES=multilib-pkg patch (portage-multilibpkg.patch,13.72 KB, patch)
2005-01-04 00:39 UTC, Jeremy Huddleston (RETIRED)
Details | Diff
FEATURES=multilib-strict patch (portage-multilib-strict.patch,979 bytes, patch)
2005-01-04 23:59 UTC, Jeremy Huddleston (RETIRED)
Details | Diff
FEATURES=multilib-pkg patch (portage-multilibpkg.patch,14.44 KB, patch)
2005-01-07 02:56 UTC, Jeremy Huddleston (RETIRED)
Details | Diff
distcc-gentoo-multilib.patch.patch (distcc-gentoo-multilib.patch.patch,394 bytes, patch)
2005-01-14 12:28 UTC, Sven Wegener
Details | Diff
portage-multilib-strict-exempt.patch (portage-multilib-strict-exempt.patch,988 bytes, patch)
2005-01-21 14:21 UTC, Jeremy Huddleston (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Huddleston (RETIRED) gentoo-dev 2004-12-23 01:38:37 UTC
Ok, so I've decided to setup a tracker bug to deal with multilib related issues in portage and toolchain... it's mostly portage related, but toolchain is on CC so they can follow and make comments.

To sumarize my last email to dev-portage and toolchain, I hope to alter the multilib setup in portage to use a list of supported ABIs, and each ABI has CFLAGS, LIBDIR, etc assigned which are required to build for that ABI.  See default-linux/sparc/sparc64-multilib/dev/make.defaults for an example.

I have committed a change to eutils.eclass to make use of this new approach (if it's not sparc64-multilib, then the old approach is used), and I am testing a glibc ebuild which makes use of this functionality to emerge both 32bit and 64bit versions at the same time.

Things I've noticed since my last mail to dev-portage and toolchain:
It would be best if the ${CC} exported to ebuild.sh was "${CHOST}-gcc $(eval echo \${CFLAGS_${ABI}})" rather than "${CHOST}-gcc" (and likewise for ${CXX})  This is because the build process of many packages (like glibc) use ${CC} but ignore ${CFLAGS} for some things (like "$(CC) --print-file-name=crtbegin.o" for instance).  The abi's cflags (eg: -m32) need to be passed in to get the right crtbegin.o.

I've also updated some portage/bin scripts that use CONF_LIBDIR to use LIBDIR_${ABI} if it is defined.  I'll attach the patch.
Comment 1 Jeremy Huddleston (RETIRED) gentoo-dev 2004-12-23 01:40:08 UTC
Created attachment 46698 [details, diff]
patch of portage/bin to use LIBDIR_${ABI} instead of CONF_LIBDIR if it is defined

Here's the patch I mentioned which applies to current cvs to use LIBDIR_${ABI}
if it defined over CONF_LIBDIR in the portage/bin scripts (econf, dolib, and
preplib)
Comment 2 Jeremy Huddleston (RETIRED) gentoo-dev 2004-12-24 01:23:24 UTC
Created attachment 46769 [details, diff]
gcc-wrapper-multilib.patch

Here's one for toolchain (specifically lv when he gets back):

I modified the gcc wrapper to honor the ${ABI} and ${CFLAGS_${ABI}} environment
variables.  Also, I rolled support for (${CHOST}-)?g{cc,++}{32,64} into
wrapper.c as I saw that was on the todo list.

To show that it works:

(01:17:26 Fri Dec 24 2004 root@aeris sparc64)
~ $ export ABI="sparc64" && gcc a.c -o a.64 && file a.64
a.64: ELF 64-bit MSB executable, SPARC V9, version 1 (SYSV), for GNU/Linux
2.0.0, dynamically linked (uses shared libs), not stripped

(01:17:34 Fri Dec 24 2004 root@aeris sparc64)
~ $ export ABI="sparc32" && gcc a.c -o a.32  && file a.32
a.32: ELF 32-bit MSB executable, SPARC32PLUS, V8+ Required, version 1 (SYSV),
for GNU/Linux 2.0.0, dynamically linked (uses shared libs), not stripped

(01:17:45 Fri Dec 24 2004 root@aeris sparc64)
~ $ echo $CFLAGS_sparc32
-m32

(01:17:52 Fri Dec 24 2004 root@aeris sparc64)
~ $ echo $CFLAGS_sparc64
-m64
Comment 3 Jeremy Huddleston (RETIRED) gentoo-dev 2004-12-24 20:31:08 UTC
Created attachment 46850 [details, diff]
FEATURES=distcc patch to ebuild.sh for CFLAGS_${ABI}

here's a patch to ebuild.sh to honor CFLAGS_${ABI} if it is set for calling
distcc
Comment 4 SpanKY gentoo-dev 2004-12-24 20:34:07 UTC
umm, wouldnt it be a lot easier to have portage just append the appropriate CFLAGS_ABI onto CFLAGS ?
Comment 5 Jeremy Huddleston (RETIRED) gentoo-dev 2004-12-24 21:05:50 UTC
vapier: Please see my initial comment... In theory, yes it would be prettier to just append ${CFLAGS_<ABI>}, and that's what I originally tried, but that would be good if GCC always used CFLAGS.  It doesn't.  the problem is many packages ignore CFLAGS for simple things (and some do entirely).  As an example, glibc required a 10K patch (23 hunks) to add in the $CFLAGS_<ABI> where it ignored CFLAGS.  It took me 2 days to track down all the problems.  As an alternative, I just tried CC="$(tc-getCC) ${CGLAGS_ABI}" and all was well.  This approach makes the toolchain always honor $CFLAGS_<ABI>, it's straightforward, and it avoids manhours in tracking down instances where packages don't honor CFLAGS and forcing them to.

Comment 6 Jeremy Huddleston (RETIRED) gentoo-dev 2004-12-27 21:33:36 UTC
Comment on attachment 46769 [details, diff]
gcc-wrapper-multilib.patch

I've talked to lv in #-dev today and this has been committed to gcc-config.
Comment 7 Jeremy Huddleston (RETIRED) gentoo-dev 2004-12-27 21:37:30 UTC
Comment on attachment 46850 [details, diff]
FEATURES=distcc patch to ebuild.sh for CFLAGS_${ABI}

Setting this to obsolete.  I think the prefered option is to patch distcc like
the gcc wrapper was patched.
Comment 8 Jeremy Huddleston (RETIRED) gentoo-dev 2004-12-28 01:08:58 UTC
Ok, I've got a distcc patch all made up, and I included it in portage, but it's commented out of the ebuild pending lisa's approval.  Lisa, could you check it out, and if it looks good uncomment the epatch line in the ebuild?  The code is pretty much identical to what went into the gcc wrapper.

And here's proof it works:
(01:06:20 Tue Dec 28 2004 jeremy@cid x86_64)
~/tmp $ export CFLAGS_x86="-m32"

(01:06:27 Tue Dec 28 2004 jeremy@cid x86_64)
~/tmp $ export CFLAGS_amd64="-m64"

(01:06:30 Tue Dec 28 2004 jeremy@cid x86_64)
~/tmp $ export ABI="x86" && distcc gcc bad.c && file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.5, dynamically linked (uses shared libs), not stripped

(01:06:39 Tue Dec 28 2004 jeremy@cid x86_64)
~/tmp $ export ABI="amd64" && distcc gcc bad.c && file a.out
a.out: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.5, dynamically linked (uses shared libs), not stripped

(01:06:47 Tue Dec 28 2004 jeremy@cid x86_64)
~/tmp $ export ABI="x86" && /usr/lib/distcc/bin/gcc bad.c && file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.5, dynamically linked (uses shared libs), not stripped

(01:07:33 Tue Dec 28 2004 jeremy@cid x86_64)
~/tmp $ export ABI="amd64" && /usr/lib/distcc/bin/gcc bad.c && file a.out
a.out: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.5, dynamically linked (uses shared libs), not stripped
Comment 9 SpanKY gentoo-dev 2004-12-28 17:06:47 UTC
ive taken the ABI changes out of 1.3.8 and put them into 1.3.9

i want 1.3.8 to go stable and it seems fine thus far ... introducing ABI stuff into 1.3.8 would prevent a new clean stable tree
Comment 10 Jeremy Huddleston (RETIRED) gentoo-dev 2004-12-31 03:15:06 UTC
Created attachment 47272 [details, diff]
updated libdir patch for current portage/bin

Here's an updated patch which doesn't fork off an 'eval echo'
Comment 11 Lisa Seelye (RETIRED) gentoo-dev 2004-12-31 13:46:48 UTC
committed
Comment 12 Jason Stubbs (RETIRED) gentoo-dev 2005-01-02 01:36:38 UTC
Added to portage_2_0.
Comment 13 Jeremy Huddleston (RETIRED) gentoo-dev 2005-01-03 00:01:43 UTC
Created attachment 47436 [details, diff]
FEATURES=multilib-pkg patch (RFC)

Ok, this isn't meant to be included in portage yet, but I've reached a
milestone, so I'd like comments from anyone who has any thoughts regarding this
.  Also, I intentionally left out some indents in dyn_unpack() to make the
patch more readable... I'll of course add them in in a final patch.

This patch adds a new FEATURE to portage called 'multilib-pkg'	With it
enabled, some packages in the tree (currently none) will install libs for all
the ABIs in ${MULTILIB_ABIS}.  Additionally, the ebuild can control which ABIs
are allowed using the ${ABI_ALLOW} and ${ABI_DENY} variables which have the
expected logic.  These can be set in pkg_setup() for things like
'USE=win32codecs emerge mplayer' on amd64.

And to show it off, I tested it out on zlib:

(23:47:31 Sun Jan 02 2005 root@aeris sparc64)
~ $ file /lib/libz.so.1.2.2 
/lib/libz.so.1.2.2: ELF 32-bit MSB shared object, SPARC32PLUS, V8+ Required,
version 1 (SYSV), stripped

(23:47:57 Sun Jan 02 2005 root@aeris sparc64)
~ $ file /lib64/libz.so.1.2.2 
/lib64/libz.so.1.2.2: ELF 64-bit MSB shared object, SPARC V9, version 1 (SYSV),
stripped

You need to add RESTRICT="multilib-pkg" to the zlib ebuild to get it to emerge
both libs using this patch.

I'm not really keen on RESTRICT="multilib-pkg" as it's not really a RESTRICTion
... but I don't think we need variable bloat either to add another flag to
ebuilds, so any suggestions on that are more than welcome.

I'll also be adding a debugging FEATURE 'multilib-strict' which will cause the
emerge to die if a binary of an invalid ABI ends up in /lib, /usr/lib, or
/usr/X11R6/lib
Comment 14 Jeremy Huddleston (RETIRED) gentoo-dev 2005-01-03 00:38:07 UTC
Created attachment 47440 [details, diff]
FEATURES=multilib-pkg patch (RFC)

Fixed a couple bugs:
Missed escaping a new line
reset DEST and umask for each run through src_install...
Comment 15 Jeremy Huddleston (RETIRED) gentoo-dev 2005-01-04 00:39:17 UTC
Created attachment 47558 [details, diff]
updated FEATURES=multilib-pkg patch

Yet another step closer...

This should make it easier on packages which do things like 'AR="$(tc-getAR)
rc"' in src_compile.  With the previous patch, subsequent calls to src_compile
would result in AR="${CHOST}-ar rc rc"	Now, we save/restore the environment
for each ABI separately.  It's not quite optimized yet, but the logic is
there...
Comment 16 Jeremy Huddleston (RETIRED) gentoo-dev 2005-01-04 23:59:01 UTC
Created attachment 47684 [details, diff]
FEATURES=multilib-strict patch

Here's a patch to help finding packages which don't honor libdir properly. 
Users can set FEATURES=multilib-strict and report back when packages try
installing libs into the wrong directory.  Profiles can set the following to
take advantage of this:

MULTILIB_STRICT_DIRS="/lib /usr/lib /usr/kde/*/lib /usr/qt/*/lib
/usr/X11R6/lib"
MULTILIB_STRICT_DENY="64-bit"

Note, this can be used in current profiles and doesn't require the new multilib
setup, so current users can start helping us by using this.  The
MULTILIB_STRICT_DENY is simply passed to egrep on the result of 'file <file>'
for everything in the MULTILIB_STRICT_DIRS.  If the egrep passes, we die.
Comment 17 Jeremy Huddleston (RETIRED) gentoo-dev 2005-01-07 02:56:35 UTC
Created attachment 47826 [details, diff]
FEATURES=multilib-pkg patch

Cleaned up a bit...

optimized the unset portion of the env-switching to just unset everything then
source the old env with the option of setting FEATURES=multilib-debug to use
the old behavior and see what is being unset.

Handle aborted src_{unpack,compile,test,install} better.

Move 'true' to the end of dyn_clean as that was overlooked in a recent patch
(jstubbs, you probably want to fix that part before -r9...)

Applies cleanly against current cvs again...
Comment 18 Jeremy Huddleston (RETIRED) gentoo-dev 2005-01-13 00:56:23 UTC
Comment on attachment 47272 [details, diff]
updated libdir patch for current portage/bin

marking obsolete as it's in a release now
Comment 19 Jeremy Huddleston (RETIRED) gentoo-dev 2005-01-13 00:56:43 UTC
Comment on attachment 47684 [details, diff]
FEATURES=multilib-strict patch

marking obsolete as it's in a release now
Comment 20 Sven Wegener gentoo-dev 2005-01-14 12:28:21 UTC
Created attachment 48489 [details, diff]
distcc-gentoo-multilib.patch.patch

The distcc multilib patch needs a little update. It uses unitialized variables
which lead to breakage, at least for me. If I emerge distcc with
-fomit-frame-pointer in CFLAGS, executing /usr/lib/distcc/bin/gcc will result
in exit code 105 i.e. "Out of memory."

newflagsCount is the only one used unitialized, all others have an assignment
later in the code.
Comment 21 Jeremy Huddleston (RETIRED) gentoo-dev 2005-01-14 14:17:29 UTC
Comment on attachment 48489 [details, diff]
distcc-gentoo-multilib.patch.patch

incvs, thanks.
Comment 22 Jeremy Huddleston (RETIRED) gentoo-dev 2005-01-21 14:21:15 UTC
Created attachment 49143 [details, diff]
portage-multilib-strict-exempt.patch

Please apply:
Applies against current cvs (portage_2_0)

This adds another option to multilib-strict (and sets a default for it) which
allows exemptions.  This is neccessary for perl modules and gcc which take care
of their own abi separation using subdirs (/usr/lib/perl5/5.8.6/x86_64-linux
for example).
Comment 23 Heinrich Wendel (RETIRED) gentoo-dev 2005-02-16 07:18:16 UTC
in portage-2.0.51-r16 $(get_libdir) returns lib, but it should return lib64 (amd64-2005.0 profile
Comment 24 Jeremy Huddleston (RETIRED) gentoo-dev 2005-02-16 10:24:21 UTC
lanius: Can youu show me where it's doing this?  I just threw 'einfo $(get_libdir)' into src_unpack of zlib's ebuild to test it, and it printed out lib64.  Please come talk to me on IRC.
Comment 25 Heinrich Wendel (RETIRED) gentoo-dev 2005-02-17 08:37:25 UTC
eradicator: try this in bash:

source /sbin/functions.sh; echo $(get_libdir)
Comment 26 Jeremy Huddleston (RETIRED) gentoo-dev 2005-02-17 11:12:40 UTC
lanius.  ok, I'll take a look at that later, but what actually uses that?
Comment 27 Heinrich Wendel (RETIRED) gentoo-dev 2005-02-17 11:54:13 UTC
init script may use it top find out the correct lib directory, i'm currently working on motif-config that needs it, don't know about java-config or gcc-config, or similar tools
Comment 28 Jeremy Huddleston (RETIRED) gentoo-dev 2005-02-17 12:58:57 UTC
I know gcc-config and opengl-update don't use it.

The libdir needs to be configured into the init script.  Using get_libdir() in /sbin/functions.sh assumes that on any given system, the same libdir is always used.  That is an incorrect assumption as get_libdir() will change based on the ${ABI}.  So, we need to go through the tree and figure out who is using that when they shouldn't be.  Do you have a list of scripts you know who use it?
Comment 29 Danny van Dyk (RETIRED) gentoo-dev 2005-02-17 15:39:31 UTC
I added it to functions.sh some months ago to get {blas,lapack}-config working on amd64-multilib. Might be that it's not quite up to date with current multilib...
Comment 30 Jeremy Huddleston (RETIRED) gentoo-dev 2005-02-18 04:08:44 UTC
it's not a matter of being up to date or not... it's simply that that it can't work.  You're essentially assuming that get_libdir will always be the same for every package on the system, but that is not the case.  You can have a 32bit version of mplayer installed (get_libdir=lib) and a 64bit version of xine installed (get_libdir=lib64).  Granted these aren't the best examples, but I'm trying to illustrate that the correct logic would be to do something like this in the ebuild:

dosed "s:@@LIBDIR@@:$(get_libdir):" /etc/conf.d/myconf
Comment 31 Heinrich Wendel (RETIRED) gentoo-dev 2005-02-18 05:27:19 UTC
Sounds reasonable. So get_libdir should be removed from functions.sh completly, right?
Comment 32 Jeremy Huddleston (RETIRED) gentoo-dev 2005-02-18 10:01:57 UTC
yep.
Comment 33 Heinrich Wendel (RETIRED) gentoo-dev 2005-02-19 12:37:14 UTC
So Danny, please fix {blas,lapack}-config
Comment 34 Jeremy Huddleston (RETIRED) gentoo-dev 2005-03-13 18:24:26 UTC
Ok, looks like I've hit a snag in some multilib stuff thanks in part to gcc and in part to libtool.  Using the standarg auto*, liibtool build chain, libtool searches through the directories listed in `gcc -print-search-dirs`'s libraries section.  

To see this, just search for '$CC -print-search-dirs' in a configure script.  The problem is this always lists the base directory rather than the `gcc -print-multi-directory` subdirectory.  Thus if sparc32 is default, libtool needs to search through /usr/lib/gcc/sparc64-unknown-linux-gnu/3.4.3-20050110/32, but /usr/lib/gcc/sparc64-unknown-linux-gnu/3.4.3-20050110 is listed instead.  Thus, it notices the 64bit libstdc++.la instead of the 32bit one.  Deleting the .la files is a temporary fix as it just passes the -lstdc++ through to the linker, but I'd rather find a better solution to this problem...

gcc -m32 -print-search-dirs
Comment 35 Lisa Seelye (RETIRED) gentoo-dev 2005-03-19 07:44:30 UTC
did a bit of maintenance in the ebuild, please move to distcc-2.18.3-r5. ;)
Comment 36 Brian Harring (RETIRED) gentoo-dev 2005-05-10 22:29:20 UTC
Jeremy, if you get a chance could you dump something of an update to this bug regarding current support?
Comment 37 Jeremy Huddleston (RETIRED) gentoo-dev 2005-05-11 00:00:24 UTC
http://ramblings.hudscabin.com/blogs/index.php/2005/05/02/multilib_and_toolchain_thoughts

That's probably the best update I have for you. No patches for it yet... and I think it's best to shy away from the multilib-pkg approach... it's just an ugly hack...

but I think CHOST aliases might be in orded to make things easy... so if the user sets 'CHOST=amd64 emerge blah' portage/the profile should know to change it to CHOST=x86_64-pc-linux-gnu... but that's something for later...
Comment 38 sigloiv 2005-06-03 22:00:56 UTC
I'm just following the instructions while emerging 'distcc' (doesn't look like 
many did just from scanning the posts).

The patch worked fine.
Comment 39 Jeremy Huddleston (RETIRED) gentoo-dev 2005-08-14 15:00:03 UTC
closing this as multilib-pkg isn't the way to go, so it should be closed... blah.
Comment 40 Jack Kelly 2005-08-27 18:12:16 UTC
Started to emerge distcc, got this message:
 * Applying distcc-gentoo-multilib-r1.patch ...
 * Please report to bug #75420 success or failure of this patch.
Patched with no problems, I think. (Didn't error, at least)
Comment 41 Lisa Seelye (RETIRED) gentoo-dev 2006-04-04 06:07:55 UTC
(In reply to comment #39)
> closing this as multilib-pkg isn't the way to go, so it should be closed...
> blah.
> 

Can I remove distcc-2.18.3-r8 which had the multilib patch then?