Re: building multilibs broken

["Michael Ambrus" <ambrmi09 at gmail dot com>]

Hi Dave,
I have no immediate solution for your problem but some pointers that
might be helpful.

In the /newlib/libc/misc/init.c file you have #ifdef
HAVE_INITFINI_ARRAY that to me indicates it must be involved in your
problem.

I've just checked with a recent build of a multi-lib target of mine
and I can verify that there are indeed several targ-include
directories in the build (one for each multilib library). Each of them
has it's own newlib.h and I figure that the one your -isystem is
currently pointing out is the one you need to check. In my case there
were 27 newlib.h which were all identical.

However, whence the tool-chain gets installed the multiple header
files files (including newlib.h) seems to be replaced with only one
(valid) copy which supports Jeff's conclusion.

It would be interesting to know if you can determine any differences
between newlib.h of your various build-hosts (i.e.
mingw/debian/freeBSD). They should be identical and if they differ it
could indicate a failure in the newlib build/configuration scripts.

Also double check that the newlib.h that gets installed has the same
contents as in your build. I've noticed that in rare cases and for
some build-hosts, the installation process of the headers is changing
the contents of the files (adding/removing prefixes for defines).

Regards
/Michael


On 5/5/07, Dave Murphy <wintermute2k4@ntlworld.com> wrote:
> Hi,
>
> I've been bitten by a similar issue to this one
>
> http://sourceware.org/ml/newlib/2006/msg00502.html
>
> The toolchain I'm building is arm-eabi
>
> arm-eabi-gcc -print-multi-lib says
>
> .;
> thumb;@mthumb
> be;@mbig-endian
> thumb/be;@mthumb@mbig-endian
>
>
> The problem was noticed because the thumb libc  was missing
> __libc_init_array but the arm libraries weren't. Adding a #error to
> init.c stopped the build  at this point.
>
> Making all in misc
> gmake[8]: Entering directory
> `/usr/home/piso/buildscripts/test-build/newlib-build/arm-eabi/thumb/newlib/libc/misc'
> arm-eabi-gcc
> -B/usr/home/piso/buildscripts/test-build/newlib-build/arm-eabi/newlib/
> -isystem
> /usr/home/piso/buildscripts/test-build/newlib-build/arm-eabi/newlib/targ-include
> -isystem
> /usr/home/piso/buildscripts/test-build/newlib-1.15.0/newlib/libc/include
> -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
> -DPACKAGE_VERSION=\"1.15.0\" -DPACKAGE_STRING=\"newlib\ 1.15.0\"
> -DPACKAGE_BUGREPORT=\"\"  -I.
> -I../../../../../../newlib-1.15.0/newlib/libc/misc -O2 -D__NO_SYSCALLS__
> -fno-builtin      -O2 -DREENTRANT_SYSCALLS_PROVIDED   -mthumb -c -o
> lib_a-init.o `test -f 'init.c' || echo
> '../../../../../../newlib-1.15.0/newlib/libc/misc/'`init.c
> ../../../../../../newlib-1.15.0/newlib/libc/misc/init.c:17:2: error:
> #error What the ...?
> gmake[8]: *** [lib_a-init.o] Error 1
>
> $ find ./ -name targ-include
> ./arm-eabi/thumb/newlib/targ-include
>
>
> Exactly the same symptoms as Shaun was experiencing.
>
> The really weird thing about this is that it doesn't happen on my
> msys/mingw build or a debian build but breaks on a freeBSD system.
> Another user did report similar symptoms when trying to insert the
> Digital Mars compiler into devkitARM and I believe that may be related.
>
> Jeff said that there should only be one targ-include but that appears
> not to be the case or at least targ-include is being copied to several
> places in the build tree.
>
> the -isystem path appears to be coming from the top level configure
> where it sets FLAGS_FOR_TARGET
>
> FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -B$$r/$(TARGET_SUBDIR)/newlib/
> -isystem $$r/$(TARGET_SUBDIR)/newlib/targ-include -isystem
> $$s/newlib/libc/include'
>
>
> I'd hazard a guess that $(TARGET_SUBDIR) isn't set when the multilib
> dirs are being configured. Unfortunately I'm a bit lost atm, does anyone
> have any suggestions what I might need to patch to get the correct
> -isystem path?
>
> Dave