public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* help cross-compiling gcc
@ 2022-12-29 21:24 Vincent Fortier
  2022-12-31 12:04 ` Kai Ruottu
  0 siblings, 1 reply; 6+ messages in thread
From: Vincent Fortier @ 2022-12-29 21:24 UTC (permalink / raw)
  To: gcc-help

Hi all,

I've been trying to cross-compile various versions of gcc using the
Synology DSM6 and DSM7 toolchains and kernel for various archs
(armv5-7-8, ppc, i686, x64).

Over the years I've been actively working on the SynoCommunity project
that provides a framework to help integrate free software and generate
linux packages that can be installed on Synology NAS (ref:
https://github.com/SynoCommunity/spksrc)

Pertaining to gcc, my first attempt has been to try to build the same
compiler as the one used on various versions of DSM6 (gcc-4.9) and
DSM7 (gcc-7.5).  In order to do so I use the Synology provided
toolchain and prepare the associated kernel with proper platform
configuration in order to provide its headers.  In extra I look
forward into applying crosstool-ng patches.

As a relatively "simple" example, I've been working on cross-compiling
for a x86_64 host/target using DSM6 with gcc-4.9.4.  So far I was only
able to build the gcc C compiler (beginner's luck?).  Enabling any
other languages fails so has trying newer versions of gcc on that
particular platform.

From my reading I've associated my sysroot with the proper toolchain
and added linux headers as extra includes.  I believe I'm close but
probably missing something obvious (which is why I'm now asking for a
bit of extra help :)

Build options are as follows (partially based on linux from scratch
gcc 4.9.2), makefile variables naming being parsed by the framework:
CONFIGURE_ARGS = --disable-bootstrap
#CONFIGURE_ARGS += --enable-languages=c
CONFIGURE_ARGS += --enable-languages=c,c++
#CONFIGURE_ARGS += --enable-languages=c,c++,fortran,go,objc,obj-c++
CONFIGURE_ARGS += --enable-shared
CONFIGURE_ARGS += --enable-threads=posix
CONFIGURE_ARGS += --enable-__cxa_atexit
CONFIGURE_ARGS += --enable-clocale=gnu
CONFIGURE_ARGS += --disable-plugins
CONFIGURE_ARGS += --disable-multilib
CONFIGURE_ARGS += --with-system-zlib
CONFIGURE_ARGS += --with-build-sysroot=$(TC_SYSROOT)
#CONFIGURE_ARGS += --with-sysroot=$(TC_SYSROOT)
# Otherwise fails
ADDITIONAL_CFLAGS += -Wno-error
# kernel headers
ADDITIONAL_CFLAGS +=
-I$(WORK_DIR)/linux-$(ARCH)-$(TCVERSION)/arch/$(ARCH)/include
ADDITIONAL_CPPFLAGS +=
-I$(WORK_DIR)/linux-$(ARCH)-$(TCVERSION)/arch/$(ARCH)/include

Considering that by default the framework provides:
--host=$(TC_TARGET) --build=i686-pc-linux

Guidance would be much welcomed :)

- vin (@th0ma7)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: help cross-compiling gcc
  2022-12-29 21:24 help cross-compiling gcc Vincent Fortier
@ 2022-12-31 12:04 ` Kai Ruottu
  2022-12-31 20:30   ` Vincent Fortier
  0 siblings, 1 reply; 6+ messages in thread
From: Kai Ruottu @ 2022-12-31 12:04 UTC (permalink / raw)
  To: gcc-help

Vincent Fortier via Gcc-help kirjoitti 29.12.2022 klo 23.24:
> Hi all,
>
> I've been trying to cross-compile various versions of gcc using the
> Synology DSM6 and DSM7 toolchains and kernel for various archs
> (armv5-7-8, ppc, i686, x64).
>
> Over the years I've been actively working on the SynoCommunity project
> that provides a framework to help integrate free software and generate
> linux packages that can be installed on Synology NAS (ref:
> https://github.com/SynoCommunity/spksrc)
>
> Pertaining to gcc, my first attempt has been to try to build the same
> compiler as the one used on various versions of DSM6 (gcc-4.9) and
> DSM7 (gcc-7.5).
OK...
>    In order to do so I use the Synology provided
> toolchain and prepare the associated kernel with proper platform
> configuration in order to provide its headers.
Not understood. Why you think that you must replace the kernel headers 
coming
with the Synology-made toolchain?
> In extra I look
> forward into applying crosstool-ng patches.
What you do expect finding in these patches?
> As a relatively "simple" example, I've been working on cross-compiling
> for a x86_64 host/target using DSM6 with gcc-4.9.4.  So far I was only
> able to build the gcc C compiler (beginner's luck?).  Enabling any
> other languages fails so has trying newer versions of gcc on that
> particular platform.
For pure curiosity I tried to reproduce the GCC in the 
'r1000-gcc850_glibc226_i686-GPL.txz'
package. But with the "as it is now" stuff in this Synology toolchain - 
with the glibc and kernel
headers being provided. And on my old CentOS 6 / i686 host with a CentOS 
5 / i686 targeted
cross gcc-8.5.0. Everything went ok until hitting in this error when 
compiling libstdc++ :

libtool: compile:  /home/src/gcc-8.5.0/build/./gcc/xgcc -shared-libgcc 
-B/home/src/gcc-8.5.0/build/./gcc -nostdinc++ 
-L/home/src/gcc-8.5.0/build/i686-syno_r1000-linux-gnu/libstdc++-v3/src 
-L/home/src/gcc-8.5.0/build/i686-syno_r1000-linux-gnu/libstdc++-v3/src/.libs 
-L/home/src/gcc-8.5.0/build/i686-syno_r1000-linux-gnu/libstdc++-v3/libsupc++/.libs 
-B/opt/cross/i686-syno_r1000-linux-gnu/bin/ 
-B/opt/cross/i686-syno_r1000-linux-gnu/lib/ -isystem 
/opt/cross/i686-syno_r1000-linux-gnu/include -isystem 
/opt/cross/i686-syno_r1000-linux-gnu/sys-include -D_GNU_SOURCE -D_DEBUG 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-DHAVE_RPC_XDR_H=1 -DHAVE_TIRPC_RPC_XDR_H=0 -I. 
-I../../../../libsanitizer/sanitizer_common -I.. -I 
../../../../libsanitizer/include -isystem 
../../../../libsanitizer/include/system -Wall -W -Wno-unused-parameter 
-Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin 
-fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables 
-fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include 
-I../../libstdc++-v3/include/i686-syno_r1000-linux-gnu 
-I../../../../libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11 
-DSANITIZER_LIBBACKTRACE -DSANITIZER_CP_DEMANGLE -I 
../../../../libsanitizer/../libbacktrace -I ../libbacktrace -I 
../../../../libsanitizer/../include -include 
../../../../libsanitizer/libbacktrace/backtrace-rename.h -g -O2 
-D_GNU_SOURCE -g -Os -MT sanitizer_platform_limits_posix.lo -MD -MP -MF 
.deps/sanitizer_platform_limits_posix.Tpo -c 
../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc 
-fPIC -DPIC -o .libs/sanitizer_platform_limits_posix.o
../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:902:46: 
virhe: ”SCSI_IOCTL_TAGGED_DISABLE” on esittelemättä tällä näkyvyysalueella
    unsigned IOCTL_SCSI_IOCTL_TAGGED_DISABLE = SCSI_IOCTL_TAGGED_DISABLE;
^~~~~~~~~~~~~~~~~~~~~~~~~
../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:902:46: 
huom: suggested alternative: ”IOCTL_SCSI_IOCTL_TAGGED_DISABLE”
    unsigned IOCTL_SCSI_IOCTL_TAGGED_DISABLE = SCSI_IOCTL_TAGGED_DISABLE;
^~~~~~~~~~~~~~~~~~~~~~~~~
IOCTL_SCSI_IOCTL_TAGGED_DISABLE
../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:903:45: 
virhe: ”SCSI_IOCTL_TAGGED_ENABLE” on esittelemättä tällä näkyvyysalueella
    unsigned IOCTL_SCSI_IOCTL_TAGGED_ENABLE = SCSI_IOCTL_TAGGED_ENABLE;
^~~~~~~~~~~~~~~~~~~~~~~~
../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:903:45: 
huom: suggested alternative: ”IOCTL_SCSI_IOCTL_TAGGED_ENABLE”
    unsigned IOCTL_SCSI_IOCTL_TAGGED_ENABLE = SCSI_IOCTL_TAGGED_ENABLE;
^~~~~~~~~~~~~~~~~~~~~~~~
IOCTL_SCSI_IOCTL_TAGGED_ENABLE
make[4]: *** [sanitizer_platform_limits_posix.lo] Virhe 1
make[4]: Poistutaan hakemistosta 
"/media/2c439158-ef3e-4dcf-a63b-03191c302829/home/src/gcc-8.5.0/build/i686-syno_r1000-linux-gnu/libsanitizer/sanitizer_common"
make[3]: *** [all-recursive] Virhe 1

Seemingly the 'include/scsi/scsi.h' was changed either in newer glibcs 
or kernel headers, I don't remember
where these SCSI headers belong. The CentOS 5 and 6 '/usr/include' 
headers still have this :

/*
  * Here are some scsi specific ioctl commands which are sometimes useful.
  */
/* These are a few other constants only used by scsi devices.  */

#define SCSI_IOCTL_GET_IDLUN 0x5382

/* Used to turn on and off tagged queuing for scsi devices.  */

#define SCSI_IOCTL_TAGGED_ENABLE 0x5383
#define SCSI_IOCTL_TAGGED_DISABLE 0x5384

/* Used to obtain the host number of a device.  */
#define SCSI_IOCTL_PROBE_HOST 0x5385

The Synology R1000 headers only mention that these values 0x5383 and 
0x5384 "were once defined".

Let's see what one should do with this problem...


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: help cross-compiling gcc
  2022-12-31 12:04 ` Kai Ruottu
