On Tuesday, 28 April 2015 at 02:11:06 UTC, Jens Bauer wrote:
> On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:
>> The build script:
>> ../gcc/configure --disable-bootstrap \
>> --enable-languages=c,d  --disable-nls --target=arm-eabi \
>> --without-headers  --with-newlib --without-isl --without-cloog \
>> --disable-libphobos --disable-libstdcxx --disable-libbacktrace\
>> --enable-multilib
>
> You probably didn't mean to have the backslash right next to --disable-libbacktrace.
> This results in the following switch:
>
> --disable-libbacktrace--enable-multilib
>
> ... which makes it build alright. (multilib is enabled by default).
> If adding a space before --enable-multilib, then I get a build error; a part of cc1 seem to require libbacktrace.
>
> Thus I believe removing --disable-libbacktrace would be OK to do.
>
> I'm still in the process of building/modifying, so it'll take a while before I report my best results.
> So far, it looks like GCC-4.9.2 can be built with multilib if using --disable-bootstrap.

Yes, my mistake. I just made a build with the corrected version with success.

On Monday, 27 April 2015 at 18:26:35 UTC, Jens Bauer wrote:
> On Monday, 27 April 2015 at 13:16:10 UTC, Iain Buclaw wrote:
>> On 27 April 2015 at 15:05, Jens Bauer via Digitalmars-d
> {snip}
>>> As you see, config.h, libstdc++ and multilib are all present in this chunk.
>>
>> Try building with --disable-libstdcxx as in the suggestion from Timo.
>
> Unfortunately, it still fails:
[...]

The way I've gotten around this is to do "make all-gcc".

According to http://www.mingw.org/wiki/HostedCrossCompilerHOWTO:

"The make targets all-gcc and install-gcc are used here to
prevent the build process from attempting to build and install
the C++ compiler and libraries before we have the base C
libraries built and installed."

Mike

On Tuesday, 28 April 2015 at 02:18:29 UTC, Mike wrote:
> On Tuesday, 28 April 2015 at 02:12:11 UTC, Jens Bauer wrote:
>>
>> You don't have to wait for an Arch Linux release of GCC 5.1,
>
> I always thought we needed to build our cross-compilers with the same version as the host in order to have confidence in the build.

I've never used anything later than GCC-4.2 to build GCC 3.x.x ... 4.9.2
-So you can absolutely use this or anything later to build your toolchain. :)
There's no real difference in building a cross toolchain and building a native toolchain (except from some things acts up, but it'll do that with any compiler version anyway).

On Tuesday, 28 April 2015 at 04:05:15 UTC, Mike wrote:
> On Tuesday, 28 April 2015 at 00:34:42 UTC, Mike wrote:
> [...]
>>
>> If you suspect it might work for GCC 4.9.2, I'll give it a try.
>
> I tested this script generating an arm-none-eabil 4.9.2 cross-compiler with a 4.9.2 host.  My build script is here:  https://github.com/JinShil/arm-none-eabi-gdc

What ? -Are gmp, mpc and mpfr not required anymore ?

