[Bug tree-optimization/36439] [4.3 Regression] very long compile-time in PRE building gimp-plugin-registry
-- vapier at gentoo dot org changed: What|Removed |Added CC||toolchain at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36439 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain
Hector Oron writes: > Hello, > , and there is generally no need to install anything but libraries and headers into /usr/ -- so I don't think there is a pressing need to replicate a filesystem hierarchy standard below a triplet directory. >> >>> True, however, that is not a sufficient reason to not >>> move /usr/ to /usr/lib/ and /usr/include/ >>> if it means getting such support into the core Debian packaging tools. >> >> Indeed, however this makes building stuff without the packaging tools a lot >> harder -- for example I need to patch gcc to recognize these paths if I >> build gcc by hand. It might be a lot easier to have the packaging tools >> handle the "current" layout than to patch all the software that assumes >> that software is generally installed into "include" and "lib" dirs under a >> common prefix (such as most GNU software that uses the autoconf macros to >> find installed software). > > That's totally right and that is my point, I really think multiarch is > not well designed to fit into cross compiling. They (dpkg-core) might > want us to do extra work which will break our stuff. If gcc looks into the tripplet dirs by default then cross-compiling can just use the normal system directories. The sys-root would be / in that case. The common prefix "". > And as from the point of view of multiarch we probably have a nice, > simple and working solution right now, without even notice it. The only > reason I found against our approach is: > > " > Why not prefix/arch-os/lib/ (and include/)? > It would pollute the prefix directory. Can you imagine adding one entry > for each target to the root and /usr directories? Better that they go > under the prefix/lib/ (and include/) directories which already contain > many files. " > > Which in practice it is not so bad to do all the extra work that > multiarch needs to get done. > > Please correct me if I am wrong You are wrong. :) The toolchain does not yet look in all the right places. Neither for the multiarch nor the corss-compile way of putting the prefix. It is in a state where both ways are used and neither is complete enough for a full system. MfG Goswin -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain
Simon Richter writes: > Hi, > >> >, since >> > they have entirely different objectives > >> Not entirely different - the objective for the packaging tools is >> actually the same, to have packages install cleanly without changes on >> systems with a different architecture triplet. > > I'm not sure this can be achieved at all, as we still need a root > filesystem that isn't prefixed with the architecture triplet. Why? At least libraries are just fine in the triplet dirs. As said binaries should not move. For cross-building dpkg-cross can move them during unpacking if that is needed. > The other issue is that generally, the 32/64 bit distinction does not > necessarily mean that we use a different triplet. i386/amd64 does, at least > in Debian, but that is optional as well and could be changed in the gcc > package, which would give us a situation where only clearly incompatible > arches need to be installed into a triplet directory. Then change the triplets. Having binary files for multiple architectures in the same triplet dirs works neither for multiarch nor cross-building. >> >, and there is generally no need to >> > install anything but libraries and headers into /usr/ -- so I >> > don't think there is a pressing need to replicate a filesystem hierarchy >> > standard below a triplet directory. > >> True, however, that is not a sufficient reason to not >> move /usr/ to /usr/lib/ and /usr/include/ >> if it means getting such support into the core Debian packaging tools. > > Indeed, however this makes building stuff without the packaging tools a lot > harder -- for example I need to patch gcc to recognize these paths if I > build gcc by hand. It might be a lot easier to have the packaging tools > handle the "current" layout than to patch all the software that assumes > that software is generally installed into "include" and "lib" dirs under a > common prefix (such as most GNU software that uses the autoconf macros to > find installed software). > >Simon The current layout does not result in a bootable system. We do need /arch-os-libc/lib/ and then stuff already needs patching. Also current setup is: % ldconfig -v | grep : /usr/lib/i486-linux-gnu: /usr/local/lib: /lib/x86_64-linux-gnu: /usr/lib/x86_64-linux-gnu: /lib: /lib32: /usr/lib: /usr/lib32: /usr/lib32/i586: (hwcap: 0x0004) /usr/lib32/i486: (hwcap: 0x0002) /usr/lib32/i686: (hwcap: 0x0008) /usr/lib32/i686/cmov: (hwcap: 0x00088000) ldconfig has no idea about cross-compile dirs. And someone suggested they should be system dirs hardcoded into the binary and not via conffiles. MfG Goswin -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain
Hello, > The toolchain does not yet look in all the right places. Neither for > the multiarch nor the corss-compile way of putting the prefix. It is > in a state where both ways are used and neither is complete enough for > a full system. So, would it be fine to send an addendum to multiarch[1] document taking into account cross environments? In case, we write up that file, preferred way for cross environments would be a sysroot , where in multiarch do we fit our cross ? Or we should just go for the splitted /* option (which won't be useful until multiarch is ready) ? >From cross toolchain point of view, i would suggest to stay with upstream maintainers layout, which would require a change on dpkg-cross, moving /include into /usr/include, that way we would be able to export . Regards [1] http://lackof.org/taggart/hacking/multiarch/ -- Héctor Orón -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