@ 2022-12-31 20:30   ` Vincent Fortier
  2022-12-31 20:47     ` Tom Kacvinsky
  2022-12-31 21:59     ` Kai Ruottu
  0 siblings, 2 replies; 6+ messages in thread
From: Vincent Fortier @ 2022-12-31 20:30 UTC (permalink / raw)
  To: Kai Ruottu; +Cc: gcc-help

Le sam. 31 déc. 2022, à 07 h 05, Kai Ruottu <kai.ruottu@wippies.com> a écrit :
>
> Vincent Fortier via Gcc-help kirjoitti 29.12.2022 klo 23.24:
> > Hi all,
> >
> > I've been trying to cross-compile various versions of gcc using the
> > Synology DSM6 and DSM7 toolchains and kernel for various archs
> > (armv5-7-8, ppc, i686, x64).
> >
> > Over the years I've been actively working on the SynoCommunity project
> > that provides a framework to help integrate free software and generate
> > linux packages that can be installed on Synology NAS (ref:
> > https://github.com/SynoCommunity/spksrc)
> >
> > Pertaining to gcc, my first attempt has been to try to build the same
> > compiler as the one used on various versions of DSM6 (gcc-4.9) and
> > DSM7 (gcc-7.5).
> OK...
> >    In order to do so I use the Synology provided
> > toolchain and prepare the associated kernel with proper platform
> > configuration in order to provide its headers.
> Not understood. Why you think that you must replace the kernel headers
> coming with the Synology-made toolchain?

I was able to build C only using --enable-languages=c only when adding
the relative kernel headers along with:
# kernel headers
ADDITIONAL_CFLAGS +=
-I$(WORK_DIR)/linux-$(ARCH)-$(TCVERSION)/arch/$(ARCH)/include
ADDITIONAL_CPPFLAGS +=
-I$(WORK_DIR)/linux-$(ARCH)-$(TCVERSION)/arch/$(ARCH)/include

As such I expected that the toolchain header files weren't
sufficient... But I just retested this and it actually did built
without it, thus meaning it isn't needed.

> > In extra I look
> > forward into applying crosstool-ng patches.
> What you do expect finding in these patches?

Until now I hadn't looked at it in detail.  I recalled an aarch64 issue:
https://lwn.net/Articles/842122/
And was also hoping a miracle fix would come out of it solving my build issue.
But I just looked at the patchset and this actual aarch64 fix isn't
even included, and no, it ain't solving miraculously my build issue.
I'll have to investigate a little to confirm if it make sense or not
of applying them.

> > As a relatively "simple" example, I've been working on cross-compiling
> > for a x86_64 host/target using DSM6 with gcc-4.9.4.  So far I was only
> > able to build the gcc C compiler (beginner's luck?).  Enabling any
> > other languages fails so has trying newer versions of gcc on that
> > particular platform.
> For pure curiosity I tried to reproduce the GCC in the
> 'r1000-gcc850_glibc226_i686-GPL.txz'
> package. But with the "as it is now" stuff in this Synology toolchain -
> with the glibc and kernel
> headers being provided. And on my old CentOS 6 / i686 host with a CentOS
> 5 / i686 targeted
> cross gcc-8.5.0. Everything went ok until hitting in this error when
> compiling libstdc++ :
>
> libtool: compile:  /home/src/gcc-8.5.0/build/./gcc/xgcc -shared-libgcc
> -B/home/src/gcc-8.5.0/build/./gcc -nostdinc++
> -L/home/src/gcc-8.5.0/build/i686-syno_r1000-linux-gnu/libstdc++-v3/src
> -L/home/src/gcc-8.5.0/build/i686-syno_r1000-linux-gnu/libstdc++-v3/src/.libs
> -L/home/src/gcc-8.5.0/build/i686-syno_r1000-linux-gnu/libstdc++-v3/libsupc++/.libs
> -B/opt/cross/i686-syno_r1000-linux-gnu/bin/
> -B/opt/cross/i686-syno_r1000-linux-gnu/lib/ -isystem
> /opt/cross/i686-syno_r1000-linux-gnu/include -isystem
> /opt/cross/i686-syno_r1000-linux-gnu/sys-include -D_GNU_SOURCE -D_DEBUG
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> -DHAVE_RPC_XDR_H=1 -DHAVE_TIRPC_RPC_XDR_H=0 -I.
> -I../../../../libsanitizer/sanitizer_common -I.. -I
> ../../../../libsanitizer/include -isystem
> ../../../../libsanitizer/include/system -Wall -W -Wno-unused-parameter
> -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin
> -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables
> -fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include
> -I../../libstdc++-v3/include/i686-syno_r1000-linux-gnu
> -I../../../../libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11
> -DSANITIZER_LIBBACKTRACE -DSANITIZER_CP_DEMANGLE -I
> ../../../../libsanitizer/../libbacktrace -I ../libbacktrace -I
> ../../../../libsanitizer/../include -include
> ../../../../libsanitizer/libbacktrace/backtrace-rename.h -g -O2
> -D_GNU_SOURCE -g -Os -MT sanitizer_platform_limits_posix.lo -MD -MP -MF
> .deps/sanitizer_platform_limits_posix.Tpo -c
> ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
> -fPIC -DPIC -o .libs/sanitizer_platform_limits_posix.o
> ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:902:46:
> virhe: ”SCSI_IOCTL_TAGGED_DISABLE” on esittelemättä tällä näkyvyysalueella
>     unsigned IOCTL_SCSI_IOCTL_TAGGED_DISABLE = SCSI_IOCTL_TAGGED_DISABLE;
> ^~~~~~~~~~~~~~~~~~~~~~~~~
> ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:902:46:
> huom: suggested alternative: ”IOCTL_SCSI_IOCTL_TAGGED_DISABLE”
>     unsigned IOCTL_SCSI_IOCTL_TAGGED_DISABLE = SCSI_IOCTL_TAGGED_DISABLE;
> ^~~~~~~~~~~~~~~~~~~~~~~~~
> IOCTL_SCSI_IOCTL_TAGGED_DISABLE
> ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:903:45:
> virhe: ”SCSI_IOCTL_TAGGED_ENABLE” on esittelemättä tällä näkyvyysalueella
>     unsigned IOCTL_SCSI_IOCTL_TAGGED_ENABLE = SCSI_IOCTL_TAGGED_ENABLE;
> ^~~~~~~~~~~~~~~~~~~~~~~~
> ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:903:45:
> huom: suggested alternative: ”IOCTL_SCSI_IOCTL_TAGGED_ENABLE”
>     unsigned IOCTL_SCSI_IOCTL_TAGGED_ENABLE = SCSI_IOCTL_TAGGED_ENABLE;
> ^~~~~~~~~~~~~~~~~~~~~~~~
> IOCTL_SCSI_IOCTL_TAGGED_ENABLE
> make[4]: *** [sanitizer_platform_limits_posix.lo] Virhe 1
> make[4]: Poistutaan hakemistosta
> "/media/2c439158-ef3e-4dcf-a63b-03191c302829/home/src/gcc-8.5.0/build/i686-syno_r1000-linux-gnu/libsanitizer/sanitizer_common"
> make[3]: *** [all-recursive] Virhe 1
>
> Seemingly the 'include/scsi/scsi.h' was changed either in newer glibcs
> or kernel headers, I don't remember
> where these SCSI headers belong. The CentOS 5 and 6 '/usr/include'
> headers still have this :
>
> /*
>   * Here are some scsi specific ioctl commands which are sometimes useful.
>   */
> /* These are a few other constants only used by scsi devices.  */
>
> #define SCSI_IOCTL_GET_IDLUN 0x5382
>
> /* Used to turn on and off tagged queuing for scsi devices.  */
>
> #define SCSI_IOCTL_TAGGED_ENABLE 0x5383
> #define SCSI_IOCTL_TAGGED_DISABLE 0x5384
>
> /* Used to obtain the host number of a device.  */
> #define SCSI_IOCTL_PROBE_HOST 0x5385
>
> The Synology R1000 headers only mention that these values 0x5383 and
> 0x5384 "were once defined".
>
> Let's see what one should do with this problem...
>

This is the exact problem I've been hitting, at least on x86_64 archs.
I've looked at many source packages provided by synology but nowhere I
could find a thing pertaining to glibc, gcc or a patch of somesort
related to SCSI_IOCTL ...  Also, seems I'm not the first asking:
https://www.spinics.net/lists/gcchelp/msg49136.html

I've also tried using the --with-sysroot switch, again in hope of
finding a miracle cure.  Once proper variables were set in the
framework it ended generating errors where it would mix in build
include with host include and thus generating interesting errors.
There a portion of GCC that ends-up being compiled using the build C
compiler instead of host/target specified where include get mixed-up:

In file included from
/home/spksrc/gdb/spksrc/cross/gcc-4.9.4/work-apollolake-6.1/gcc-4.9.4/libcilkrts/runtime/local_state.h:62,
                 from
/home/spksrc/gdb/spksrc/cross/gcc-4.9.4/work-apollolake-6.1/gcc-4.9.4/libcilkrts/runtime/cilk-abi.c:60:
/home/spksrc/gdb/spksrc/toolchain/syno-apollolake-6.1/work/x86_64-pc-linux-gnu/x86_64-pc-linux-gnu/sys-root/usr/include/pthread.h:1004:21:
warning: ‘struct timespec’ declared inside parameter list will not be
visible outside of this definition or declaration
 1004 |        const struct timespec *__restrict __abstime)
      |                     ^~~~~~~~
make[5]: *** [Makefile:782: cilk-abi-cilk-for.lo] Error 1
make[5]: *** Waiting for unfinished jobs....
In file included from /usr/include/stdlib.h:25,
                 from /usr/include/c++/10/cstdlib:75,
                 from
/home/spksrc/gdb/spksrc/cross/gcc-4.9.4/work-apollolake-6.1/gcc-4.9.4/libcilkrts/runtime/cilk_fiber.cpp:54:
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:56:17: error:
missing binary operator before token "("
   56 | #if __GLIBC_USE (IEC_60559_BFP_EXT) || __GLIBC_USE (ISOC2X)
      |                 ^
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h:73:17: error:
missing binary operator before token "("
   73 | #if __GLIBC_USE (IEC_60559_FUNCS_EXT) || __GLIBC_USE (ISOC2X)
      |                 ^
In file included from /usr/include/c++/10/cstdlib:75,
                 from
/home/spksrc/gdb/spksrc/cross/gcc-4.9.4/work-apollolake-6.1/gcc-4.9.4/libcilkrts/runtime/cilk_fiber.cpp:54:
/usr/include/stdlib.h:133:35: error: missing binary operator before token "("
  133 | #if __HAVE_FLOAT16 && __GLIBC_USE (IEC_60559_TYPES_EXT)
      |                                   ^

I'm now tempted to patch GCC to remove the definitions from:
$ grep -Rl SCSI_IOCTL *
libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
libsanitizer/sanitizer_common/sanitizer_common_interceptors_ioctl.inc
libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc

Any ideas and/or help much appreciated :)

- vin (@th0ma7)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: help cross-compiling gcc
  2022-12-31 20:30   ` Vincent Fortier
