Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Issues building arm-none-eabi toolchain via crossdev.
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
R0b0t1
Apprentice
Apprentice


Joined: 05 Jun 2008
Posts: 255

PostPosted: Sun Aug 13, 2017 5:15 am    Post subject: Issues building arm-none-eabi toolchain via crossdev. Reply with quote

Hello,

The command I am using, `crossdev -t arm-none-eabi`, fails in stage 2. The stable version fails as well and I've reported it: https://bugs.gentoo.org/show_bug.cgi?id=627586. It seems to be suffering from a different issue. Comments on either are appreciated, but I'd rather get GCC 6.4.0 working. At the moment I'm running a Kubuntu VM to do my development in.

I found the related topic https://forums.gentoo.org/viewtopic-t-1048968-start-0.html but there is not much exposition. The part I am using is ARMV7E-M architecture - how do I specify that to crossdev? It seems like specifying more than ARM in CHOST does not do anything (besides create an appropriately named overlay directory) and any more specific configuration requires explicit command line options when compiling.

It's also expected that Newlib is built with crossdev. Eix shows it installed, but linking my project fails with "ld: cannot find -lc_nano." The topic at https://forums.gentoo.org/viewtopic-t-1017098-start-0.html isn't very helpful. The failure is that specifying "-specs=nano.specs" along with "-lc" apparently links against "c_nano." If I remove the nano.specs option linking will succeed, but I would like to save space.

Code:
checking for library containing clock_gettime... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
make[1]: *** [Makefile:9915: configure-target-libstdc++-v3] Error 1
make[1]: Leaving directory '/var/tmp/portage/cross-arm-none-eabi/gcc-6.4.0/work/build'
make: *** [Makefile:875: all] Error 2
 * ERROR: cross-arm-none-eabi/gcc-6.4.0::localrepo failed (compile phase):
 *   emake failed
 *
 * If you need support, post the output of `emerge --info '=cross-arm-none-eabi/gcc-6.4.0::localrepo'`,
 * the complete build log and the output of `emerge -pqv '=cross-arm-none-eabi/gcc-6.4.0::localrepo'`.
 * The complete build log is located at '/var/tmp/portage/cross-arm-none-eabi/gcc-6.4.0/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/cross-arm-none-eabi/gcc-6.4.0/temp/environment'.
 * Working directory: '/var/tmp/portage/cross-arm-none-eabi/gcc-6.4.0/work/build'
 * S: '/var/tmp/portage/cross-arm-none-eabi/gcc-6.4.0/work/gcc-6.4.0'
 *
 * Please include /var/tmp/portage/cross-arm-none-eabi/gcc-6.4.0/work/gcc-build-logs.tar.bz2 in your bug report.
 *
 * !!! User patches were applied to this build!

>>> Failed to emerge cross-arm-none-eabi/gcc-6.4.0, Log file:

>>>  '/var/tmp/portage/cross-arm-none-eabi/gcc-6.4.0/temp/build.log'


On a related note how do I get crossdev to build unkeyworded (**) toolchain versions? Thanks in advance.
Back to top
View user's profile Send private message
russK
l33t
l33t


Joined: 27 Jun 2006
Posts: 648

PostPosted: Sun Aug 13, 2017 6:39 pm    Post subject: Reply with quote

I has success with 2 different builds, you may find the 2nd one more interesting.

I was able to build this:
Code:
# crossdev -t arm-none-eabi
------------------------------------------------------------------------------------------------------
 * crossdev version:      20151026
 * Host Portage ARCH:     amd64
 * Target Portage ARCH:   arm
 * Target System:         arm-none-eabi
 * Stage:                 3 (C compiler & libc)
 * ABIs:                  default

 * binutils:              binutils-[latest]
 * gcc:                   gcc-[latest]
 * libc:                  newlib-[latest]

 * CROSSDEV_OVERLAY:      /usr/local/portage-crossdev
 * PORT_LOGDIR:           /var/log/portage
 * PORTAGE_CONFIGROOT:
 * Portage flags:
  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -
 * leaving metadata/layout.conf alone in /usr/local/portage-crossdev
  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -
!!! WARNING - Cannot auto-configure CHOST arm-none-eabi;
!!! You should edit /usr/arm-none-eabi/etc/portage/make.conf
!!! by hand to complete your configuration.
!!!  No LIBC is known for this target.
 * Log: /var/log/portage/cross-arm-none-eabi-binutils.log
 * Emerging cross-binutils ...                                                                  [ ok ]
 * Log: /var/log/portage/cross-arm-none-eabi-gcc-stage1.log
 * Emerging cross-gcc-stage1 ...                                                                [ ok ]
 * Log: /var/log/portage/cross-arm-none-eabi-newlib.log
 * Emerging cross-newlib ...                                                                    [ ok ]


