Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 647612 - sys-devel/multilib-gcc-wrapper lacks ld,ar, ranlib etc. wrappers
Summary: sys-devel/multilib-gcc-wrapper lacks ld,ar, ranlib etc. wrappers
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Michał Górny
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-14 16:09 UTC by Joakim Tjernlund
Modified: 2019-11-20 19:39 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joakim Tjernlund 2018-02-14 16:09:58 UTC
Wanting to create i686-pc-linux-gnu wrappers which I can pass to
configure etc. I installed sys-devel/multilib-gcc-wrapper but
this package only has gcc wrappers, no binutils wrappers.
How can I get the missing binutils wrapppers ?
Comment 1 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-02-15 18:17:31 UTC
What are you trying to achieve? The main purpose of multilib-gcc-wrappers is to provide executables for i686 distcc host on amd64.
Comment 2 Joakim Tjernlund 2018-02-16 15:01:52 UTC
I want to pass i686-pc-linux-gnu to configure in our own code so configure
understands that it should build 32 bits.
Just passing -m32 in CFLAGS does work.
Comment 3 Ian Stakenvicius gentoo-dev 2018-02-16 15:10:17 UTC
To do that I believe you need to set up a crossdev.
Comment 4 Joakim Tjernlund 2018-02-16 15:20:44 UTC
(In reply to Ian Stakenvicius from comment #3)
> To do that I believe you need to set up a crossdev.

Not in this case, we wnat to build part of our embedded app on host
for running some test/simulation. All deps are there and previously we
just built with -m32 flag and got away with that.
Now we got a dep in configure so we need to tell it to not
assume 64 bits from host.

Does not distcc also need 32 bits linker etc. ?
Comment 5 Ian Stakenvicius gentoo-dev 2018-02-16 15:24:28 UTC
distcc only handles compilation, and in "pump" mode, preprocessing.  Everything else, including linking, occurs on the original system.  'man distcc' for more details.
Comment 6 Joakim Tjernlund 2018-02-16 15:30:33 UTC
(In reply to Ian Stakenvicius from comment #5)
> distcc only handles compilation, and in "pump" mode, preprocessing. 
> Everything else, including linking, occurs on the original system.  'man
> distcc' for more details.

OK, but only creating wrappers for gcc is incomplete, ld etc. should
be included too IMHO.
Comment 7 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-02-16 16:47:46 UTC
Well, I don't see a major problem adding more symlinks. However, I'm wondering if they really belong here or maybe rather in a separate multilib-binutils-wrapper package.
Comment 8 Joakim Tjernlund 2018-02-20 08:30:52 UTC
(In reply to Michał Górny from comment #7)
> Well, I don't see a major problem adding more symlinks. However, I'm
> wondering if they really belong here or maybe rather in a separate
> multilib-binutils-wrapper package.

Got sidetracked and almost forgot to comment, sorry.

From a user POV I would prefer a single package to install all
scripts. I would not object if there were 2 packages though should
that make more sense from a impl. POV.
Comment 9 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-03-14 14:29:31 UTC
I'm still not convinced this is a good idea. Which tools should we cover?

ld is kinda implicit. But we should we also wrap ld.bfd and ld.gold? Should sys-devel/lld start providing CHOST-prefixed executables? We normally don't expect tools to be calling linker directly, and instead gcc/clang to pass appropriate emulation to the linker.

Then, do we need to wrap ar, ranlib? Do we need to pass any options to them, or creating dumb symlinks would be enough?

What about dlltool? What about as? All those tools have some potential interest for being prefixed, and all of them have completely different target options that we don't have stored anywhere.
Comment 10 Joakim Tjernlund 2019-11-20 19:39:04 UTC
(In reply to Michał Górny from comment #9)
> I'm still not convinced this is a good idea. Which tools should we cover?
> 
> ld is kinda implicit. But we should we also wrap ld.bfd and ld.gold? Should
> sys-devel/lld start providing CHOST-prefixed executables? We normally don't
> expect tools to be calling linker directly, and instead gcc/clang to pass
> appropriate emulation to the linker.
> 
> Then, do we need to wrap ar, ranlib? Do we need to pass any options to them,
> or creating dumb symlinks would be enough?
> 
> What about dlltool? What about as? All those tools have some potential
> interest for being prefixed, and all of them have completely different
> target options that we don't have stored anywhere.

The same as crossdev creates I think:
powerpc-g2.20-linux-gnu-addr2line       powerpc-g2.20-linux-gnu-g++             powerpc-g2.20-linux-gnu-ld.bfd
powerpc-g2.20-linux-gnu-ar              powerpc-g2.20-linux-gnu-g++-4.9.3       powerpc-g2.20-linux-gnu-ld.gold
powerpc-g2.20-linux-gnu-as              powerpc-g2.20-linux-gnu-gcc             powerpc-g2.20-linux-gnu-nm
powerpc-g2.20-linux-gnu-c++             powerpc-g2.20-linux-gnu-gcc-4.9.3       powerpc-g2.20-linux-gnu-objcopy
powerpc-g2.20-linux-gnu-c++-4.9.3       powerpc-g2.20-linux-gnu-gcc-ar          powerpc-g2.20-linux-gnu-objdump
powerpc-g2.20-linux-gnu-c++filt         powerpc-g2.20-linux-gnu-gcc-nm          powerpc-g2.20-linux-gnu-pkg-config
powerpc-g2.20-linux-gnu-cpp             powerpc-g2.20-linux-gnu-gcc-ranlib      powerpc-g2.20-linux-gnu-ranlib
powerpc-g2.20-linux-gnu-cpp-4.9.3       powerpc-g2.20-linux-gnu-gcov            powerpc-g2.20-linux-gnu-readelf
powerpc-g2.20-linux-gnu-dwp             powerpc-g2.20-linux-gnu-gcov-4.9.3      powerpc-g2.20-linux-gnu-run
powerpc-g2.20-linux-gnu-ebuild          powerpc-g2.20-linux-gnu-gdb             powerpc-g2.20-linux-gnu-size
powerpc-g2.20-linux-gnu-elfedit         powerpc-g2.20-linux-gnu-gfortran        powerpc-g2.20-linux-gnu-strings
powerpc-g2.20-linux-gnu-embedspu        powerpc-g2.20-linux-gnu-gfortran-4.9.3  powerpc-g2.20-linux-gnu-strip
powerpc-g2.20-linux-gnu-emerge          powerpc-g2.20-linux-gnu-gprof           
powerpc-g2.20-linux-gnu-fix-root        powerpc-g2.20-linux-gnu-ld