@ 2022-12-31 20:47     ` Tom Kacvinsky
  2022-12-31 21:59     ` Kai Ruottu
  1 sibling, 0 replies; 6+ messages in thread
From: Tom Kacvinsky @ 2022-12-31 20:47 UTC (permalink / raw)
  To: gcc-help

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

On Sat, Dec 31, 2022 at 3:30 PM Vincent Fortier via Gcc-help <
gcc-help@gcc.gnu.org> wrote:

<massive snip>

Any ideas and/or help much appreciated :)
>

Perhaps your issue is that you need the C run time for your cross compiled
tool chain first,
as the libraries GCC builds for its C++ run time (for example, there are
others), having been
targeted for something other than the host build system, will need the
target C run time.  I do
not know if Synology systems use glibc for their C run time.

Now, please keep in mind I have yet to try my hand at building a cross
compiler myself,
but at one point I did do some research on it and this was one of the
things I read.  So I
would take anything I wrote above with a grain of salt.

Tom

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: help cross-compiling gcc
  2022-12-31 20:30   ` Vincent Fortier
  2022-12-31 20:47     ` Tom Kacvinsky
@ 2022-12-31 21:59     ` Kai Ruottu
  2023-04-04  1:23       ` Vincent Fortier
  1 sibling, 1 reply; 6+ messages in thread