And this:
Code:
# crossdev -t armv7e-cortexm4-linux-gnueabi------------------------------------------------------------------------------------------------------
 * crossdev version:      20151026
 * Host Portage ARCH:     amd64
 * Target Portage ARCH:   arm
 * Target System:         armv7e-cortexm4-linux-gnueabi
 * Stage:                 4 (C/C++ compiler)
 * ABIs:                  default

 * binutils:              binutils-[latest]
 * gcc:                   gcc-[latest]
 * headers:               linux-headers-[latest]
 * libc:                  glibc-[latest]

 * CROSSDEV_OVERLAY:      /usr/local/portage-crossdev
 * PORT_LOGDIR:           /var/log/portage
 * PORTAGE_CONFIGROOT:   
 * Portage flags:         
  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -
 * leaving metadata/layout.conf alone in /usr/local/portage-crossdev
  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -
 * Log: /var/log/portage/cross-armv7e-cortexm4-linux-gnueabi-binutils.log
 * Emerging cross-binutils ...                                                                  [ ok ]
 * Log: /var/log/portage/cross-armv7e-cortexm4-linux-gnueabi-linux-headers-quick.log
 * Emerging cross-linux-headers-quick ...                                                       [ ok ]
 * Log: /var/log/portage/cross-armv7e-cortexm4-linux-gnueabi-glibc-headers.log
 * Emerging cross-glibc-headers ...                                                             [ ok ]
 * Log: /var/log/portage/cross-armv7e-cortexm4-linux-gnueabi-gcc-stage1.log
 * Emerging cross-gcc-stage1 ...                                                                [ ok ]
 * Log: /var/log/portage/cross-armv7e-cortexm4-linux-gnueabi-linux-headers.log
 * Emerging cross-linux-headers ...                                                             [ ok ]
 * Log: /var/log/portage/cross-armv7e-cortexm4-linux-gnueabi-glibc.log
 * Emerging cross-glibc ...                                                                     [ ok ]
 * Log: /var/log/portage/cross-armv7e-cortexm4-linux-gnueabi-gcc-stage2.log
 * Emerging cross-gcc-stage2 ...                                                                [ ok ]


When I tried,
Code:
# crossdev -t armv7e-cortexm4-eabi

It fails in the gcc stage1 with an issue with newlib and hardfloat. I see some threads on the internet with people grappling with the same issue, e.g., https://lists.gt.net/gentoo/embedded/305768
There may be ways to supply arguments to get that build to work.

I now have this, I'm collecting compilers:
Code:
# gcc-config -l
 [1] arm-none-eabi-6.4.0 *

 [2] armv6j-hardfloat-linux-gnueabi-4.8.5 *

 [3] armv7e-cortexm4-linux-gnueabi-6.4.0 *

 [4] avr-4.9.4
 [5] avr-5.4.0 *

 [6] x86_64-pc-linux-gnu-4.9.4
 [7] x86_64-pc-linux-gnu-5.4.0 *




HTH
Back to top
View user's profile Send private message
russK
l33t
l33t


Joined: 27 Jun 2006
Posts: 648

PostPosted: Sun Aug 13, 2017 6:49 pm    Post subject: Reply with quote

Here is a little more info.

When when this fails, I get the following log on the paste bin:

