Problem cross-compiling gcc

Problem cross-compiling gcc

[Christer Solskogen]

While cross compiling gcc with musl I see this:

checking for exported symbols... /home/solskogen/gcc/libcc1/configure: 
line 15053: -T: command not found
yes
checking for -rdynamic... /home/solskogen/gcc/libcc1/configure: line 
15063: -T: command not found
no
checking for library containing dlopen... none required
checking for -fPIC -shared... yes
configure: error:
    Building GCC with plugin support requires a host that supports
    -fPIC, -shared, -ldl and -rdynamic.
make[1]: *** [Makefile:11890: configure-libcc1] Error 1

This is the configure line: /home/solskogen/gcc/configure --prefix=/usr 
--libexecdir=/lib --host=aarch64-centrix-linux-musl 
--target=aarch64-centrix-linux-musl --build=x86_64-pc-linux-gnu 
--enable-languages=c,c++ --disable-multilib --enable-checking=release 
--disable-nls --with-gcc-major-version-only --enable-plugin 
--disable-libstdcxx-pch --enable-default-pie --enable-default-ssp 
--disable-libsanitizer --enable-host-shared

I can't figure out that it doesn't find. But a google search suggests 
objdump.

gcc is at version 12.2.0. Worth submitting a bug report?

Re: Problem cross-compiling gcc

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 1617 bytes --]

On Sun, 12 Feb 2023, 17:52 Christer Solskogen via Gcc-help, <
gcc-help@gcc.gnu.org> wrote:

> While cross compiling gcc with musl I see this:
>
> checking for exported symbols... /home/solskogen/gcc/libcc1/configure:
> line 15053: -T: command not found
> yes
> checking for -rdynamic... /home/solskogen/gcc/libcc1/configure: line
> 15063: -T: command not found


Did you try looking at that line of that configure file? It should tell you
exactly what is missing.


no
> checking for library containing dlopen... none required
> checking for -fPIC -shared... yes
> configure: error:
>     Building GCC with plugin support requires a host that supports
>     -fPIC, -shared, -ldl and -rdynamic.
> make[1]: *** [Makefile:11890: configure-libcc1] Error 1
>
> This is the configure line: /home/solskogen/gcc/configure --prefix=/usr
> --libexecdir=/lib --host=aarch64-centrix-linux-musl
> --target=aarch64-centrix-linux-musl --build=x86_64-pc-linux-gnu
> --enable-languages=c,c++ --disable-multilib --enable-checking=release
> --disable-nls --with-gcc-major-version-only --enable-plugin
> --disable-libstdcxx-pch --enable-default-pie --enable-default-ssp
> --disable-libsanitizer --enable-host-shared
>
> I can't figure out that it doesn't find. But a google search suggests
> objdump.
>

Could be, look at the configure script.

Do you have a cross objdump compiled for the target, in your PATH?