From: Kai Ruottu @ 2022-12-31 21:59 UTC (permalink / raw)
  To: Vincent Fortier; +Cc: gcc-help

Vincent Fortier kirjoitti 31.12.2022 klo 22.30:
> Le sam. 31 déc. 2022, à 07 h 05, Kai Ruottu <kai.ruottu@wippies.com> a écrit :
> As such I expected that the toolchain header files weren't
> sufficient... But I just retested this and it actually did built
> without it, thus meaning it isn't needed.
Quickly checked the 'include' and 'lib' stuff looked quite standard in 
the R1000 i686 case.
> For pure curiosity I tried to reproduce the GCC in the
>> 'r1000-gcc850_glibc226_i686-GPL.txz'
>> package. But with the "as it is now" stuff in this Synology toolchain -
>> with the glibc and kernel
>> headers being provided. And on my old CentOS 6 / i686 host with a CentOS
>> 5 / i686 targeted
>> cross gcc-8.5.0. Everything went ok until hitting in this error when
>> compiling libstdc++ :
>>
>> ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
>> -fPIC -DPIC -o .libs/sanitizer_platform_limits_posix.o
>> ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:902:46:
>> virhe: ”SCSI_IOCTL_TAGGED_DISABLE” on esittelemättä tällä näkyvyysalueella
>>      unsigned IOCTL_SCSI_IOCTL_TAGGED_DISABLE = SCSI_IOCTL_TAGGED_DISABLE;
>> ^~~~~~~~~~~~~~~~~~~~~~~~~
>> ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:902:46:
>> huom: suggested alternative: ”IOCTL_SCSI_IOCTL_TAGGED_DISABLE”
>>      unsigned IOCTL_SCSI_IOCTL_TAGGED_DISABLE = SCSI_IOCTL_TAGGED_DISABLE;
>> ^~~~~~~~~~~~~~~~~~~~~~~~~
>> IOCTL_SCSI_IOCTL_TAGGED_DISABLE
>> ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:903:45:
>> virhe: ”SCSI_IOCTL_TAGGED_ENABLE” on esittelemättä tällä näkyvyysalueella
>>      unsigned IOCTL_SCSI_IOCTL_TAGGED_ENABLE = SCSI_IOCTL_TAGGED_ENABLE;
>> ^~~~~~~~~~~~~~~~~~~~~~~~
>> ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:903:45:
>> huom: suggested alternative: ”IOCTL_SCSI_IOCTL_TAGGED_ENABLE”
>>      unsigned IOCTL_SCSI_IOCTL_TAGGED_ENABLE = SCSI_IOCTL_TAGGED_ENABLE;
>> ^~~~~~~~~~~~~~~~~~~~~~~~
>> IOCTL_SCSI_IOCTL_TAGGED_ENABLE
>> make[4]: *** [sanitizer_platform_limits_posix.lo] Virhe 1
>> make[4]: Poistutaan hakemistosta
>> "/media/2c439158-ef3e-4dcf-a63b-03191c302829/home/src/gcc-8.5.0/build/i686-syno_r1000-linux-gnu/libsanitizer/sanitizer_common"
>> make[3]: *** [all-recursive] Virhe 1
>>
>>
>> I'm now tempted to patch GCC to remove the definitions from:
>> $ grep -Rl SCSI_IOCTL *
>> libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
>> libsanitizer/sanitizer_common/sanitizer_common_interceptors_ioctl.inc
>> libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
>>
>> Any ideas and/or help much appreciated :)
I didn't invent any solution yet for this SCSI_IOCTL_TAGGED_* problem so 
I simply
edited the by-configure-produced Makefile via removing all the 
requisites to build