Code:
# crossdev -s1 -t  armv7e-cortexm4-eabi
------------------------------------------------------------------------------------------------------
 * crossdev version:      20151026
 * Host Portage ARCH:     amd64
 * Target Portage ARCH:   arm
 * Target System:         armv7e-cortexm4-eabi
 * Stage:                 1 (C compiler only)
 * ABIs:                  default

 * binutils:              binutils-[latest]
 * gcc:                   gcc-[latest]

 * CROSSDEV_OVERLAY:      /usr/local/portage-crossdev
 * PORT_LOGDIR:           /var/log/portage
 * PORTAGE_CONFIGROOT:   
 * Portage flags:         
  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -
 * leaving sys-devel/binutils in /usr/local/portage-crossdev
 * leaving sys-devel/gcc in /usr/local/portage-crossdev
 * leaving sys-libs/newlib in /usr/local/portage-crossdev
 * leaving sys-devel/gdb in /usr/local/portage-crossdev
 * leaving metadata/layout.conf alone in /usr/local/portage-crossdev
  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -
 * Log: /var/log/portage/cross-armv7e-cortexm4-eabi-binutils.log
 * Emerging cross-binutils ...                                                                  [ ok ]
 * Log: /var/log/portage/cross-armv7e-cortexm4-eabi-gcc-stage1.log
 * Emerging cross-gcc-stage1 ...

 * gcc failed :(
 *
 * If you file a bug, please attach the following logfiles:
 * /var/log/portage/cross-armv7e-cortexm4-eabi-info.log
 * /var/log/portage/cross-armv7e-cortexm4-eabi-gcc-stage1.log.xz
 * /var/tmp/portage/cross-armv7e-cortexm4-eabi/gcc*/temp/gcc-config.logs.tar.xz


Look here for /var/log/portage/cross-armv7e-cortexm4-eabi-gcc-stage1.log
https://paste.pound-python.org/show/DFC7SXY38X7HyC9AXMn7/
Back to top
View user's profile Send private message
R0b0t1
Apprentice
Apprentice


Joined: 05 Jun 2008
Posts: 255

PostPosted: Sun Aug 13, 2017 8:59 pm    Post subject: Reply with quote

Somehow I think I solved a stage 1 failure by switching the CHOST to arm-none-eabi. I am not sure what this would have changed. I have reproduced this by attempting to build a toolchain for armv7e-cortexm4-eabi, which fails. In any case, I gravitated to arm-none-eabi because this CHOST supports all embedded ARM processors that do not use an OS. Appropriate flags need to be obtained from the device manufacturer.

The default arguments to crossdev for arm-none-eabi seem to succeed, producing a C compiler that is sufficient for embedded development. Unfortunately I am hoping to be able to use C++. In GCC 5, the failure in stage 2 seems to be related to an unsupported OS. In GCC 6 it seems to be due to an improperly implemented automake configuration test.

I attempted to build GCC 7.1 via crossdev using suggestions from NeddySeagoon, to see if the configuration problems went away, but editing /etc/portage/package.keywords/cross-arm-none-eabi to include "<cross-arm-none-eabi/gcc-8 **" only leads to this line being removed upon rerunning crossdev. Specifying --g =7.1.0 adds "=cross-arm-none-eabi/gcc-7.1.0 * ~* **" to that file and will execute up to stage two with -s4 specified, but I do not see arm-none-eabi-gcc-7.1.0 and the specified version does not show up in gcc-config. It seems like it rebuilt GCC 6.

I also attempted to modify crossdev - the stage 1 compilation avoids C++ support. Stage 2 seems to be poorly supported due to lack of OS, but most information I can find on crossdev specifies -s4 to generate a C++ compiler. Sadly editing line 582 of the crossdev script to remove "nocxx -cxx" and passing USE="cxx" to the invocation of the script did not produce a C++ compiler.


In short, all of my questions still stand. I can attach any relevant output.

It seems like most distributions repackage the toolchain provided by ARM. I have had a lot of problems trying to find documentation to configure crossdev and the toolchains it produces, otherwise I suppose I might be able to fix some bugs still open on the Gentoo tracker.
Back to top
View user's profile Send private message
R0b0t1
Apprentice
Apprentice


Joined: 05 Jun 2008
Posts: 255

PostPosted: Tue Aug 15, 2017 1:24 am    Post subject: Reply with quote

Well, more bad news. It looks like the stage 1 that is generated doesn't produce usable code. Compiling the same project under Windows with the ARM-provided toolchain results in working code, even with the option changes necessary to compile on the crossdev-produced stage 1.
Back to top
View user's profile Send private message
NTU
Apprentice
Apprentice


Joined: 17 Jul 2015
Posts: 185

PostPosted: Tue Aug 15, 2017 2:25 am    Post subject: Reply with quote

Code:
checking for library containing clock_gettime... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.


Heh, I came across that when I was working on this countless times:

https://github.com/NTULINUX/clfs-arm64

When GCC throws you that error, it's because of the installation directory of the libraries for Glibc. If Glibc isn't installed where GCC expects it, or a portion of some of it's libraries, you'll get that. I discovered that copying the files from the most top level lib directory to the target arch name directory/lib fixed the issue and I was able to continue the build by going back into GCC and running make. It continued where it left off and built it successfully. I can tell you just by that error message that it is a bug with crossdev. Depending on how the crossdev ./configure options are written for cross GCC you may need to copy glibc's libraries in your crossdev cross toolchain install directory to either $SYSROOT/lib or (in your case) cross-arm-none-eabi/lib

It took some playing with but I eventually figured out the culprit.

For crossdev developers:

You should look into specifying --libdir=$WHERE_IT_IS_NOW to --libdir=$WHERE_IT_IS_NOW/$TARGET_ARCH/lib{64} on the glibc configure line. I've haven't dug into crossdev specifically but I've also noticed that --with-build-sysroot is broken. CLFS and Crosstool-NG use --with-sysroot instead of what ./configure --help suggests; --with-build-sysroot and I see why. I've never been able to build jack if I use --with-build-sysroot and get errors mostly due to missing headers. Using --includedir or --with-native-system-header-dir doesn't do anything.

Your issue with the linker not finding -lc is an issue with Binutils' --with-lib-path option. I've hunted that problem down recently too. When a cross library is installed to a directory outside of Binutils' default search path, you'll get that. Running $cross-arch-gnu-ld --verbose will have a section of SEARCH_DIR("/path/to/libs") variables. If the library crossdev installs is outside of that search path, Binutils will not be able to find things like -lc etc.


Last edited by NTU on Tue Aug 15, 2017 2:36 am; edited 2 times in total
Back to top
View user's profile Send private message
russK
l33t
l33t


Joined: 27 Jun 2006
Posts: 648

PostPosted: Tue Aug 15, 2017 2:29 am    Post subject: Reply with quote

NTU,

Sounds like you understand the issue well enough to file a bug report. Do you know if one has been filed on this? The developers may or may not see this on the forum.

Regards
Back to top
View user's profile Send private message
NTU
Apprentice
Apprentice


Joined: 17 Jul 2015
Posts: 185

PostPosted: Tue Aug 15, 2017 2:56 am    Post subject: Reply with quote

Depending on what issue we're talking about here, this thing here isn't an issue with crossdev:

Code:
/var/tmp/portage/cross-arm-none-eabi/gcc-5.4.0-r3/work/gcc-5.4.0/libsanitizer/sanitizer_common/sanitizer_platform.h:16:3:# error "This operating system is not supported"


The reason why libsanitizer builds fine when you use armv7e-cortexm4-linux-gnueabi is because armv7e is a supported platform by libsanitizer. When you use really broad terms like arm-none-eabi is, I'm assuming based on the error message, because not all ARM target types support libsanitizer. Have you tried crossdev -t arm-none-linux-gnueabi?

Again, I haven't actually dissected crossdev itself, but you've mentioned newlib. GCC is not supposed to be built against newlib. I filed a bug report (years ago) to the GCC devs due to an issue with building against newlib, and it was instantly dismissed because I was, unknowingly, building GCC against an unsupported C library by the upstream developers. I would take their advice and avoid newlib. The only reason for cross development you specify --with-newlib and --without-headers on the first static GCC build (stage 1) is because there are no C headers yet. --with-newlib --without-headers doesn't actually mean to tell GCC to use the newlib C library, rather only build the base static C compiler without the target C library installed yet. GCC should (in a perfect world) build fine with just --without-headers but the CLFS guys use both, so I use both, even though there is absolutely no use of newlib in either of our projects.

Potential note to crossdev devs:

When the user specifies -t arm-none-eabi perhaps add --disable-libsanitizer to the ./configure line and whatever else may not be supported by such target:

Code:
if [[ $CROSSDEV_TARGET == arm-none-eabi ]] ; then
   --disable-libsanitizer
fi
Back to top
View user's profile Send private message
R0b0t1
Apprentice
Apprentice


Joined: 05 Jun 2008
Posts: 255

PostPosted: Tue Aug 15, 2017 11:29 pm    Post subject: Reply with quote

Hello NTU,

To clarify, I am targeting MMUless embedded devices. It might be possible to compile Linux for them (ucLinux patches are now mainline) but that is not what I am trying to do at the moment. In light of this I need to use newlib, or at the very least it is the case that newlib is strongly recommended by the processor manufacturer.

Can you direct me to instructions that will help me build a toolchain for the target I need? Also, the issue is not that GCC can't find libc, it just seems to not be able to find the various versions of libc that newlib compilation should generate. If you were referring to potentially linking GCC against newlib, I do not think that is occurring. E.g. crossdev can compile AVR-GCC perfectly.

Your suggestion to disable libsanitizer is in line with other recommendations I see elsewhere but where does this information originate? There seems to be configuration that crossdev is missing, but it is very hard to figure out what it is missing. I'll try to put some of your recommendations into practice when building GCC manually.


Have you considered contributing to crossdev? I don't suggest this merely because you might be able to fix the problem I am having, but because the goal of crossdev seems to be more or less your goal. A cross portage helps with filesystem maintenance immensely. Your script is the third or fourth root building script I have seen. Admittedly it is better put together than most of the others, but crossdev is really the tool for the job.

R0b0t1.
Back to top
View user's profile Send private message
NTU
Apprentice
Apprentice


Joined: 17 Jul 2015
Posts: 185

PostPosted: Wed Aug 16, 2017 1:48 am    Post subject: Reply with quote

R0b0t1 wrote:
Hello NTU

Suh dude.

Quote:
To clarify, I am targeting MMUless embedded devices.

Have you tried uclibc? Musl may work too, not sure, I don't know it's status on MMU-lacking devices. This is also a reason why I spend the extra dollar on hardware that has an MMU and VFP. Time is money. ! MMU == time.

Quote:
Can you direct me to instructions that will help me build a toolchain for the target I need?

Crosstool-NG might help. I personally don't use it because it's bloated as all hell now with tons of magic. i.e. if you don't use .build as the default directory, it fails. Genius. Don't screw with the folder names, suffix and prefix config parts, and you should be fine.

Quote:
Also, the issue is not that GCC can't find libc, it just seems to not be able to find the various versions of libc that newlib compilation should generate. If you were referring to potentially linking GCC against newlib, I do not think that is occurring.

Why would newlib be getting compiled if GCC is not linking to it? Seems like a waste of CPU cycles. Perhaps I'm misunderstanding.

Quote:
Your suggestion to disable libsanitizer is in line with other recommendations I see elsewhere but where does this information originate?

From the error message as printed out by GCC.

Quote:
There seems to be configuration that crossdev is missing, but it is very hard to figure out what it is missing.

What's missing is a --disable-libsanitizer option in the crossdev source.

Quote:
Have you considered contributing to crossdev?

No.

Quote:
I don't suggest this merely because you might be able to fix the problem I am having, but because the goal of crossdev seems to be more or less your goal.

It is not my goal at all. Crossdev is for cross building a Gentoo system, a source-based Linux distribution. I want a system from scratch, more bare-metal, and that is completely generic. Debian's dpkg and Gentoo's crossdev are for the distributions they were built from and are not universal tools.

Quote:
A cross portage helps with filesystem maintenance immensely.

Cross portage depends on the target system having a complete toolchain. You can't have a "Gentoo" system without a build system, otherwise it's a "broken Gentoo system." For things like an embedded firewall or a headless server, you don't want make and a compiler and all those tools. You want it to be as bare as possible. Having things like X installed for example lower the security of the device.

Quote:
Your script is the third or fourth root building script I have seen.

Kewl.

Quote:
Admittedly it is better put together than most of the others

Thank you! I appreciate it.

Quote:
but crossdev is really the tool for the job.

Depends on what the job and goal is. Crossdev can leave a system too bloated for one's needs, and also leaves room for problems like yours. The whole point of my project is to skip the madness and have everything open with customization in mind, including for even the configure lines for the toolchain and everything in between.

Quote:
R0b0t1.

NTU.

I always wanted to quote someone like this.
Back to top
View user's profile Send private message
R0b0t1
Apprentice
Apprentice


Joined: 05 Jun 2008
Posts: 255

PostPosted: Wed Aug 16, 2017 7:18 pm    Post subject: Reply with quote

NTU wrote:
Quote:
To clarify, I am targeting MMUless embedded devices.

Have you tried uclibc? Musl may work too, not sure, I don't know it's status on MMU-lacking devices. This is also a reason why I spend the extra dollar on hardware that has an MMU and VFP. Time is money. ! MMU == time.
My part does not have an MMU but does have a VFP. The problem is that devices with an MMU are orders of magnitude more complicated and use orders of magnitude more power. There is very little technical reason that devices of the size I am interested in could not be designed with an MMU, but it is not cost effective, especially on the programming end. I'll consider uclibc and musl but they are not as well supported for as Newlib. There's very little evidence the problem is newlib, there seems to be a problem in crossdev.

For ARM, the distinction is mainly between Cortex-M/Cortex-R (embedded/realtime processors, without an MMU) and Cortex-A (applications processors, with an MMU).

NTU wrote:
Quote:
Can you direct me to instructions that will help me build a toolchain for the target I need?

Crosstool-NG might help. I personally don't use it because it's bloated as all hell now with tons of magic. i.e. if you don't use .build as the default directory, it fails. Genius. Don't screw with the folder names, suffix and prefix config parts, and you should be fine.
Alright. That doesn't seem promising. So far I either find instructions for building cross compilers that support Linux-based systems, or cross compilers that overspecialize themselves and are not actually an arm-none-eabi toolchain, despite the terminology in common use.

NTU wrote:
Quote:
Also, the issue is not that GCC can't find libc, it just seems to not be able to find the various versions of libc that newlib compilation should generate. If you were referring to potentially linking GCC against newlib, I do not think that is occurring.
Why would newlib be getting compiled if GCC is not linking to it? Seems like a waste of CPU cycles. Perhaps I'm misunderstanding.
GCC doesn't link to it because GCC is not being built for the target system. I am building the compiler that produces code for the target system - programs (running in "real" mode) targeting the architecture the compiler supports will be linked with newlib. In my case the device I am targeting runs at 80MHz or less and has a small amount of RAM. Compiling anything, even if I could run GCC on it, would likely take months or years.

NTU wrote:
Quote:
Your suggestion to disable libsanitizer is in line with other recommendations I see elsewhere but where does this information originate?

From the error message as printed out by GCC.

Quote:
There seems to be configuration that crossdev is missing, but it is very hard to figure out what it is missing.

What's missing is a --disable-libsanitizer option in the crossdev source.
I am surprised that this is the only thing missing. I have found instructions for building an arm-none-eabi toolchain that leave this option out. Consequently I'm not really sure where the error message you're referring to occurs.

NTU wrote:
Quote:
Have you considered contributing to crossdev?

No.

Quote:
I don't suggest this merely because you might be able to fix the problem I am having, but because the goal of crossdev seems to be more or less your goal.

It is not my goal at all. Crossdev is for cross building a Gentoo system, a source-based Linux distribution. I want a system from scratch, more bare-metal, and that is completely generic. Debian's dpkg and Gentoo's crossdev are for the distributions they were built from and are not universal tools.

Quote:
A cross portage helps with filesystem maintenance immensely.

Cross portage depends on the target system having a complete toolchain. You can't have a "Gentoo" system without a build system, otherwise it's a "broken Gentoo system." For things like an embedded firewall or a headless server, you don't want make and a compiler and all those tools. You want it to be as bare as possible. Having things like X installed for example lower the security of the device.

Quote:
Your script is the third or fourth root building script I have seen.

Kewl.

Quote:
Admittedly it is better put together than most of the others

Thank you! I appreciate it.

Quote:
but crossdev is really the tool for the job.

Depends on what the job and goal is. Crossdev can leave a system too bloated for one's needs, and also leaves room for problems like yours. The whole point of my project is to skip the madness and have everything open with customization in mind, including for even the configure lines for the toolchain and everything in between.
That is a shame. You should reconsider, because I think you have misunderstood the point of Gentoo and crossdev. The point of Gentoo, portage, and crossdev is to efficiently describe a system so you can compile it. The only reason you would not use it for your goal is because you want to do everything yourself.

Per the main wiki page on crossdev, crossdev is for generating compilation environments. It doesn't stipulate that you compile anything save the cross compiler. When you compile a package via portage for your target system it is put into the crossroot by default, so you can compress that and install it on systems as you want. You can also produce binary packages to keep systems up to date. If you want you can also avoid using portage with crossdev entirely and use the cross toolchain it generates to manage your root directly, but I would suggest this is a waste of time.

If you use crossdev to generate a toolchain and then use portage to compile @system for a crossroot, you have a bare system that is as generic as you can get. If you want to use a binary distribution's definition of generic, you are more than welcome to enable all of the USE flags for the software in @system so that every feature is available. Otherwise configure that before you compile to be as limited as you want.

R0b0t1.
Back to top
View user's profile Send private message
R0b0t1
Apprentice
Apprentice


Joined: 05 Jun 2008
Posts: 255

PostPosted: Thu Aug 17, 2017 4:08 am    Post subject: Reply with quote

Hello,

I have attempted to build GCC by piecing together some instructions from the internet. I am using sources available in portage and applying the patches in portage. It is my goal to produce a working toolchain and then duplicate those steps in crossdev or any relevant ebuilds. I have yet to go through the official arm-none-eabi toolchain's useflags (available via `arm-none-eabi-gcc -v`) and copy them. It seems like there will be quite a bit of modification necessary. I am not sure if specifying a CPU and FPU is necessary - arm-none-eabi should encompass all Cortex-M devices of varying capability.

GCC fails to compile with multiple errors:
Code:
../../../../work/gcc-7.1.0/libssp/gets-chk.c: In function '__gets_chk':
../../../../work/gcc-7.1.0/libssp/gets-chk.c:66:24: error: 'INT_MAX' undeclared (first use in this function); did you mean '__INT_MAX__'?
   if (slen >= (size_t) INT_MAX)
                        ^~~~~~~
                        __INT_MAX__

There are more, e.g. size_t is undefined. I am building with GCC 7.1. If I should go back to a more stable GCC, how do I do so?


A rough outline of all steps is here: https://istarc.wordpress.com/2014/07/21/stm32f4-build-your-toolchain-from-scratch/

Setup:
Code:
export TARGET=arm-none-eabi
export PREFIX=arm-none-eabi/install
export PATH=$PATH:<parent>/arm-none-eabi/install/bin

mkdir arm-none-eabi && cd arm-none-eabi
mkdir dist
mkdir work
mkdir build
mkdir install

emerge -af sys-devel/binutils sys-devel/gcc sys-devel/gdb newlib
# Copy the distribution files to ./dist:
cp /usr/portage/distfiles/<package> ./dist
# Unpack the distribution files to ./work:
tar xfC <package> ./work
# Unpack the patches to ./work/<package>/patch:
tar xfC <package-patches> ./work/<package>
# Patch the release (from within source directory):
cd ./<package>
for f in ./patch/*.patch; do patch -p 1 < $f; done
# Create the build directories (only necessary for GCC):
cd build && mkdir `ls ../work`


binutils 2.28.1:
Code:
./configure --target=$TARGET --prefix=$PREFIX --with-cpu=cortex-m4 --with-fpu=fpv4-sp-d16 --with-float=hard --with-mode=thumb --enable-interwork --enable-multilib --with-gnu-as --with-gnu-ld --disable-nls


gcc 7.1.0 (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32212):
Code:
cd ./build/gcc-7.1.0
../../work/gcc-7.1.0/configure --target=$TARGET --prefix=$PREFIX --with-cpu=cortex-m4 --with-fpu=fpv4-sp-d16 --with-float=hard --with-mode=thumb --enable-interwork --enable-multilib --enable-languages=c --with-system-zlib --with-newlib --without-headers --without-shared --disable-nls --with-gnu-as --with-gnu-ld


Please, I am not very smart. Any help is appreciated. I would very much like to get this working from Gentoo as it is cumbersome to use a VM.

R0b0t1.
Back to top
View user's profile Send private message
cwr
Veteran
Veteran


Joined: 17 Dec 2005
Posts: 1969

PostPosted: Thu Aug 17, 2017 1:24 pm    Post subject: Reply with quote

I've built ARM cross compilers with:
Code:

crossdev -t armv7m-softfloat-eabi

for the LPC 1768 and
Code:

crossdev -S -v -t armv6j-hardfloat-linux-gnueabi

for the RPi Zero

The BeagleBone Black needed:
Code:

    crossdev -v -S -t armv7-none-linux-gnueabi --env
    'EXTRA_ECONF="--with-arch=armv7-a
    --with-fpu=vfpv3-d16
    --with-float-abi=hard
    libc_cv_forced_unwind=yes
    libc_cv_ctors_header=yes
    libc_cv_c_cleanup=yes"'


However, these all used standard binutils and glibc, and were built on systems which were
entirely 32-bit. In the past I've often had to set specific binutils and glibc versions, but
recently the default versions have generally compiled.

Good luck - Will
Back to top
View user's profile Send private message
R0b0t1
Apprentice
Apprentice


Joined: 05 Jun 2008
Posts: 255

PostPosted: Thu Aug 17, 2017 9:18 pm    Post subject: Reply with quote

Thank you for your input cwr, when I get home I will try to build those toolchains. The LPC1768 toolchain should be correct with minor modifications for the STM32L4 line:
Code:
crossdev -t armv7em-hardfloat-eabi
I will also try it as you provided verbatim should that fail. I am not sure if specifying anything besides "arm" in the first part does anything. Well - in the past I have had it change a failure into a success, and I think that was because it is not recognized and some default options were not set. I will also try to rely on libc. It seems like that is a candidate for success, as arm-none-eabi pulls in newlib automatically (as a general principle I'd like to use GNU software anyway).

I have both other devices you mentioned, so I may as well get those toolchains compiled.

Recently, retrying the compilation with GCC 7.2 (newly released) fails as well with more or less the same errors. I switched because I felt I would eventually need help from the GCC mailing list, and it seems like I will. I was able to get Newlib to compile by going back to the 2.5.0 release and avoiding the 7/20/17 update. I suppose I will keep posting with updates. Input is always welcome.

I have an update! I was able to produce a GCC 6.3.0 C++ compiler on a Kubuntu VM. I will have to try this again at home, and see if the produced code runs on device. I suppose I will still need to file a bug on the GCC tracker.


Last edited by R0b0t1 on Sat Aug 19, 2017 5:54 am; edited 1 time in total
Back to top
View user's profile Send private message
NTU
Apprentice
Apprentice


Joined: 17 Jul 2015
Posts: 185

PostPosted: Fri Aug 18, 2017 10:22 pm    Post subject: Reply with quote

Quote:
That is a shame. You should reconsider, because I think you have misunderstood the point of Gentoo and crossdev. The point of Gentoo, portage, and crossdev is to efficiently describe a system so you can compile it. The only reason you would not use it for your goal is because you want to do everything yourself.


Do everything myself... The reason I'm doing everything myself is because crossdev is apparently broken according to this thread and it isn't made for what I want. Crossdev is made for being run on a Gentoo system (not the right way to do Linux development) and it's for building a cross-Gentoo system, again, not what I want. Crossdev is not minimal enough for me, too large of a root filesystem with unnecessary bloat, and doesn't even work right according to this thread. Your need to tell me what I want just irritates me. All this talk about you wanting me to be a crossdev developer when it's goal is something completely different than what I have in mind, I'm starting to think the only person here who should join their project is you as their PR rep. I tried helping you and I'm offering valid advice but now I'm just getting frustrated and more confused. Even with @system and stripping USE flags, it'll still have utilities which I don't need.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 16016

PostPosted: Sat Aug 19, 2017 12:18 am    Post subject: Reply with quote

My experience has been that crossdev can be used to generate a toolchain independent from any attempt to compile a cross-Gentoo using that toolchain. It certainly has supporting features for people who want to use it that way (the cross-emerge wrapper, for example), but it is also possible to build just the cross-compiler, then run that through separate privately managed scripts to build the desired programs (not necessarily even Gentoo packages). Among other things, this is very useful for targeting exotic systems, such as Windows.
NTU wrote:
made for being run on a Gentoo system (not the right way to do Linux development)
This sounds strange to me. What do you think is the proper way to do Linux development if not from a Linux system?
Back to top
View user's profile Send private message
NTU
Apprentice
Apprentice


Joined: 17 Jul 2015
Posts: 185

PostPosted: Sat Aug 19, 2017 12:32 am    Post subject: Reply with quote

Hu wrote:
NTU wrote:
made for being run on a Gentoo system (not the right way to do Linux development)
This sounds strange to me. What do you think is the proper way to do Linux development if not from a Linux system?


Oh I see, this is one of those "anything you say can and will be used against you" situations. Allow me to clarify.

"made for being run on a Gentoo system" -> "made exclusively for being run on a Gentoo system."

This is my last reply to this cancerous thread. Hope you guys can fix the issue at hand here but this is where I wash my hands of this situation.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 16016

PostPosted: Sat Aug 19, 2017 3:20 am    Post subject: Reply with quote

It's not exclusive to Gentoo. It's exclusive to systems that have a compatible package manager. This is unfortunate, but necessary, because you really don't want to spew toolchain files all over the place by building it outside control of some sort of package manager, whether rpm, deb, or ebuild.
Back to top
View user's profile Send private message
R0b0t1
Apprentice
Apprentice


Joined: 05 Jun 2008
Posts: 255

PostPosted: Sat Aug 19, 2017 6:23 am    Post subject: Reply with quote

I have an update!

The 6.3.0 and 6.4.0 builds were not reproducible. The CHOST cwr gave for the LPC he selected compiles with "softfloat" replaced with "hardfloat." A few variations I tried do not. However, that is mostly irrelevant because someone involved with OpenOCD development responded to my message to the GCC mailing list and linked me to this script: https://github.com/FreddieChopin/bleeding-edge-toolchain. Using that I successfully generated a complete arm-none-eabi toolchain that supports all Cortex-M, Cortex-R, and Cortex-A (in supervisor mode) features, as that CHOST should. Sadly I did not find complete documentation on what needs to be done, though I was given more documentation.

Someone on the GCC mailing list also confirmed my suspicions that creating the C and C++ compilers in separate stages is not necessary. If a working host toolchain is already present it is possible to build all front ends that you want at the same time. Hopefully I will be able to integrate this into crossdev. However, please keep in mind that I am not very smart.

In other news, I am not making much progress on the microcontroller side of things. Wishes of good luck are much appreciated. Most peripheral or HAL libraries I have found do not seem very good. I am currently trying to use unicore-mx, but it is very new.


NTU wrote:
Quote:
That is a shame. You should reconsider, because I think you have misunderstood the point of Gentoo and crossdev. The point of Gentoo, portage, and crossdev is to efficiently describe a system so you can compile it. The only reason you would not use it for your goal is because you want to do everything yourself.

Do everything myself... The reason I'm doing everything myself is because crossdev is apparently broken according to this thread and it isn't made for what I want.

Crossdev is broken in this case, but it is made for doing what you want to do as best as I can understand from your description. Instead of many good implementations it is better to have one extraordinary one.

NTU wrote:
Crossdev is made for being run on a Gentoo system (not the right way to do Linux development) and it's for building a cross-Gentoo system, again, not what I want. Crossdev is not minimal enough for me, too large of a root filesystem with unnecessary bloat, and doesn't even work right according to this thread. Your need to tell me what I want just irritates me. All this talk about you wanting me to be a crossdev developer when it's goal is something completely different than what I have in mind, I'm starting to think the only person here who should join their project is you as their PR rep. I tried helping you and I'm offering valid advice but now I'm just getting frustrated and more confused. Even with @system and stripping USE flags, it'll still have utilities which I don't need.

I just explained why all of these things you are saying are not necessarily true. If you are interested in discussing the suitability of crossdev for your purposes please address things I said in one of my replies to you. Also, understand that the only reason I am bothering to suggest it as an alternative is due to my and other's experience solving similar problems.

The only very large and potentially extraneous packages that @system has in it are what other distributions call build-essential, e.g. binutils, gcc, and make. There's actually not enough there to compile complex, non-essential projects, and you can remove those from @system in your target's overlay.

NTU wrote:
Hu wrote:
NTU wrote:
made for being run on a Gentoo system (not the right way to do Linux development)
This sounds strange to me. What do you think is the proper way to do Linux development if not from a Linux system?


Oh I see, this is one of those "anything you say can and will be used against you" situations. Allow me to clarify.

"made for being run on a Gentoo system" -> "made exclusively for being run on a Gentoo system."

This is my last reply to this cancerous thread. Hope you guys can fix the issue at hand here but this is where I wash my hands of this situation.

Would you rather we discuss things you never said? Unfortunately, I do not understand what you mean by this post. You do not need to run Gentoo using crossdev generated packages. You can run whatever distribution you want, but that will probably entail replacing your generated packages with the packages in another distribution's package manager after a couple of boots. If you don't want to use the package manager you can delete most of the (already sparse) directory structure in /usr/<chost> although there are some configuration files in there you should keep.

I apologize if I came off as confrontational, but I do not think anybody meant what they said in that way.


R0b0t1.


Last edited by R0b0t1 on Sun Aug 20, 2017 1:39 am; edited 1 time in total
Back to top
View user's profile Send private message
cwr
Veteran
Veteran


Joined: 17 Dec 2005
Posts: 1969

PostPosted: Sat Aug 19, 2017 3:41 pm    Post subject: Reply with quote

Well, I've used crossdev to build cross-compiled Gentoo systems for ARM, but I've also used
it simply to build a cross-compiler for AVR CPUs such as Arduino. I don't see why you couldn't
copy the gcc binaries and libraries to another similar system and use them there, for that
matter, though I've never tried it.

Will
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum