Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 442548 - sys-devel/gcc: doesn't build n32 libraries in n64 mips multilib config
Summary: sys-devel/gcc: doesn't build n32 libraries in n64 mips multilib config
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: MIPS Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 477956
  Show dependency tree
 
Reported: 2012-11-10 05:51 UTC by Matt Turner
Modified: 2022-05-11 01:58 UTC (History)
2 users (show)

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


Attachments
gcc-4.6.3-n64.log.gz (gcc-4.6.3-n64.log.gz,219.64 KB, application/x-gzip)
2012-11-10 05:51 UTC, Matt Turner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Turner gentoo-dev 2012-11-10 05:51:06 UTC
Created attachment 329062 [details]
gcc-4.6.3-n64.log.gz

When building gcc with a default/linux/mips/10.0/mipsel/multilib/n64 profile, I expect gcc and other executables to be n64 ABI binaries and for o32, n32, and n64 libraries to be built, such as crt*.o and libgcc_s.so.

Instead, configure prints 'Running configure in multilib subdirs 32 64' and then only o32 and n64 libraries are built, leaving out n32.

It looks like the libraries gcc installs in /usr/lib/gcc/$CHOST/$GCC_VER/ are the default ABI. On n32 profiles, n32 libraries are installed here, but on other multilib profiles the build system doesn't make any special effort to build n32 libs, so they're left out.
Comment 1 SpanKY gentoo-dev 2012-11-11 21:39:11 UTC
when you see "Running configure in multilib subdirs 32 64", it's talking about the subdirs being built, not the main dir.  so the fact it doesn't list all three isn't a bug in and of itself.

the problem is that the configure logic doesn't appear to handle --with-abi correctly.  it does change the default abi to match that flag, but it doesn't shuffle the subdirs accordingly.  it actually ends up building n64 twice -- once in the toplevel and again in the subdir.
Comment 2 Matt Turner gentoo-dev 2012-11-13 04:40:41 UTC
(In reply to comment #1)
> the problem is that the configure logic doesn't appear to handle --with-abi
> correctly.  it does change the default abi to match that flag, but it
> doesn't shuffle the subdirs accordingly.  it actually ends up building n64
> twice -- once in the toplevel and again in the subdir.

To clarify, is that a problem with gcc's configure logic or with toolchain.eclass? I can't see much in toolchain.eclass that seems related, but it's also surprising that gcc's configure logic could be broken like this.
Comment 3 SpanKY gentoo-dev 2012-11-13 05:31:36 UTC
(In reply to comment #2)

afaict, it's a bug in the gcc build system.  just grab gcc-4.7.2 and build it with these keep bits of info:
 --target=mips64el-unknown-linux-gnu
 --enable-multilib
 --with-abi=64
Comment 4 Matt Turner gentoo-dev 2012-12-03 21:20:15 UTC
Talking with Andrew Pinski:

<pinskia> MULTILIB_OPTIONS/MULTILIB_DIRNAMES don't depend on the --with-abi option as far as I can tell
<pinskia> also I think --with-abi= does not set the default one
<pinskia> MIPS_ABI_DEFAULT in config.gcc is not changed by that option
<pinskia> that might be the bug really :)
Comment 5 Joshua Kinard gentoo-dev 2017-07-17 08:56:17 UTC
Does this bug still look relevant on gcc-6.3.0?  Checking a recent stage run I did for multilib/mips3, I have this for gcc-6.3.0:

# file usr/lib/gcc/mips64-unknown-linux-gnu/6.3.0/libgcc_s.so.1
usr/lib/gcc/mips64-unknown-linux-gnu/6.3.0/libgcc_s.so.1: ELF 32-bit MSB shared object, MIPS, N32 MIPS-III version 1 (SYSV), dynamically linked, stripped

# file usr/lib/gcc/mips64-unknown-linux-gnu/6.3.0/64/libgcc_s.so.1
usr/lib/gcc/mips64-unknown-linux-gnu/6.3.0/64/libgcc_s.so.1: ELF 64-bit MSB shared object, MIPS, MIPS-III version 1 (SYSV), dynamically linked, stripped

# file usr/lib/gcc/mips64-unknown-linux-gnu/6.3.0/32/libgcc_s.so.1
usr/lib/gcc/mips64-unknown-linux-gnu/6.3.0/32/libgcc_s.so.1: ELF 32-bit MSB shared object, MIPS, MIPS-III version 1 (SYSV), dynamically linked, stripped

It looks like gcc is building the main binaries/libs as N32, and then creating separate libraries for N64 and O32, not defaulting to N64 and then doing N32/O32.  So it seems like this might be fixed, just in a different fashion?
Comment 6 Matt Turner gentoo-dev 2017-09-04 22:57:10 UTC
(In reply to Joshua Kinard from comment #5)
> Does this bug still look relevant on gcc-6.3.0?  Checking a recent stage run
> I did for multilib/mips3, I have this for gcc-6.3.0:

Was it a n64/multilib stage? When the default ABI is n32, everything matches what you said. This bug is specifically about when the default ABI is n64.
Comment 7 Joshua Kinard gentoo-dev 2018-04-01 06:48:26 UTC
(In reply to Matt Turner from comment #6)
> (In reply to Joshua Kinard from comment #5)
> > Does this bug still look relevant on gcc-6.3.0?  Checking a recent stage run
> > I did for multilib/mips3, I have this for gcc-6.3.0:
> 
> Was it a n64/multilib stage? When the default ABI is n32, everything matches
> what you said. This bug is specifically about when the default ABI is n64.

No, was a multilib/n32 build.