libsanitizer. Then everything continued as expected.

Probably I will rebuild the toolchain from sources again, removing the
'--enable-libsanitizer' in the configure command. And the support for
'local language'(finnish, seen in the log) via adding the '--disable-nls'
there. The used configure command will be seen here :

# i686-syno_r1000-linux-gnu-gcc-8.5 -v
Using built-in specs.
COLLECT_GCC=i686-syno_r1000-linux-gnu-gcc-8.5
COLLECT_LTO_WRAPPER=/media/2c439158-ef3e-4dcf-a63b-03191c302829/opt/cross/bin/../lib/gcc/i686-syno_r1000-linux-gnu/8.5.0/lto-wrapper
Kohde: i686-syno_r1000-linux-gnu
Configured with: ../configure --build=i686-linux-gnu 
--host=i686-linux-gnu --target=i686-syno_r1000-linux-gnu 
--prefix=/opt/cross --libdir=/opt/cross/lib --libexecdir=/opt/cross/lib 
--with-sysroot=/opt/host-i686-syno_r1000-linux-gnu 
--enable-languages=c,c++ --with-arch=i686 --disable-tm-clone-registry 
--disable-multilib --enable-long-long --enable-default-pie 
--enable-__cxa_atexit --enable-cxx-flags=-D_FILE_OFFSET_BITS=64 
--enable-libmudflap --enable-libgomp --enable-libssp 
--enable-libquadmath --enable-libquadmath-support --enable-libsanitizer 
--enable-libmpx --enable-lto --with-host-libstdcxx='-static-libgcc 
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-threads=posix 
--enable-target-optspace --disable-plugin --enable-gold 
--enable-version-specific-runtime-libs 
--with-gxx-include-dir=/opt/cross/include/c++/8.5.0 
--program-prefix=i686-syno_r1000-linux-gnu- --program-suffix=-8.5
Säiemalli: posix
gcc-versio 8.5.0 (GCC)

The options were copied "selectively" from the original gcc-8.5.0 in the 
Synology toolchain
(for a x86_64 host). The '$prefix' was my own standard '/opt/cross' and 
the '$sys-root' the
'/opt/host-$target'


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: help cross-compiling gcc
  2022-12-31 21:59     ` Kai Ruottu
@ 2023-04-04  1:23       ` Vincent Fortier
  0 siblings, 0 replies; 6+ messages in thread
From: Vincent Fortier @ 2023-04-04  1:23 UTC (permalink / raw)
  To: Kai Ruottu; +Cc: gcc-help

Le sam. 31 déc. 2022, à 16 h 59, Kai Ruottu <kai.ruottu@wippies.com> a écrit :
>
> Vincent Fortier kirjoitti 31.12.2022 klo 22.30:
> > Le sam. 31 déc. 2022, à 07 h 05, Kai Ruottu <kai.ruottu@wippies.com> a écrit :
> > As such I expected that the toolchain header files weren't
> > sufficient... But I just retested this and it actually did built
> > without it, thus meaning it isn't needed.
> Quickly checked the 'include' and 'lib' stuff looked quite standard in
> the R1000 i686 case.
> > For pure curiosity I tried to reproduce the GCC in the
> >> 'r1000-gcc850_glibc226_i686-GPL.txz'
> >> package. But with the "as it is now" stuff in this Synology toolchain -
> >> with the glibc and kernel
> >> headers being provided. And on my old CentOS 6 / i686 host with a CentOS
> >> 5 / i686 targeted
> >> cross gcc-8.5.0. Everything went ok until hitting in this error when
> >> compiling libstdc++ :
> >>
> >> ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
> >> -fPIC -DPIC -o .libs/sanitizer_platform_limits_posix.o
> >> ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:902:46:
> >> virhe: ”SCSI_IOCTL_TAGGED_DISABLE” on esittelemättä tällä näkyvyysalueella
> >>      unsigned IOCTL_SCSI_IOCTL_TAGGED_DISABLE = SCSI_IOCTL_TAGGED_DISABLE;
> >> ^~~~~~~~~~~~~~~~~~~~~~~~~
> >> ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:902:46:
> >> huom: suggested alternative: ”IOCTL_SCSI_IOCTL_TAGGED_DISABLE”
> >>      unsigned IOCTL_SCSI_IOCTL_TAGGED_DISABLE = SCSI_IOCTL_TAGGED_DISABLE;
> >> ^~~~~~~~~~~~~~~~~~~~~~~~~
> >> IOCTL_SCSI_IOCTL_TAGGED_DISABLE
> >> ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:903:45:
> >> virhe: ”SCSI_IOCTL_TAGGED_ENABLE” on esittelemättä tällä näkyvyysalueella
> >>      unsigned IOCTL_SCSI_IOCTL_TAGGED_ENABLE = SCSI_IOCTL_TAGGED_ENABLE;
> >> ^~~~~~~~~~~~~~~~~~~~~~~~
> >> ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:903:45:
> >> huom: suggested alternative: ”IOCTL_SCSI_IOCTL_TAGGED_ENABLE”
> >>      unsigned IOCTL_SCSI_IOCTL_TAGGED_ENABLE = SCSI_IOCTL_TAGGED_ENABLE;
> >> ^~~~~~~~~~~~~~~~~~~~~~~~
> >> IOCTL_SCSI_IOCTL_TAGGED_ENABLE
> >> make[4]: *** [sanitizer_platform_limits_posix.lo] Virhe 1
> >> make[4]: Poistutaan hakemistosta
> >> "/media/2c439158-ef3e-4dcf-a63b-03191c302829/home/src/gcc-8.5.0/build/i686-syno_r1000-linux-gnu/libsanitizer/sanitizer_common"
> >> make[3]: *** [all-recursive] Virhe 1
> >>
> >>
> >> I'm now tempted to patch GCC to remove the definitions from:
> >> $ grep -Rl SCSI_IOCTL *
> >> libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
> >> libsanitizer/sanitizer_common/sanitizer_common_interceptors_ioctl.inc
> >> libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
> >>
> >> Any ideas and/or help much appreciated :)
> I didn't invent any solution yet for this SCSI_IOCTL_TAGGED_* problem so