If you can't work out what's wrong, just build GCC with --disable-libcc1
(assuming you don't need it for gdb in your cross toolchain).


> gcc is at version 12.2.0. Worth submitting a bug report?
>


probably not



>
>
>
>

Re: Problem cross-compiling gcc

[Christer Solskogen]

On 12.02.2023 20:24, Jonathan Wakely via Gcc-help wrote:
> On Sun, 12 Feb 2023, 17:52 Christer Solskogen via Gcc-help, <
> gcc-help@gcc.gnu.org> wrote:
> 
>> While cross compiling gcc with musl I see this:
>>
>> checking for exported symbols... /home/solskogen/gcc/libcc1/configure:
>> line 15053: -T: command not found
>> yes
>> checking for -rdynamic... /home/solskogen/gcc/libcc1/configure: line
>> 15063: -T: command not found
> 
> 
> Did you try looking at that line of that configure file? It should tell you
> exactly what is missing.
> 

if $export_sym_check conftest$ac_exeext | grep foobar > /dev/null; then
But I don't quite understand what it really means.

> 
> no
>> checking for library containing dlopen... none required
>> checking for -fPIC -shared... yes
>> configure: error:
>>      Building GCC with plugin support requires a host that supports
>>      -fPIC, -shared, -ldl and -rdynamic.
>> make[1]: *** [Makefile:11890: configure-libcc1] Error 1
>>
>> This is the configure line: /home/solskogen/gcc/configure --prefix=/usr
>> --libexecdir=/lib --host=aarch64-centrix-linux-musl
>> --target=aarch64-centrix-linux-musl --build=x86_64-pc-linux-gnu
>> --enable-languages=c,c++ --disable-multilib --enable-checking=release
>> --disable-nls --with-gcc-major-version-only --enable-plugin
>> --disable-libstdcxx-pch --enable-default-pie --enable-default-ssp
>> --disable-libsanitizer --enable-host-shared
>>
>> I can't figure out that it doesn't find. But a google search suggests
>> objdump.
>>
> 
> Could be, look at the configure script.
> 
> Do you have a cross objdump compiled for the target, in your PATH?

I do. aarch64-centrix-linux-musl-objdump is in PATH.

-- 
chs

Re: Problem cross-compiling gcc

[Christer Solskogen]

On 12.02.2023 20:24, Jonathan Wakely via Gcc-help wrote:

>> gcc is at version 12.2.0. Worth submitting a bug report?
>>
> 
> 
> probably not
> 


I think I've found a workaround.
Adding gcc_cv_objdump=${TARGET}-objdump to the make command. But that 
seems like a bug to me, doesn't it?

-- 
chs

Re: Problem cross-compiling gcc

[Kai Ruottu]

Christer Solskogen via Gcc-help kirjoitti 12.2.2023 klo 19.51:
> While cross compiling gcc with musl I see this:
>
> checking for exported symbols... /home/solskogen/gcc/libcc1/configure: 
> line 15053: -T: command not found
> yes
> checking for -rdynamic... /home/solskogen/gcc/libcc1/configure: line 
> 15063: -T: command not found
> no
> checking for library containing dlopen... none required
> checking for -fPIC -shared... yes
> configure: error:
>    Building GCC with plugin support requires a host that supports
>    -fPIC, -shared, -ldl and -rdynamic.
> make[1]: *** [Makefile:11890: configure-libcc1] Error 1
>
> This is the configure line: /home/solskogen/gcc/configure 
> --prefix=/usr --libexecdir=/lib --host=aarch64-centrix-linux-musl 
> --target=aarch64-centrix-linux-musl --build=x86_64-pc-linux-gnu

What is intersting in this case is WHICH GCC the build tries to use when 
compiling libgcc. It should be the 'aarch64-centrix-linux-musl' targeted 
cross-GCC, used for the becoming $host
system to create the executables and libraries for it. So what are the 
CC_FOR_TARGET, GCC_FOR_TARGET, CXX_FOR_TARGET and GXX_FOR_TARGET in the 
main Makefile and in the one
used for libgcc?  My habit has been years to define these in environment 
before running configure. Maybe these simply don't work in the "native 
Canadian Cross" case. (To create a native
GCC with a cross-GCC).

Re: Problem cross-compiling gcc

[Christer Solskogen]

On 12.02.2023 21:01, Kai Ruottu wrote:
> Christer Solskogen via Gcc-help kirjoitti 12.2.2023 klo 19.51:
>> While cross compiling gcc with musl I see this:
>>
>> checking for exported symbols... /home/solskogen/gcc/libcc1/configure: 
>> line 15053: -T: command not found
>> yes
>> checking for -rdynamic... /home/solskogen/gcc/libcc1/configure: line 
>> 15063: -T: command not found
>> no
>> checking for library containing dlopen... none required
>> checking for -fPIC -shared... yes
>> configure: error:
>>    Building GCC with plugin support requires a host that supports
>>    -fPIC, -shared, -ldl and -rdynamic.
>> make[1]: *** [Makefile:11890: configure-libcc1] Error 1
>>
>> This is the configure line: /home/solskogen/gcc/configure 
>> --prefix=/usr --libexecdir=/lib --host=aarch64-centrix-linux-musl 
>> --target=aarch64-centrix-linux-musl --build=x86_64-pc-linux-gnu
> 
> What is intersting in this case is WHICH GCC the build tries to use when 
> compiling libgcc. It should be the 'aarch64-centrix-linux-musl' targeted 
> cross-GCC, used for the becoming $host
> system to create the executables and libraries for it. So what are the 
> CC_FOR_TARGET, GCC_FOR_TARGET, CXX_FOR_TARGET and GXX_FOR_TARGET in the 
> main Makefile and in the one
> used for libgcc?  My habit has been years to define these in environment 
> before running configure. Maybe these simply don't work in the "native 
> Canadian Cross" case. (To create a native
> GCC with a cross-GCC).
> 
> 

