| Summary: | sys-devel/multilib-gcc-wrapper lacks ld,ar, ranlib etc. wrappers | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Joakim Tjernlund <joakim.tjernlund> |
| Component: | Current packages | Assignee: | Michał Górny <mgorny> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | dschridde+gentoobugs, multilib+disabled |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=617776 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Joakim Tjernlund
2018-02-14 16:09:58 UTC
What are you trying to achieve? The main purpose of multilib-gcc-wrappers is to provide executables for i686 distcc host on amd64. 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. To do that I believe you need to set up a crossdev. (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. ? distcc only handles compilation, and in "pump" mode, preprocessing. Everything else, including linking, occurs on the original system. 'man distcc' for more details. (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. 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. (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. 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. (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 |
