Building gcc 12 cross-compiler with --enable-lto on FreeBSD fails
Hi, I am trying to build a cross-compiler on FreeBSD with --enable-lto because a chip vendor is using it when building controller software that is part of a system. The build I am using symlinks gmp, mpfr etc as source so they are built as part of the gcc build. The mpfr package is reporting ... build/mpfr/config.log:configure:17408: error: Link Time Optimisation is not supported (see config.log for details). Should the enable option be passed to these packages? I have assumed the enable option for LTO is for the cross compiler and not the host gcc? Thanks Chris
Re: Building gcc 12 cross-compiler with --enable-lto on FreeBSD fails
On Wed, Jun 15, 2022 at 11:27 AM Chris Johns wrote: > > Hi, > > I am trying to build a cross-compiler on FreeBSD with --enable-lto because a > chip vendor is using it when building controller software that is part of a > system. > > The build I am using symlinks gmp, mpfr etc as source so they are built as > part > of the gcc build. > > The mpfr package is reporting ... > > build/mpfr/config.log:configure:17408: error: Link Time Optimisation is not > supported (see config.log for details). > > Should the enable option be passed to these packages? You shouldn't need --enable-lto, it's effect (adding lto to the set of compiled languages) is already the default. You can use --enable-languages=default,lto to achieve the same effect without getting the mpfr side-effect. > I have assumed the enable option for LTO is for the cross compiler and not the > host gcc? it's for the built GCC, enabling LTO support (but not for enabling building GCC itself with LTO). Richard. > > Thanks > Chris
Re: Building gcc 12 cross-compiler with --enable-lto on FreeBSD fails
On 15/6/22 7:56 pm, Richard Biener wrote: > On Wed, Jun 15, 2022 at 11:27 AM Chris Johns > wrote: >> >> Hi, >> >> I am trying to build a cross-compiler on FreeBSD with --enable-lto because a >> chip vendor is using it when building controller software that is part of a >> system. >> >> The build I am using symlinks gmp, mpfr etc as source so they are built as >> part >> of the gcc build. >> >> The mpfr package is reporting ... >> >> build/mpfr/config.log:configure:17408: error: Link Time Optimisation is not >> supported (see config.log for details). >> >> Should the enable option be passed to these packages? > > You shouldn't need --enable-lto, it's effect (adding lto to the set of > compiled > languages) is already the default. You can use --enable-languages=default,lto > to achieve the same effect without getting the mpfr side-effect. Oh that is great and I had no idea this is how it is controlled. I have rebuilt my compiler and it is now building. Nice. >> I have assumed the enable option for LTO is for the cross compiler and not >> the >> host gcc? > > it's for the built GCC, enabling LTO support (but not for enabling > building GCC itself > with LTO). It now makes sense. I will also update the RTEMS tools builds. Thanks Chris
Re: Make cp-demangle non-recursive
Hello Mohamed, On Wed, Jun 15 2022, Mohamed Atef wrote: > Hi, > Are there any further details about this project? do you have any particular question in mind? The project was not selected for this year's Google Summer of Code program. As far as I know nobody works on it outside the program (but I just may not know). When discussing the project earlier this year, Pedro Alves pointed out that we also need demangler entry points which do not rely on malloc which can be used in signal handlers. That requirement is likely to make the project uglier (but perhaps not necessarily much harder). Martin
Re: Make cp-demangle non-recursive
Hi Martin, I haven't examin the whole project yet. But i have free time till next October, I mean litterally free time nothing to do. So during this time I think i can work with Jakub on OMPD and work on something in gcc internals. Maybe you can suggest something not very big something that can be done in 3 months. Mohamed في الأربعاء، ١٥ يونيو، ٢٠٢٢ ١:٠٢ م Martin Jambor كتب: > Hello Mohamed, > > On Wed, Jun 15 2022, Mohamed Atef wrote: > > Hi, > > Are there any further details about this project? > > do you have any particular question in mind? > > The project was not selected for this year's Google Summer of Code > program. As far as I know nobody works on it outside the program (but I > just may not know). > > When discussing the project earlier this year, Pedro Alves pointed out > that we also need demangler entry points which do not rely on malloc > which can be used in signal handlers. That requirement is likely to > make the project uglier (but perhaps not necessarily much harder). > > Martin >
[RISCV] RISC-V GNU Toolchain Meeting Cancell (Jun, 16, 2022)
Hi all, Tomorrow meeting will cancel since there are few new topics to discuss. The next meeting will be two weeks later. Regrads, PLCT Jiawei