I was able to patch scsi.h to get rid of the SCSI_IOCTL_TAGGED_*
error.  This actually allowed me to get LLVM to build properly.  My PR
checks here shows error but that is only due to caching github-action
current caching.  Otherwise works as expected to build out a
development package https://github.com/SynoCommunity/spksrc/pull/5225
So far I got all I need with the exception of gcc ...

> I simply edited the by-configure-produced Makefile via removing all the
> requisites to build libsanitizer. Then everything continued as expected.

I really wonder what you did in here to get this going in order to
prevent it to build as it is referred everywhere in there?  I could
script this if you can provide me a few additional pointers.  In the
meantime I tried variations on the --enable-libsanitizer or
--disable-libsanitizer or --disable-libiberty all together... all
failing one way or another.

> Probably I will rebuild the toolchain from sources again, removing the
> '--enable-libsanitizer' in the configure command. And the support for
> 'local language'(finnish, seen in the log) via adding the '--disable-nls'
> there. The used configure command will be seen here :
>
> # i686-syno_r1000-linux-gnu-gcc-8.5 -v
> Using built-in specs.
> COLLECT_GCC=i686-syno_r1000-linux-gnu-gcc-8.5
> COLLECT_LTO_WRAPPER=/media/2c439158-ef3e-4dcf-a63b-03191c302829/opt/cross/bin/../lib/gcc/i686-syno_r1000-linux-gnu/8.5.0/lto-wrapper
> Kohde: i686-syno_r1000-linux-gnu
> Configured with: ../configure --build=i686-linux-gnu
> --host=i686-linux-gnu --target=i686-syno_r1000-linux-gnu
> --prefix=/opt/cross --libdir=/opt/cross/lib --libexecdir=/opt/cross/lib
> --with-sysroot=/opt/host-i686-syno_r1000-linux-gnu
> --enable-languages=c,c++ --with-arch=i686 --disable-tm-clone-registry
> --disable-multilib --enable-long-long --enable-default-pie
> --enable-__cxa_atexit --enable-cxx-flags=-D_FILE_OFFSET_BITS=64
> --enable-libmudflap --enable-libgomp --enable-libssp
> --enable-libquadmath --enable-libquadmath-support --enable-libsanitizer
> --enable-libmpx --enable-lto --with-host-libstdcxx='-static-libgcc
> -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-threads=posix
> --enable-target-optspace --disable-plugin --enable-gold
> --enable-version-specific-runtime-libs
> --with-gxx-include-dir=/opt/cross/include/c++/8.5.0
> --program-prefix=i686-syno_r1000-linux-gnu- --program-suffix=-8.5
> Säiemalli: posix
> gcc-versio 8.5.0 (GCC)