Today I'll do more experiments. I didn't succeed yesterday, so it may take a bit more trial and error (I'm used to it anyway, as it took me 2 years to get a working GCC toolchain on this computer - please don't mention brew, fink and the toolchain scripts that are made for intel - they don't work).

On Tuesday, 28 April 2015 at 06:32:16 UTC, Mike wrote:
> On Monday, 27 April 2015 at 18:26:35 UTC, Jens Bauer wrote:
>> On Monday, 27 April 2015 at 13:16:10 UTC, Iain Buclaw wrote:
>>> On 27 April 2015 at 15:05, Jens Bauer via Digitalmars-d
>> {snip}
>>>> As you see, config.h, libstdc++ and multilib are all present in this chunk.
>>>
>>> Try building with --disable-libstdcxx as in the suggestion from Timo.
>>
>> Unfortunately, it still fails:
> [...]
>
> The way I've gotten around this is to do "make all-gcc".

This is what I use as well, but that doesn't seem to let my second stage pass.

On Tuesday, 28 April 2015 at 12:13:38 UTC, Jens Bauer wrote:
> On Tuesday, 28 April 2015 at 04:05:15 UTC, Mike wrote:
>> On Tuesday, 28 April 2015 at 00:34:42 UTC, Mike wrote:
>> [...]
>>>
>>> If you suspect it might work for GCC 4.9.2, I'll give it a try.
>>
>> I tested this script generating an arm-none-eabil 4.9.2 cross-compiler with a 4.9.2 host.  My build script is here:  https://github.com/JinShil/arm-none-eabi-gdc
>
> What ? -Are gmp, mpc and mpfr not required anymore ?

I don't see why they should be required for this use case.  I'm building a cross-compiler that will run on my Linux 64-bit host.  Since I already have a native compiler for my host, I already have those libraries.  Therefore, I just need to build the cross-compiler and link it to those libraries (At least, that's how I understand it).  If I were to build a canadian cross-compiler, that would be different.

Mike

On Wednesday, 29 April 2015 at 03:11:05 UTC, Mike wrote:
> On Tuesday, 28 April 2015 at 12:13:38 UTC, Jens Bauer wrote:
>>
>> What ? -Are gmp, mpc and mpfr not required anymore ?
>
> I don't see why they should be required for this use case.  I'm building a cross-compiler that will run on my Linux 64-bit host.  Since I already have a native compiler for my host, I already have those libraries.  Therefore, I just need to build the cross-compiler and link it to those libraries (At least, that's how I understand it).  If I were to build a canadian cross-compiler, that would be different.

Alright. I just tried without those libraries and I get build-errors, so they're still required.
(They're actually required at your end, too, but as you have them installed, the installed libraries will be used).

I've been building and re-building the past few days; I still haven't found out why my crti.o, libgcc.o and others are missing, but I'm getting closer.

I've also improved my build-system slightly, so that it's almost presentable.
A number of variables plus the configure arguments are set up at the beginning. After that, some helper-functions are set up, then the sources are downloaded+depacked or just cloned (but only if necessary). After this, they're patched and compressed (only first time). Finally they're built in a clean build directory.
The build-system is fairly server-friendly; it allows you to set up your own Web-server as a cache; you only need to set an environment variable called DL_CACHE for this. It also tries to shorten the build-time by only doing what's necessary (though I'm building from scratch each time). At the end, the number of hours, minutes and seconds is shown. Currently for my PowerMac G5 QuadCore/2.5GHz, it takes approximately 48 minutes (binutils+GCC+newlib; a second GCC would take approximately 50 minutes extra).
... I'll try and make a paste later, when it's been polished slightly. It's possible to run it line-by-line or as a script. I've also made it as a .pdf file.

On Tuesday, 28 April 2015 at 00:34:42 UTC, Mike wrote:
> On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:
>
> Nevertheless, when GCC 5.1 is official released for my distribution, I'll give it a test (if it's not too late by then).
>
> If you suspect it might work for GCC 4.9.2, I'll give it a try.

I think I might have something usable now.

http://d.gpio.dk/dl/Build%20a%20GDC%20toolchain.pdf

Bonus: I recommend rebuilding tar for multi-core support:
http://d.gpio.dk/dl/Upgrade%20tar.pdf
I could not build pigz, but if you can build it, you can add it using --with-gzip=pigz

On 04/27/2015 03:42 PM, Timo Sintonen wrote:
> 
> The basic idea has been to make as little changes as possible. I started by compiling object.d and then added files and modified them one by one until there were no compile or link errors. Then I added other files that could be compiled without errors. It is not guaranteed that all features work and the list of files have changed from version to version.

Wonder if it makes more sense to start from zero and add as few files as
possible.
Druntime doesn't do much useful stuff for a µC anyhow.

- GC and rt.lifetime (new, arrays)
- Moduleinfo
- EH unwind support
- AA implementation
- vectorized array ops
- core.time/sync/thread/demangle

What might be interesting is this.

- core.bitop
- maybe core.atomic
- some gcc simd module
- libc bindings for core.stdc.math and core.stdc.stdio for printf

On Thursday, 30 April 2015 at 00:14:18 UTC, Martin Nowak wrote:
> On 04/27/2015 03:42 PM, Timo Sintonen wrote:
>> 
>> The basic idea has been to make as little changes as possible. I started
>
> Wonder if it makes more sense to start from zero and add as few files as possible.

That was my thought too.

> Druntime doesn't do much useful stuff for a µC anyhow.

I agree. Things like stdint is needed very much. -But this does not really add anything to the binary file size.

> What might be interesting is this.
>
> - core.bitop
> - maybe core.atomic
> - some gcc simd module
> - libc bindings for core.stdc.math and core.stdc.stdio for printf

Indeed. Personally I hate printf, FILE* and the like, but a huge crowd needs them, so I'll admit defeat here. ;)

My thoughts are in the direction: "lightweight", "quick", "functional".
Eg. "Everything that does not add to the executable size on its own is welcome." and "If it's absolutely required, then OK, add it."
-But I'd say that everything else should be up to the user to add (if possible).
Some people might not use strings - normally I only use zero-terminated character arrays myself, so I would consider this optional. But on the other hand, strings in D are very powerful, so I would hate if I weren't able to use them. Associate arrays are in the same boat.
Thus, if the user is lucky enough to have a file system (eg. SD-card), then it would make sense to have a FILE*. On the other hand, I wouldn't like the FILE* on anything that does not have any disk-like peripherals.