I see this in configure:
Configuring in ./libcc1
configure: loading cache ./config.cache
checking build system type... x86_64-pc-linux-gnu
checking host system type... aarch64-centrix-linux-musl
checking target system type... aarch64-centrix-linux-musl
checking for aarch64-centrix-linux-musl-gcc... 
aarch64-centrix-linux-musl-gcc
checking whether the C compiler works... yes


Which *should* mean that it finds the correct compiler. In the Makefile 
I see this:

CC = aarch64-centrix-linux-musl-gcc
CXX = aarch64-centrix-linux-musl-g++
GCC_FOR_TARGET=$(STAGE_CC_WRAPPER) aarch64-centrix-linux-musl-gcc
CXX_FOR_TARGET=$(STAGE_CC_WRAPPER) aarch64-centrix-linux-musl-c++
CC_FOR_TARGET=$(STAGE_CC_WRAPPER) aarch64-centrix-linux-musl-gcc

All of the other tools also have the aarch64-centrix-linux-musl- prefix 
as well, so as far as I understand this *should* work.

Re: Problem cross-compiling gcc

[Kai Ruottu]

[-- Attachment #1: Type: text/plain, Size: 5964 bytes --]

Christer Solskogen via Gcc-help kirjoitti 13.2.2023 klo 9.23:
> On 12.02.2023 21:01, Kai Ruottu wrote:
>> Christer Solskogen via Gcc-help kirjoitti 12.2.2023 klo 19.51:
>>> While cross compiling gcc with musl I see this:
>>>
>>> checking for exported symbols... 
>>> /home/solskogen/gcc/libcc1/configure: line 15053: -T: command not found
>>> yes
>>> checking for -rdynamic... /home/solskogen/gcc/libcc1/configure: line 
>>> 15063: -T: command not found
>>> no
>>> checking for library containing dlopen... none required
>>> checking for -fPIC -shared... yes
>>> configure: error:
>>>    Building GCC with plugin support requires a host that supports
>>>    -fPIC, -shared, -ldl and -rdynamic.
>>> make[1]: *** [Makefile:11890: configure-libcc1] Error 1
>>>
>>> This is the configure line: /home/solskogen/gcc/configure 
>>> --prefix=/usr --libexecdir=/lib --host=aarch64-centrix-linux-musl 
>>> --target=aarch64-centrix-linux-musl --build=x86_64-pc-linux-gnu
>>
>> What is intersting in this case is WHICH GCC the build tries to use 
>> when compiling libgcc. It should be the 'aarch64-centrix-linux-musl' 
>> targeted cross-GCC, used for the becoming $host
>> system to create the executables and libraries for it. So what are 
>> the CC_FOR_TARGET, GCC_FOR_TARGET, CXX_FOR_TARGET and GXX_FOR_TARGET 
>> in the main Makefile and in the one
>> used for libgcc?  My habit has been years to define these in 
>> environment before running configure. Maybe these simply don't work 
>> in the "native Canadian Cross" case. (To create a native
>> GCC with a cross-GCC).
>>
>>
>
> I see this in configure:
> Configuring in ./libcc1
> configure: loading cache ./config.cache
> checking build system type... x86_64-pc-linux-gnu
> checking host system type... aarch64-centrix-linux-musl
> checking target system type... aarch64-centrix-linux-musl
> checking for aarch64-centrix-linux-musl-gcc... 
> aarch64-centrix-linux-musl-gcc
> checking whether the C compiler works... yes
>
>
> Which *should* mean that it finds the correct compiler. In the 
> Makefile I see this:
>
> CC = aarch64-centrix-linux-musl-gcc
> CXX = aarch64-centrix-linux-musl-g++
> GCC_FOR_TARGET=$(STAGE_CC_WRAPPER) aarch64-centrix-linux-musl-gcc
> CXX_FOR_TARGET=$(STAGE_CC_WRAPPER) aarch64-centrix-linux-musl-c++
> CC_FOR_TARGET=$(STAGE_CC_WRAPPER) aarch64-centrix-linux-musl-gcc
>
> All of the other tools also have the aarch64-centrix-linux-musl- 
> prefix as well, so as far as I understand this *should* work.
>
For curiousness I tried creating a native gcc for 'x86_64-linux-musl' 
for which I had target headers and libs from year 2017.
I couldn't find equivalent for 'aarch64-linux-musl' in the net, only the 
libraries in the "Void Linux" pages, but no development
headers.

I built first a cross-GCC from the gcc-12.2.0 sources with a gcc-5.5.0 
as the build/host GCC, then tried to use the new cross-GCC
as the host/target compiler. But not defining the GCC_FOR_TARGET, 
CXX_FOR_TARGET and CC_FOR_TARGET, letting the
configure to define them. In my case they of course were wrong because I 
haven't only one GCC for a target at a time. As told,
I had already a toolchain - gcc-7.2.0 based - for 'x86_64-linux-musl' - 
with exec-suffix '-7.2', so the new one got a suffix '-12'.
Ok, making symlinks  with the bare 'x86_64-linux-musl-gcc' etc names to 
point to the right ones solved this.

After this the only problem was trying to also use gcc-12.2.0 as the 
$build GCC. It was too new and the 'gen*' stuff created for
the build $host was linked against the 12.2.0-version of the C++ library 
but during runtime tried to use the older shared C++
library installed on the host system which didn't work.  So back to 
using the gcc-5.5.0 for the $build GCC...

The native-Canadian Cross succeeded then without any problems. One could 
only wonder why "reinventing the wheel" would
be necessary when the earlier '$host-to-x86_64-linux-musl' 
cross-compiler already had all the stuff being built for the $target
system.  Aren't the separated 'lib/gcc/$target' and 
'libexec/gcc/$target' stuff just for this purpose, to make it easy to 
pack at least
the common header and library things?

The install command :
make DESTDIR=path-to-rootdir install
told in :
https://gcc.gnu.org/install/finalinstall.html
however should enable one to maintain a "temporary staging area or into 
a |chroot| jail" on the $host system for each 'alien $host'.
So maybe "reinventing the wheel" via reproducing the already produced 
$target stuff has some sanity...

I cannot say what the problem with the 'aarch64' architecture could be 
but what I can see is that your GCC configure options are
quite simple when compared to what I "borrowed" from somewhere in 2017 
in the 'x86_64' architecture case :

[root@AthlonXP2 ~]# x86_64-linux-musl-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-linux-musl-gcc
COLLECT_LTO_WRAPPER=/opt/cross/bin/../lib/gcc/x86_64-linux-musl/12.2.0/lto-wrapper
Target: x86_64-linux-musl
Configured with: ../configure --build=i686-linux-gnu 
--host=i686-linux-gnu --target=x86_64-linux-musl --prefix=/opt/cross 
--libdir=/opt/cross/lib --libexecdir=/opt/cross/lib 
--with-sysroot=/opt/host-x86_64-linux-musl --enable-languages=c,c++ 
--enable-fast-character --disable-libsanitizer --disable-libvtv 
--disable-libitm --disable-symvers libat_cv_have_ifunc=no 
--enable-threads=posix --enable-__cxa_atexit --disable-multilib 
--enable-shared --enable-lto --enable-vtable-verify 
--enable-linker-build-id --enable-serial-configure --disable-werror 
--disable-nls --enable-default-pie --enable-default-ssp 
--enable-checking=release --disable-libstdcxx-pch 
--with-linker-hash-style=gnu --disable-libunwind-exceptions 
--disable-target-libiberty --with-default-libstdcxx-abi=gcc4-compatible 
--with-gxx-include-dir=/opt/cross/include/c++/12.2 
--program-prefix=x86_64-linux-musl- --program-suffix=-12
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (GCC)

Re: Problem cross-compiling gcc

[Segher Boessenkool]

On Sun, Feb 12, 2023 at 06:51:06PM +0100, Christer Solskogen via Gcc-help wrote:
> While cross compiling gcc with musl I see this:

> This is the configure line: /home/solskogen/gcc/configure --prefix=/usr 
> --libexecdir=/lib --host=aarch64-centrix-linux-musl 
> --target=aarch64-centrix-linux-musl --build=x86_64-pc-linux-gnu 
> --enable-languages=c,c++ --disable-multilib --enable-checking=release 
> --disable-nls --with-gcc-major-version-only --enable-plugin 
> --disable-libstdcxx-pch --enable-default-pie --enable-default-ssp 
> --disable-libsanitizer --enable-host-shared

That is not a cross-compiler, you are building a cross-built native
compiler here (host=target).  To do that you already need a working
cross-compiler, so it is probably not what you intended to do.

To build a cross-compiler you should not normally give any --build= or
--host=, and instead use what is auto-detected for that.  You'll end up
with build=host: a cross-compiler.


Segher

Re: Problem cross-compiling gcc

[Christer Solskogen]

On 13.02.2023 09:16, Segher Boessenkool wrote:
> On Sun, Feb 12, 2023 at 06:51:06PM +0100, Christer Solskogen via Gcc-help wrote:
>> While cross compiling gcc with musl I see this:
> 
>> This is the configure line: /home/solskogen/gcc/configure --prefix=/usr
>> --libexecdir=/lib --host=aarch64-centrix-linux-musl
>> --target=aarch64-centrix-linux-musl --build=x86_64-pc-linux-gnu
>> --enable-languages=c,c++ --disable-multilib --enable-checking=release
>> --disable-nls --with-gcc-major-version-only --enable-plugin
>> --disable-libstdcxx-pch --enable-default-pie --enable-default-ssp
>> --disable-libsanitizer --enable-host-shared
> 
> That is not a cross-compiler, you are building a cross-built native
> compiler here (host=target).  To do that you already need a working
> cross-compiler, so it is probably not what you intended to do.
> 

Oh, I know. That's why the subject is "cross-compiling gcc" :-)
I already have a working cross compiler. In fact, cross compiling gcc is 
pretty good way to check that the cross compiler is in good shape.

-- 
chs

Re: Problem cross-compiling gcc

[Segher Boessenkool]

On Mon, Feb 13, 2023 at 09:35:56AM +0100, Christer Solskogen via Gcc-help wrote:
> On 13.02.2023 09:16, Segher Boessenkool wrote:
> >On Sun, Feb 12, 2023 at 06:51:06PM +0100, Christer Solskogen via Gcc-help 
> >wrote:
> >>While cross compiling gcc with musl I see this:
> >
> >>This is the configure line: /home/solskogen/gcc/configure --prefix=/usr
> >>--libexecdir=/lib --host=aarch64-centrix-linux-musl
> >>--target=aarch64-centrix-linux-musl --build=x86_64-pc-linux-gnu
> >>--enable-languages=c,c++ --disable-multilib --enable-checking=release
> >>--disable-nls --with-gcc-major-version-only --enable-plugin
> >>--disable-libstdcxx-pch --enable-default-pie --enable-default-ssp
> >>--disable-libsanitizer --enable-host-shared
> >
> >That is not a cross-compiler, you are building a cross-built native
> >compiler here (host=target).  To do that you already need a working
> >cross-compiler, so it is probably not what you intended to do.
> >
> 
> Oh, I know. That's why the subject is "cross-compiling gcc" :-)
> I already have a working cross compiler.

Aha :-)

> In fact, cross compiling gcc is 
> pretty good way to check that the cross compiler is in good shape.

I'd say it is mainly a good way to hit problems no one else does.  For
example many things won't be detected correctly by the autoxxxx macros
It's not helped by the fact that musl isn't very mainstream either of
course, but I guess you are trying to change that :-)

gl;hf,


Segher