On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:
> On Sunday, 26 April 2015 at 18:23:47 UTC, Martin Nowak wrote:
>
> I have also tried for years to build a working multilib without success. Now I think I have been able to get all versions to work. I welcome everyone to test and report if this works.

You can be sure I will test it. :)
Thank you again for doing all the hard and valuable work!

On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:
> On Sunday, 26 April 2015 at 18:23:47 UTC, Martin Nowak wrote:
>
> I have also tried for years to build a working multilib without success. {snip}
>
> Please note: This is the first time ever I have suceeded. This will not work with any gcc before april. An older gcc will not build m4 or it may even not pass configuring.

Does this mean that we'll need to use GCC-5.1.0 (released April 22, 2015) ?
(I'm currently on 4.9.2, which is from october 2014)

On Monday, 27 April 2015 at 05:56:11 UTC, Iain Buclaw wrote:
> On 26 April 2015 at 22:41, Jens Bauer via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>>
>> The reason I cannot build GDC with multilib, is that I get a compile-error
>> when building the final GCC+GDC.
>> Building GCC alone without GDC gives me no such error.
>> -So if I want to have multilib support, I will have to be without GDC.
>
> Where exactly does it error?

I'm doing a rebuild now; it'll probably take 50 minutes before I got the result. I'll post a reply when I have something.

> I can't think of a sole reason why gdc/libphobos would throw an error
> in multilib builds, so it must be something collateral (libstdc++) ?

I remember something about libstdc++ problems. I forgot whether it was a missing libstdc++ after the build or if it was causing trouble with the build.

On Monday, 27 April 2015 at 10:46:09 UTC, Jens Bauer wrote:
> On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:

>>
>> I have also tried for years to build a working multilib without success. {snip}
>>
>> Please note: This is the first time ever I have suceeded. This will not work with any gcc before april. An older gcc will not build m4 or it may even not pass configuring.
>
> Does this mean that we'll need to use GCC-5.1.0 (released April 22, 2015) ?
> (I'm currently on 4.9.2, which is from october 2014)

YES! As I mentioned I used gcc 6 head but but I think there has not been big changes since 5.1 release.
I have _never_ succeeded with any previous version.

I have never had any success when using any --with options like --with-cpu or --with-multilib. Most of the time they result to a compiler that has different defaults. The configure script for libgcc uses this default compiler in its tests and it always fails somewhere because of wrong defaults.

It is also possible the libraries may have wrong set of compiler flags even they build correctly. For example: once I got a library set built for arch 5. This is totally ok because arch 7 is compatible with arch 5. There was no issues before I tried exceptions. They use callback from libgcc to druntime and this failed because of arch mismatch. Took 3 months to find out.

So it is very important that the libraries will be compiled with the same compiler flags that the application. This is also true when we will make prebuilt libdruntime. The way I have done allows to pass correct flags to each library.

Anyway, now we are here to test which is working and which is not. I hope that we geet reports from as many people as possible. The working methods will go to the wiki page.

On Monday, 27 April 2015 at 05:56:11 UTC, Iain Buclaw wrote:
> On 26 April 2015 at 22:41, Jens Bauer via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>>
{snip}
>> The reason I cannot build GDC with multilib, is that I get a
>> compile-error when building the final GCC+GDC.

Correction: it's a 'build-error', but it's caused by sed.

>> Building GCC alone without GDC gives me no such error.
>
> Where exactly does it error?

Here's the complete chunk. It's on purpose I started with config.h.

---8<-----8<-----8<-----
config.status: creating config.h
config.status: executing default-1 commands
Adding multilib support to Makefile in /Users/jens/toolchain/Source/gcc/libstdc++-v3
with_multisubdir=thumb/cortex-m4/float-abi-hard/fpuv4-sp-d16
config.status: executing libtool commands
config.status: executing include/gstdint.h commands
config.status: executing generate-headers commands
echo timestamp > stamp-pb
echo timestamp > stamp-host
echo 0 > stamp-namespace-version
echo 1 > stamp-visibility
echo 1 > stamp-extern-template
sed -e '/^#pragma/b' \
	    -e '/^#/s/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_][ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*\)/_GLIBCXX_\1/g' \
	    -e 's/_GLIBCXX_SUPPORTS_WEAK/__GXX_WEAK__/g' \
	    -e 's/_GLIBCXX___MINGW32_GLIBCXX___/__MINGW32__/g' \
	    -e 's,^#include "\(.*\)",#include <bits/\1>,g' \
	    < /Users/jens/toolchain/Source/gcc/libstdc++-v3/../libgcc/gthr.h > arm-none-eabi/bits/gthr.h
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
	    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \
	    < /Users/jens/toolchain/Source/gcc/libstdc++-v3/../libgcc/gthr-single.h > arm-none-eabi/bits/gthr-single.h
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
	    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \
	    -e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \
	    -e 's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \
	    < /Users/jens/toolchain/Source/gcc/libstdc++-v3/../libgcc/gthr-posix.h > arm-none-eabi/bits/gthr-posix.h
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
	    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \
	    -e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \
	    -e 's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \
	    -e 's,^#include "\(.*\)",#include <bits/\1>,g' \
	    < /Users/jens/toolchain/Source/gcc/libstdc++-v3/../libgcc/gthr-single.h > arm-none-eabi/bits/gthr-default.h
config.status: executing libtool commands
config.status: executing include/gstdint.h cconfig.status: executing include/gstdint.h commands
config.status: executing generate-headers commands
echo timestamp > stamp-pb
echo timestamp > stamp-host
echo 0 > stamp-namespace-version
echo 1 > stamp-visibility
echo 1 > stamp-extern-template
sed -e '/^#pragma/b' \
	    -e '/^#/s/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_][ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*\)/_GLIBCXX_\1/g' \
	    -e 's/_GLIBCXX_SUPPORTS_WEAK/__GXX_WEAK__/g' \
	    -e 's/_GLIBCXX___MINGW32_GLIBCXX___/__MINGW32__/g' \
	    -e 's,^#include "\(.*\)",#include <bits/\1>,g' \
	    < /Users/jens/toolchain/Source/gcc/libstdc++-v3/../libgcc/gthr.h > arm-none-eabi/bits/gthr.h
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
	    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \
	    < /Users/jens/toolchain/Source/gcc/libstdc++-v3/../libgcc/gthr-single.h > arm-none-eabi/bits/gthr-single.h
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
	    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \
	    -e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \
	    -e 's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \
	    < /Users/jens/toolchain/Source/gcc/libstdc++-v3/../libgcc/gthr-posix.h > arm-none-eabi/bits/gthr-posix.h
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
	    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \
	    -e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \
	    -e 's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \
	    -e 's,^#include "\(.*\)",#include <bits/\1>,g' \
	    < /Users/jens/toolchain/Source/gcc/libstdc++-v3/../libgcc/gthr-single.h > arm-none-eabi/bits/gthr-default.h
make: *** [all] Error 2
Failed
--->8----->8----->8-----

As you see, config.h, libstdc++ and multilib are all present in this chunk.

On Monday, 27 April 2015 at 07:34:52 UTC, Mike wrote:
> On Monday, 27 April 2015 at 05:22:55 UTC, Timo Sintonen wrote:
>> On Monday, 27 April 2015 at 05:19:52 UTC, Timo Sintonen wrote:
>>
>> Oops, I forget to uncomment the m4 options. The correct version is
>>>
>>> And I replace the whole gcc/config/arm/t-arm-elf with this:
>>> MULTILIB_OPTIONS  += mcpu=cortex-m0/mcpu=cortex-m3/mcpu=cortex-m4
>>> mfloat-abi=hard mfpu=fpv4-sp-d16
>>> MULTILIB_DIRNAMES += cortex-m0 cortex-m3 cortex-m4
>>> MULTILIB_REQUIRED += mcpu=cortex-m0
>>> MULTILIB_REQUIRED += mcpu=cortex-m3
>>> MULTILIB_REQUIRED += mcpu=cortex-m4 /mfloat-abi=hard  /mfpu=fpv4-sp-d16
>>> MULTILIB_EXTRA_OPTS += mthumb
>
> The toolchain at https://launchpad.net/gcc-arm-embedded doesn't require this modification, so I'm wondering if there's another way.  My understanding is that this is unlreated to GDC itself, so we should be able to follow essentially the same procedure as the embedded C/C++ toolchains, right?
>
> They have their build scripts included in their source package, so I spent a little time analyzing their build scripts today, and I see they are using the following config option:
>
> "--with-multilib-list=armv6-m,armv7-m,armv7e-m,cortex-m7,armv7-r"
>
> I'm wondering if that alone will do it.  I guess I'll give it a try later and let you all know what I find.
>
> Mike

There are two ways to make t-arm-elf: inclusive and exclusive. The exclusive way is to list all combinations and exclude unwanted with MULTILIB_EXCEPYIONS. This has been the usual way to do this. I have not seen the inclusive method I use.

How they tell that m4 should use hard float and the rest do not use?  If you can do the build, check with readelf that the libraries have correct architecture and compiler flags

On 27 April 2015 at 15:05, Jens Bauer via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 27 April 2015 at 05:56:11 UTC, Iain Buclaw wrote:
>>
>> On 26 April 2015 at 22:41, Jens Bauer via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>>
> {snip}
>>>
>>> The reason I cannot build GDC with multilib, is that I get a compile-error when building the final GCC+GDC.
>
>
> Correction: it's a 'build-error', but it's caused by sed.
>
>>> Building GCC alone without GDC gives me no such error.
>>
>>
>> Where exactly does it error?
>
>
> Here's the complete chunk. It's on purpose I started with config.h.
>

<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.

Regards
Iain

On Monday, 27 April 2015 at 07:55:10 UTC, Martin Nowak wrote:

> Great, I tried to find out how GDC binaries are build, but couldn't find any script.

Instructions here:
http://wiki.dlang.org/GDC/Cross_Compiler/Generic
or here:
https://bitbucket.org/timosi/minlibd/wiki/gdc_cross_compiler

There are other instructions in
http://wiki.dlang.org/GDC/Installation
but I think there is no script

>
> How much stuff do you strip out of runtime for minilibd? It still seems to contain fat typeinfo and moduleinfo. We'd probably need the equivalent of -no-rtti and -fno-exceptions and add -fno-moduleinfo.

It uses -no-moduleinfo but. The module related stuff in object.d has been removed but there may be some code elsewhere. I got exceptions to work but for smaller systems they should be made removable.

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.

Required and optional files can be found in Makefile
https://bitbucket.org/timosi/minlibd/src/15e88941c534a19e753fa0eebcd053b17392b7ad/libdruntime/Makefile?at=default

Required changes to these files
https://bitbucket.org/timosi/minlibd/src/15e88941c534a19e753fa0eebcd053b17392b7ad/Changes?at=default

A while ago someone turned this change list to a bugzilla issue 14101, and there is also related issue 14100

>
> Maybe building a few different configurations of minilibd makes sense.
> The ARM toolchain comes with a nano.spec to select newlib-nano and size optimized libc++.
> https://launchpadlibrarian.net/200699979/readme.txt

I have not yet needed libc in my work but of course we can have one.
I repeat here that all libraries have to be built with the same compiler flags that the application. Otherwise hard to find bugs may occur.

On Monday, 27 April 2015 at 07:34:52 UTC, Mike wrote:

>
> The toolchain at https://launchpad.net/gcc-arm-embedded doesn't require this modification, so I'm wondering if there's another way.  My understanding is that this is unlreated to GDC itself, so we should be able to follow essentially the same procedure as the embedded C/C++ toolchains, right?
>
> They have their build scripts included in their source package, so I spent a little time analyzing their build scripts today, and I see they are using the following config option:
>
> "--with-multilib-list=armv6-m,armv7-m,armv7e-m,cortex-m7,armv7-r"
>
> I'm wondering if that alone will do it.  I guess I'll give it a try later and let you all know what I find.
>
> Mike

They have not touched t-arm-elf. Instead they have created t-aprofile where they have recipes for a huge collection of libraries. They also have used the exclusive method and only a real guru can understand what this file is doing. I think there will be more than 10 different libraries built.

Somewhere in configure options they have put an option that tells configure to use this file instead of t-arm-elf.

On 27 April 2015 at 18:08, Timo Sintonen via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 27 April 2015 at 07:34:52 UTC, Mike wrote:
>
>>
>> The toolchain at https://launchpad.net/gcc-arm-embedded doesn't require this modification, so I'm wondering if there's another way.  My understanding is that this is unlreated to GDC itself, so we should be able to follow essentially the same procedure as the embedded C/C++ toolchains, right?
>>
>> They have their build scripts included in their source package, so I spent a little time analyzing their build scripts today, and I see they are using the following config option:
>>
>> "--with-multilib-list=armv6-m,armv7-m,armv7e-m,cortex-m7,armv7-r"
>>
>> I'm wondering if that alone will do it.  I guess I'll give it a try later and let you all know what I find.
>>
>> Mike
>
>
> They have not touched t-arm-elf. Instead they have created t-aprofile where they have recipes for a huge collection of libraries. They also have used the exclusive method and only a real guru can understand what this file is doing. I think there will be more than 10 different libraries built.
>
> Somewhere in configure options they have put an option that tells configure to use this file instead of t-arm-elf.

(That would be gcc/config.gcc)