Ultimately it's the latest toolchain compatible version I'd like to
make available (e.g. 12.x probably feasible for DSM7 using gcc-8.5
cross-compiler).  Similar to what I did for LLVM where v9 builds ok
from toolchain provided gcc-4.9 for Synology DSM 6.x and LLVM latest
(v16) builds fine using toolchain provided gcc-8.5 for Synology DSM
7.x.

> The options were copied "selectively" from the original gcc-8.5.0 in the
> Synology toolchain
> (for a x86_64 host). The '$prefix' was my own standard '/opt/cross' and
> the '$sys-root' the
> '/opt/host-$target'

I tried finding a configuration within various arches toolchains.  I
couldn't find anything.  Where did you find this?

Also wondered, if by any chance you have spare cycles to try out
building from our spksrc framework that would be really really nice of
you.  I've committed my current testing & mostly failures with gcc
here https://github.com/SynoCommunity/spksrc/pull/5225/commits/39bff938665601f96e060b229c28e88e6aedcd44

The howto use is relatively straight-forward and documented
https://github.com/SynoCommunity/spksrc using docker or lxc/lxd.  Then
its a matter of doing a make setup from the framework root directory
and cd cross/gcc then make arch-x64-7.1 (e.g. make
arch-<ARCH>-<DSM-VERSION>) or simply make all-supported (currently no
archs are defined as unsupported for gcc as none is working anyway).

Additional help or guidance would be much appreciated, thnx!

Thnx in advance :)

- vin


              1,1           Top

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2023-04-04  1:23 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-29 21:24 help cross-compiling gcc Vincent Fortier
2022-12-31 12:04 ` Kai Ruottu
2022-12-31 20:30   ` Vincent Fortier
2022-12-31 20:47     ` Tom Kacvinsky
2022-12-31 21:59     ` Kai Ruottu
2023-04-04  1:23       ` Vincent Fortier

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).