This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See crosstool-NG for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

AW: Canadian cross build fails


Reinoud, Matthias,

the patch is simply:
--- gcc-4.9.2.orig/libgcc/crtstuff.c    2014-03-10 19:31:20.000000000 +0100
+++ gcc-4.9.2/libgcc/crtstuff.c 2014-12-12 21:28:55.715789167 +0100
@@ -56,6 +56,7 @@
 #undef rlim_t
 #undef ssize_t
 #undef vfork
+#undef caddr_t
 #include "tconfig.h"
 #include "tsystem.h"
 #include "coretypes.h"

I did not take the time to really correct the problem, that's why I used this hack and didn't send the patch to this ML.

I hope I remember it correctly:
The problem is that a configuration step is missing to correctly decide if the definition of caddr_t is really necessary.
As a preliminary crtstuff.c includes auto-host.h which is not fully correct (for canadian build).

Please have a look at the comments in crtstuff.c and and at generation of auto-host.h
Then it should get clear.

Regards,
Titus

________________________________________
Von: Reinoud Koornstra <reinoudkoornstra@gmail.com>
Gesendet: Montag, 9. Februar 2015 22:06
An: Titus von Boxberg
Cc: Matthias Weißer; crossgcc@sourceware.org
Betreff: Re: Canadian cross build fails

Hmm, how did you patch caddr_t?
In racoon for example this definition is used often, and later casted
to the real structure.

#ifdef  __USE_BSD
# ifndef __daddr_t_defined
typedef __daddr_t daddr_t;
typedef __caddr_t caddr_t;

Later:

typedef char *__caddr_t;

Nothing wrong with this, this is the def in glibc though.

On Mon, Feb 9, 2015 at 6:06 AM, Titus von Boxberg
<titus@elbe-informatik.de> wrote:
> Hi,
>
> I had the same issue (with canadian for powerpc iirc).
>
> If you look into the source file causing the error you see a comment similar to "XXX fixme" or so.
>
> So the problem is known but a "real solution" is not at hand.
> Thus, I have patched the definition of caddr_t away and it works for me.
>
> Regards,
> Titus
>
>
> -----Ursprüngliche Nachricht-----
> Von: crossgcc-owner@sourceware.org [mailto:crossgcc-owner@sourceware.org] Im Auftrag von Matthias Weißer
> Gesendet: Montag, 9. Februar 2015 13:25
> An: crossgcc@sourceware.org
> Betreff: Canadian cross build fails
>
>  [INFO ]  Installing final compiler for build: done in 223.82s (at 22:21) [INFO ]  =================================================================
> [INFO ]  Installing final compiler
> [EXTRA]    Configuring gcc
> [EXTRA]    Building libiberty
> [EXTRA]    Building gcc
> [ALL  ]    arm-gs-linux-gnueabihf-cc   -mlittle-endian -march=armv7-a
> -mcpu=cortex-a9 -mtune=cortex-a9 -mfpu=vfpv3 -mhard-float -O2 -mlittle-endian -march=armv7-a  -mcpu=cortex-a9 -mtune=cortex-a9
> -mfpu=vfpv3 -mhard-float  -DIN_GCC  -DCROSS_DIRECTORY_STRUCTU RE  -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include  -I. -I. -I../.././gcc -I/$LONGPATH/.build/src/gcc-4.9.2/libgcc
> -I/$LONGPATH/.build/src/gcc-4.9.2/libgcc/.
> -I/$LONGPATH/.build/src/gcc-4.9.2/libgcc/../gcc
> -I/$LONGPATH/.build/src/gcc-4.9.2/libgcc/../include   -g0
> -finhibit-size-directive -fno-inline -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize -fno-stack-protector  -I. -I. -I../.././gcc -I/$LONGPATH/.build/src/gcc-4.9.2/libgcc
> -I/$LONGPATH/.build/src/gcc-4.9.2/libgcc/.
> -I/$LONGPATH/.build/src/gcc-4.9.2/libgcc/../gcc
> -I/$LONGPATH/.build/src/gcc-4.9.2/libgcc/../include  -o crtendS.o -MT crtendS.o -MD -MP -MF crtendS.dep  -fPIC -c /$LONGPATH/.build/src/gcc-4.9.2/libgcc/crtstuff.c -DCRT_END -DCRTSTUFFS_O
> [ALL  ]    In file included from
> /$LONGPATH/.build/src/gcc-4.9.2/libgcc/crtstuff.c:54:0:
> [ERROR]    ../.././gcc/auto-host.h:1996:17: error: two or more data
> types in declaration specifiers
> [ALL  ]     #define caddr_t char *
> [ALL  ]                     ^
> [ALL  ]    In file included from
> /$LONGPATH/.build/src/gcc-4.9.2/libgcc/../gcc/tsystem.h:90:0,
> [ALL  ]                     from
> /$LONGPATH/.build/src/gcc-4.9.2/libgcc/crtstuff.c:60:
> [ERROR]    /$LONGPATH/output/arm-gs-linux-gnueabihf/sysroot/usr/include/sys/types.h:116:26:
> error: expected identifier or '(' before ';' token
> [ALL  ]     typedef __caddr_t caddr_t;
> [ALL  ]                              ^
>
> If I check google for that error I come across the following pages:
> https://sourceware.org/ml/newlib/2014/msg00034.html
> http://www.gurucoding.com/en/pc_cross_compiler/building_binutils_gcc_mingw_vm.php
>
>
> Both suggest patching gcc autoconf or the C library itself. I can't belive that this is the correct solution to this issue. Do I miss something? What is a bit unclear to me is that I don't have to (or I missed it) specify the path to the toolchain build in step 1 to the canadian build in step 3. I do pass the toolchain from step 2 into the crosstools config as host. This is my mini-defconfig of the step 3
> toolchain:
>
>

--
For unsubscribe information see http://sourceware.org/lists.html#faq


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]