[Buildroot] GIT or SVN

[Buildroot] GIT or SVN

[Hinko Kocevar]

Hello,

I'm new to the uclibc buildroot. I've noticed that there are two repositories: GIT and SVN. GIT looks more up2date. Is GIT the tree to use?

Also, I'm trying to create a uclibc toolchain for cris architecture. Has anyone tried that? I'm trying with:
uclibc-0.9.29
gcc-4.3.0
binutils-2.18
linux-2.6.25.5

Here are two patches to make GIT tree compile binutils and uClibc.

Best regards,
Hinko

-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si

-------------- next part --------------
A non-text attachment was scrubbed...
Name: uclibc.patch
Type: text/x-patch
Size: 676 bytes
Desc: not available
Url : http://busybox.net/lists/buildroot/attachments/20080619/4b9a39c2/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: binutils.patch
Type: text/x-patch
Size: 1413 bytes
Desc: not available
Url : http://busybox.net/lists/buildroot/attachments/20080619/4b9a39c2/attachment-0001.bin 

[Buildroot] GIT or SVN

[Hinko Kocevar]

Hinko Kocevar wrote:
> Hello,
> 
> I'm new to the uclibc buildroot. I've noticed that there are two repositories: GIT and SVN. GIT looks more up2date. Is GIT the tree to use?
> 
> Also, I'm trying to create a uclibc toolchain for cris architecture. 

And here is the 1st problem with cris toolchain. When building gcc-final libgomp wants threads... The gcc was configured with threads enabled and BR2 has BR2_PTHREADS_OLD=y. Here is gcc configure line:
$ /work/stage/buildroot/toolchain_build_cris/gcc-4.3.0/configure --prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=cris-linux-uclibc --enable-languages=c --with-sysroot=/work/stage/buildroot/build_cris/staging_dir --with-build-time-tools=/work/stage/buildroot/build_cris/staging_dir/usr/cris-linux-uclibc/bin --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --disable-shared --with-gmp=/work/stage/buildroot/toolchain_build_cris/gmp --with-mpfr=/work/stage/buildroot/toolchain_build_cris/mpfr --disable-nls --enable-threads --disable-multilib --disable-largefile

FAILURE:

...
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
libtool.m4: error: problem compiling FC test program
checking for cris-linux-uclibc-gfortran -B/usr/cris-linux-uclibc/bin/ -B/usr/cris-linux-uclibc/lib/ -isystem /usr/cris-linux-uclibc/include -isystem /usr/cris-linux-uclibc/sys-include option to produce PIC... -fPIC
checking if cris-linux-uclibc-gfortran -B/usr/cris-linux-uclibc/bin/ -B/usr/cris-linux-uclibc/lib/ -isystem /usr/cris-linux-uclibc/include -isystem /usr/cris-linux-uclibc/sys-include PIC flag -fPIC works... no
checking if cris-linux-uclibc-gfortran -B/usr/cris-linux-uclibc/bin/ -B/usr/cris-linux-uclibc/lib/ -isystem /usr/cris-linux-uclibc/include -isystem /usr/cris-linux-uclibc/sys-include static flag -static works... no
checking if cris-linux-uclibc-gfortran -B/usr/cris-linux-uclibc/bin/ -B/usr/cris-linux-uclibc/lib/ -isystem /usr/cris-linux-uclibc/include -isystem /usr/cris-linux-uclibc/sys-include supports -c -o file.o... no
checking if cris-linux-uclibc-gfortran -B/usr/cris-linux-uclibc/bin/ -B/usr/cris-linux-uclibc/lib/ -isystem /usr/cris-linux-uclibc/include -isystem /usr/cris-linux-uclibc/sys-include supports -c -o file.o... (cached) no
checking whether the cris-linux-uclibc-gfortran -B/usr/cris-linux-uclibc/bin/ -B/usr/cris-linux-uclibc/lib/ -isystem /usr/cris-linux-uclibc/include -isystem /usr/cris-linux-uclibc/sys-include linker (/work/stage/buildroot/toolchain_build_cris/gcc-4.3.0-final/./gcc/collect-ld) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking for ANSI C header files... (cached) yes
checking whether time.h and sys/time.h may both be included... yes
checking for unistd.h... (cached) yes
checking semaphore.h usability... yes
checking semaphore.h presence... yes
checking for semaphore.h... yes
checking sys/loadavg.h usability... no
checking sys/loadavg.h presence... no
checking for sys/loadavg.h... no
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
looking for a compliant stdint.h in stdint.h, checking for uintmax_t... yes
checking for uintptr_t... yes
checking for int_least32_t... yes
checking for int_fast32_t... yes
checking for uint64_t... yes
checking what to include in gstdint.h... stdint.h (already complete)
configure: error: Pthreads are required to build libgomp
make[2]: *** [configure-target-libgomp] Error 1
make[2]: Leaving directory `/work/stage/buildroot/toolchain_build_cris/gcc-4.3.0-final'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/work/stage/buildroot/toolchain_build_cris/gcc-4.3.0-final'
make: *** [/work/stage/buildroot/toolchain_build_cris/gcc-4.3.0-final/.compiled] Error 2


I'll try older gcc version to see if the error persists.

Regards,
Hinko

-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si

[Buildroot] GIT or SVN

[Bernhard Fischer]

On Thu, Jun 19, 2008 at 12:53:51PM +0200, Hinko Kocevar wrote:
>Hinko Kocevar wrote:
>> Hello,
>> 
>> I'm new to the uclibc buildroot. I've noticed that there are two repositories: GIT and SVN. GIT looks more up2date. Is GIT the tree to use?
>> 
>> Also, I'm trying to create a uclibc toolchain for cris architecture. 

Thanks for noticing my typo and correcting the URL. Applied.

I didn't try to build cris. Please use 4.3.1 and disable libgomp:
$ grep gomp .config
BR2_EXTRA_GCC_CONFIG_OPTIONS="--disable-libgomp --disable-libssp"
BR2_EXTRA_TARGET_GCC_CONFIG_OPTIONS="--disable-libgomp --disable-libssp"

I'm trying to build such a cris compiler now and will let you know how
it goes.

Thanks again,
Bernhard

[Buildroot] GIT or SVN

[Hinko Kocevar]

Bernhard Fischer wrote:
> On Thu, Jun 19, 2008 at 12:53:51PM +0200, Hinko Kocevar wrote:
>> Hinko Kocevar wrote:
>>> Hello,
>>>
>>> I'm new to the uclibc buildroot. I've noticed that there are two repositories: GIT and SVN. GIT looks more up2date. Is GIT the tree to use?
>>>
>>> Also, I'm trying to create a uclibc toolchain for cris architecture. 
> 
> Thanks for noticing my typo and correcting the URL. Applied.
> 
> I didn't try to build cris. Please use 4.3.1 and disable libgomp:
> $ grep gomp .config
> BR2_EXTRA_GCC_CONFIG_OPTIONS="--disable-libgomp --disable-libssp"
> BR2_EXTRA_TARGET_GCC_CONFIG_OPTIONS="--disable-libgomp --disable-libssp"
> 
> I'm trying to build such a cris compiler now and will let you know how
> it goes.

I've tried it too. It passes the gcc-final compilation with 'BR2_EXTRA_GCC_CONFIG_OPTIONS="--disable-libgomp", but I have to disable shared library support and threads to make gcc-final compile. Otherwise uCLibc fails with:
...
  CC libc/unistd/usershell.os
  CC libc/unistd/usleep.os
  CC libpthread/linuxthreads.old/forward.oS
  CC libpthread/linuxthreads.old/libc_pthread_init.oS
  CC libc/misc/internals/__uClibc_main.oS
  CC libpthread/linuxthreads.old/libc_pthread_init.os
  CC libc/misc/internals/__uClibc_main.os
  CC libc/stdlib/atexit.os
  AS lib/crt1.o
  AS lib/Scrt1.o
  AS lib/crti.o
  AS lib/crtn.o
  STRIP -x -R .note -R .comment lib/libc.a
  AR cr lib/libc.a
  STRIP -x -R .note -R .comment lib/uclibc_nonshared.a
  AR cr lib/uclibc_nonshared.a
  AR cr libc/libc_so.a
  LD libuClibc-0.9.29.so
libc/libc_so.a(libc_pthread_init.oS): In function `testandset':
libc_pthread_init.c:(.text+0x0): multiple definition of `testandset'
libc/libc_so.a(forward.oS):forward.c:(.text+0x0): first defined here
make[2]: *** [lib/libc.so] Error 1
make[1]: *** [lib/libc.so.0] Error 2
make[1]: Leaving directory `/work/stage/buildroot/toolchain_build_cris/uClibc-0.9.29'
make: *** [/work/stage/buildroot/toolchain_build_cris/uClibc-0.9.29/lib/libc.a] Error 2



Also inspecting the uClibc make parameters UCLIBC_EXTRA_LDFLAGS and UCLIBC_EXTRA_CFLAGS - where are they used?

/usr/bin/make -j1 -C /work/stage/buildroot/toolchain_build_cris/uClibc-0.9.29 \
		PREFIX= \
		DEVEL_PREFIX=/ \
		RUNTIME_PREFIX=/ \
		HOSTCC="/usr/bin/gcc" \
		BUILD_CFLAGS="" \
		BUILD_LDFLAGS="" \
		UCLIBC_EXTRA_LDFLAGS=" --sysroot=/work/stage/buildroot/build_cris/staging_dir/ -L/work/stage/buildroot/build_cris/staging_dir/lib -L/work/stage/buildroot/build_cris/staging_dir/usr/lib" \
		UCLIBC_EXTRA_CFLAGS=" --sysroot=/work/stage/buildroot/build_cris/staging_dir/ -isysroot /work/stage/buildroot/build_cris/staging_dir -I=/usr/include -Os -pipe  -I/work/stage/buildroot/build_cris/staging_dir/usr/include " \
		all


And UCLIBC_EXTRA_CFLAGS has '-I=/usr/include' that seems a bit odd...

Regards,
Hinko

-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si

[Buildroot] GIT or SVN

[Bernhard Fischer]

On Thu, Jun 19, 2008 at 01:54:20PM +0200, Hinko Kocevar wrote:

>  LD libuClibc-0.9.29.so
>libc/libc_so.a(libc_pthread_init.oS): In function `testandset':
>libc_pthread_init.c:(.text+0x0): multiple definition of `testandset'
>libc/libc_so.a(forward.oS):forward.c:(.text+0x0): first defined here
>make[2]: *** [lib/libc.so] Error 1
>make[1]: *** [lib/libc.so.0] Error 2
>make[1]: Leaving directory `/work/stage/buildroot/toolchain_build_cris/uClibc-0.9.29'
>make: *** [/work/stage/buildroot/toolchain_build_cris/uClibc-0.9.29/lib/libc.a] Error 2

Sounds familiar. I'll take care of it in the evening.

>And UCLIBC_EXTRA_CFLAGS has '-I=/usr/include' that seems a bit odd...

That's fine. Read the documentation of the compiler for further details.

[Buildroot] GIT or SVN

[Hinko Kocevar]

Bernhard Fischer wrote:
> On Thu, Jun 19, 2008 at 01:54:20PM +0200, Hinko Kocevar wrote:
> 
>>  LD libuClibc-0.9.29.so
>> libc/libc_so.a(libc_pthread_init.oS): In function `testandset':
>> libc_pthread_init.c:(.text+0x0): multiple definition of `testandset'
>> libc/libc_so.a(forward.oS):forward.c:(.text+0x0): first defined here
>> make[2]: *** [lib/libc.so] Error 1
>> make[1]: *** [lib/libc.so.0] Error 2
>> make[1]: Leaving directory `/work/stage/buildroot/toolchain_build_cris/uClibc-0.9.29'
>> make: *** [/work/stage/buildroot/toolchain_build_cris/uClibc-0.9.29/lib/libc.a] Error 2
> 
> Sounds familiar. I'll take care of it in the evening.

Good, thanks.

> 
>> And UCLIBC_EXTRA_CFLAGS has '-I=/usr/include' that seems a bit odd...
> 
> That's fine. Read the documentation of the compiler for further details.

Will do - can't get one valid result from google for "-I=/usr/include" :(

Regards,
Hinko

-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si

[Buildroot] GIT or SVN

[Hinko Kocevar]

Bernhard Fischer wrote:
> On Thu, Jun 19, 2008 at 01:54:20PM +0200, Hinko Kocevar wrote:
> 
>>  LD libuClibc-0.9.29.so
>> libc/libc_so.a(libc_pthread_init.oS): In function `testandset':
>> libc_pthread_init.c:(.text+0x0): multiple definition of `testandset'
>> libc/libc_so.a(forward.oS):forward.c:(.text+0x0): first defined here
>> make[2]: *** [lib/libc.so] Error 1
>> make[1]: *** [lib/libc.so.0] Error 2
>> make[1]: Leaving directory `/work/stage/buildroot/toolchain_build_cris/uClibc-0.9.29'
>> make: *** [/work/stage/buildroot/toolchain_build_cris/uClibc-0.9.29/lib/libc.a] Error 2
> 
> Sounds familiar. I'll take care of it in the evening.
> 

This patch takes care of the uClibc compilation problem for me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uClibc-0.9.29-cris-pthreads.patch
Type: text/x-patch
Size: 593 bytes
Desc: not available
Url : http://busybox.net/lists/buildroot/attachments/20080619/70794756/attachment-0001.bin 

[Buildroot] GIT or SVN

[Peter Korsgaard]

>>>>> "Hinko" == Hinko Kocevar <hinko.kocevar@cetrtapot.si> writes:

 Hinko> Hello,
 Hinko> I'm new to the uclibc buildroot. I've noticed that there are
 Hinko> two repositories: GIT and SVN. GIT looks more up2date. Is GIT
 Hinko> the tree to use?

It depends ;) Bernhards git tree is more uptodate regarding toolchain,
but the svn tree has more/newer packages and more developers.

-- 
Bye, Peter Korsgaard

[Buildroot] GIT or SVN

[Bernhard Fischer]

On Thu, Jun 19, 2008 at 09:09:00PM +0200, Peter Korsgaard wrote:
>>>>>> "Hinko" == Hinko Kocevar <hinko.kocevar@cetrtapot.si> writes:
>
> Hinko> Hello,
> Hinko> I'm new to the uclibc buildroot. I've noticed that there are
> Hinko> two repositories: GIT and SVN. GIT looks more up2date. Is GIT
> Hinko> the tree to use?
>
>It depends ;) Bernhards git tree is more uptodate regarding toolchain,
>but the svn tree has more/newer packages and more developers.

Exactly. I basically ignore packages completely, apart from the, let's
say 5-10 that i actually use or find useful.

[Buildroot] GIT or SVN

[Hinko Kocevar]

Bernhard Fischer wrote:
> On Thu, Jun 19, 2008 at 09:09:00PM +0200, Peter Korsgaard wrote:
>>>>>>> "Hinko" == Hinko Kocevar <hinko.kocevar@cetrtapot.si> writes:
>> Hinko> Hello,
>> Hinko> I'm new to the uclibc buildroot. I've noticed that there are
>> Hinko> two repositories: GIT and SVN. GIT looks more up2date. Is GIT
>> Hinko> the tree to use?
>>
>> It depends ;) Bernhards git tree is more uptodate regarding toolchain,
>> but the svn tree has more/newer packages and more developers.
> 
> Exactly. I basically ignore packages completely, apart from the, let's
> say 5-10 that i actually use or find useful.

I've been looking for recent gcc for the cris arch as I was seeing gcc internal errors when compiling kernel or openssl source with gcc 4.2.3 or 4.2.4.
With gcc 4.3.1 gcc internal errors went away, so I'm really glad I found the GIT tree!

-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si

[Buildroot] GIT or SVN

[Bernhard Fischer]

On Fri, Jun 20, 2008 at 10:40:22AM +0200, Hinko Kocevar wrote:

>With gcc 4.3.1 gcc internal errors went away, so I'm really glad I found the GIT tree!

I have improved (i hope) the cris support, configuration-wise, please
pull and let me know if it suits your needs.

cheers,
Bernhard

[Buildroot] GIT or SVN

[Hinko Kocevar]

Bernhard Fischer wrote:
> On Fri, Jun 20, 2008 at 10:40:22AM +0200, Hinko Kocevar wrote:
> 
>> With gcc 4.3.1 gcc internal errors went away, so I'm really glad I found the GIT tree!
> 
> I have improved (i hope) the cris support, configuration-wise, please
> pull and let me know if it suits your needs.
> 

Nice. I'm trying it out right now..

BTW:
Have you successfully compiled linux 2.6.25.x kerne?l with cris toolchain? Mine fails with:
 CC [M]  drivers/video/fbcmap.o
  CC [M]  drivers/video/fbsysfs.o
  CC [M]  drivers/video/modedb.o
  CC [M]  drivers/video/fbcvt.o
  LD [M]  drivers/video/fb.o
  CC [M]  drivers/video/cfbfillrect.o
  CC [M]  drivers/video/cfbcopyarea.o
  CC [M]  drivers/video/cfbimgblt.o
  LD      drivers/built-in.o
  LD      sound/built-in.o
  LD      arch/cris/arch-v10/drivers/built-in.o
  CC      net/socket.o
  LD      net/802/built-in.o
  CC      net/core/sock.o
  CC      net/core/request_sock.o
  CC      net/core/skbuff.o
  CC      net/core/iovec.o
  CC      net/core/datagram.o
  CC      net/core/stream.o
(const_int -13 [0xfffffff3])
net/core/stream.c: In function 'sk_stream_wait_connect':
net/core/stream.c:78: internal compiler error: output_operand: invalid operand for 'p' modifier
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
{standard input}: Assembler messages:
{standard input}:488: Warning: partial line at end of file ignored
make[2]: *** [net/core/stream.o] Error 1
make[1]: *** [net/core] Error 2
make: *** [net] Error 2


-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si

[Buildroot] GIT or SVN

[Peter Korsgaard]

>>>>> "Hinko" == Hinko Kocevar <hinko.kocevar@cetrtapot.si> writes:

Hi,

 Hinko> I've been looking for recent gcc for the cris arch as I was
 Hinko> seeing gcc internal errors when compiling kernel or openssl
 Hinko> source with gcc 4.2.3 or 4.2.4.  With gcc 4.3.1 gcc internal
 Hinko> errors went away, so I'm really glad I found the GIT tree!

Notice that 4.3.1 also has issues (on i686 atleast):

http://kerneltrap.org/Linux/Compiler_Oops

-- 
Bye, Peter Korsgaard

[Buildroot] GIT or SVN

[Bernhard Fischer]

On Fri, Jun 20, 2008 at 03:15:55PM +0200, Hinko Kocevar wrote:
>Bernhard Fischer wrote:
>> On Fri, Jun 20, 2008 at 10:40:22AM +0200, Hinko Kocevar wrote:
>> 
>>> With gcc 4.3.1 gcc internal errors went away, so I'm really glad I found the GIT tree!
>> 
>> I have improved (i hope) the cris support, configuration-wise, please
>> pull and let me know if it suits your needs.
>> 
>
>Nice. I'm trying it out right now..
>
>BTW:
>Have you successfully compiled linux 2.6.25.x kerne?l with cris toolchain? Mine fails with:

No, just uClibc trunk, i don't have the time nor cycles for this.

>(const_int -13 [0xfffffff3])
>net/core/stream.c: In function 'sk_stream_wait_connect':
>net/core/stream.c:78: internal compiler error: output_operand: invalid operand for 'p' modifier
>Please submit a full bug report,
>with preprocessed source if appropriate.
>See <http://gcc.gnu.org/bugs.html> for instructions.

Well, you should do that and/or try gcc-trunk or another kernel, i suppose :)

[Buildroot] GIT or SVN

[Hinko Kocevar]

Bernhard Fischer wrote:
> On Fri, Jun 20, 2008 at 10:40:22AM +0200, Hinko Kocevar wrote:
> 
>> With gcc 4.3.1 gcc internal errors went away, so I'm really glad I found the GIT tree!
> 
> I have improved (i hope) the cris support, configuration-wise, please
> pull and let me know if it suits your needs.
> 

1. Compilation of uClibc always fails with:

make[1]: Entering directory `/work/stage/git.br/toolchain_build_cris/uClibc-0.9.29'
make[2]: `conf' is up to date.
/usr/bin/make locale_headers
make[3]: `conf' is up to date.
  CC ldso/ldso/ldso.oS
  AS ldso/ldso/cris/resolve.oS
  CC ldso/libdl/libdl.oS
  CC libcrypt/crypt.os
  CC libcrypt/des.os
In file included from ./include/sys/param.h:22,
                 from libcrypt/des.c:62:
./include/limits.h:124:26: error: limits.h: No such file or directory
make[1]: *** [libcrypt/des.os] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory `/work/stage/git.br/toolchain_build_cris/uClibc-0.9.29'
make: *** [/home/hinkok/work/stage/git.br/toolchain_build_cris/uClibc-0.9.29/lib/libc.a] Error 2

2. And later:

  CC libm/expf.os
  AS libc/sysdeps/linux/cris/syscall.os
  CC libm/expm1f.os
  CC libc/sysdeps/linux/common/__rt_sigtimedwait.os
  CC libm/fabsf.os
In file included from /home/hinkok/work/stage/git.br/toolchain_build_cris/linux/include/asm/sigcontext.h:6,
                 from ./include/bits/sigcontext.h:28,
                 from ./include/signal.h:332,
                 from libc/sysdeps/linux/common/__rt_sigtimedwait.c:11:
/home/hinkok/work/stage/git.br/toolchain_build_cris/linux/include/asm/ptrace.h:4:29: error: asm/arch/ptrace.h: No such file or directory
In file included from ./include/bits/sigcontext.h:28,
                 from ./include/signal.h:332,
                 from libc/sysdeps/linux/common/__rt_sigtimedwait.c:11:
/home/hinkok/work/stage/git.br/toolchain_build_cris/linux/include/asm/sigcontext.h:18: error: field 'regs' has incomplete type
make[2]: *** [libc/sysdeps/linux/common/__rt_sigtimedwait.os] Error 1
make[2]: *** Waiting for unfinished jobs....
  CC libm/fdimf.os


-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si

-------------- next part --------------
A non-text attachment was scrubbed...
Name: buildroot-cris-uClibc.patch
Type: text/x-patch
Size: 845 bytes
Desc: not available
Url : http://busybox.net/lists/buildroot/attachments/20080620/d039e488/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: buildroot-cris-headers.patch
Type: text/x-patch
Size: 967 bytes
Desc: not available
Url : http://busybox.net/lists/buildroot/attachments/20080620/d039e488/attachment-0001.bin 

[Buildroot] cris

[Bernhard Fischer]

[I'm changing the subject to something more suitable]
On Fri, Jun 20, 2008 at 03:26:16PM +0200, Hinko Kocevar wrote:
>Bernhard Fischer wrote:
>> On Fri, Jun 20, 2008 at 10:40:22AM +0200, Hinko Kocevar wrote:
>> 
>>> With gcc 4.3.1 gcc internal errors went away, so I'm really glad I found the GIT tree!
>> 
>> I have improved (i hope) the cris support, configuration-wise, please
>> pull and let me know if it suits your needs.
>> 
>
>1. Compilation of uClibc always fails with:
>
>make[1]: Entering directory `/work/stage/git.br/toolchain_build_cris/uClibc-0.9.29'
>make[2]: `conf' is up to date.
>/usr/bin/make locale_headers
>make[3]: `conf' is up to date.
>  CC ldso/ldso/ldso.oS
>  AS ldso/ldso/cris/resolve.oS
>  CC ldso/libdl/libdl.oS
>  CC libcrypt/crypt.os
>  CC libcrypt/des.os
>In file included from ./include/sys/param.h:22,
>                 from libcrypt/des.c:62:
>./include/limits.h:124:26: error: limits.h: No such file or directory
>make[1]: *** [libcrypt/des.os] Error 1
>make[1]: *** Waiting for unfinished jobs....
>make[1]: Leaving directory `/work/stage/git.br/toolchain_build_cris/uClibc-0.9.29'
>make: *** [/home/hinkok/work/stage/git.br/toolchain_build_cris/uClibc-0.9.29/lib/libc.a] Error 2

I don't see this. Is that uClibc-trunk or something else?
>
>2. And later:
>
>  CC libm/expf.os
>  AS libc/sysdeps/linux/cris/syscall.os
>  CC libm/expm1f.os
>  CC libc/sysdeps/linux/common/__rt_sigtimedwait.os
>  CC libm/fabsf.os
>In file included from /home/hinkok/work/stage/git.br/toolchain_build_cris/linux/include/asm/sigcontext.h:6,
>                 from ./include/bits/sigcontext.h:28,
>                 from ./include/signal.h:332,
>                 from libc/sysdeps/linux/common/__rt_sigtimedwait.c:11:
>/home/hinkok/work/stage/git.br/toolchain_build_cris/linux/include/asm/ptrace.h:4:29: error: asm/arch/ptrace.h: No such file or directory

yes, i saw that too. Kernel bug.
>diff --git a/toolchain/gcc/gcc-uclibc-4.x.mk b/toolchain/gcc/gcc-uclibc-4.x.mk
>index e1b16a8..b4001d9 100644
>--- a/toolchain/gcc/gcc-uclibc-4.x.mk
>+++ b/toolchain/gcc/gcc-uclibc-4.x.mk
>@@ -234,6 +234,10 @@ $(gcc_initial) $(STAGING_DIR)/usr/bin/$(REAL_GNU_TARGET_NAME)-gcc: $(GCC_BUILD_D
> 	# gcc >= 4.3.0 have to also install install-target-libgcc
> ifeq ($(BR2_GCC_SUPPORTS_FINEGRAINEDMTUNE),y)
> 	PATH=$(TARGET_PATH) $(MAKE) -C $(GCC_BUILD_DIR1) install-gcc install-target-libgcc
>+	# This is a must for cris arch at least, or uClibc fails with missing 
>+	# limits.h header!
>+	ln -snf $(STAGING_DIR)/usr/lib/gcc/$(REAL_GNU_TARGET_NAME)/$(GCC_OFFICIAL_VER)/include-fixed/limits.h \
>+	$(STAGING_DIR)/usr/lib/gcc/$(REAL_GNU_TARGET_NAME)/$(GCC_OFFICIAL_VER)/include/limits.h

i don't think that this is correct, there must me something different
going on.
> else
> 	PATH=$(TARGET_PATH) $(MAKE) -C $(GCC_BUILD_DIR1) install-gcc
> endif

>diff --git a/toolchain/kernel-headers/kernel-headers-new.makefile b/toolchain/kernel-headers/kernel-headers-new.makefile
>index 0fca24d..b04d691 100644
>--- a/toolchain/kernel-headers/kernel-headers-new.makefile
>+++ b/toolchain/kernel-headers/kernel-headers-new.makefile
>@@ -74,6 +74,13 @@ $(LINUX_HEADERS_DIR)/.configured: $(LINUX_HEADERS_UNPACK_DIR)/.patched
> 		HOSTCXX="$(HOSTCXX)" \
> 		INSTALL_HDR_PATH=$(LINUX_HEADERS_DIR) headers_install; \
> 	)
>+ifeq ($(BR2_ARCH),"cris")
>+	 cp -a $(LINUX_HEADERS_UNPACK_DIR)/include/linux/user.h $(LINUX_HEADERS_DIR)/include/linux
>+	 cp -a $(LINUX_HEADERS_UNPACK_DIR)/include/asm-cris/user.h $(LINUX_HEADERS_DIR)/include/asm
>+	 cp -a $(LINUX_HEADERS_UNPACK_DIR)/include/asm-cris/elf.h $(LINUX_HEADERS_DIR)/include/asm
>+	 cp -a $(LINUX_HEADERS_UNPACK_DIR)/include/asm-cris/arch-v10 $(LINUX_HEADERS_DIR)/include/asm/arch
>+	 sed -i -e "/^#include <asm\/page\.h>/d" $(LINUX_HEADERS_DIR)/include/asm/user.h

as you can see this wouldn't work for v8 and generally should be fixed
in the kernel (also fails with 2.6.git).
>+endif
> 	touch $@
> 
> endif

[Buildroot] cris

[Peter Korsgaard]

>>>>> "Bernhard" == Bernhard Fischer <rep.dot.nop@gmail.com> writes:

Hi,

 >> make[1]: Leaving directory `/work/stage/git.br/toolchain_build_cris/uClibc-0.9.29'
 >> make: *** [/home/hinkok/work/stage/git.br/toolchain_build_cris/uClibc-0.9.29/lib/libc.a] Error 2

 Bernhard> I don't see this. Is that uClibc-trunk or something else?

I see that as well with uclibc 0.9.29.

-- 
Bye, Peter Korsgaard

[Buildroot] cris

[Bernhard Fischer]

On Fri, Jun 20, 2008 at 04:30:43PM +0200, Peter Korsgaard wrote:
>>>>>> "Bernhard" == Bernhard Fischer <rep.dot.nop@gmail.com> writes:
>
>Hi,
>
> >> make[1]: Leaving directory `/work/stage/git.br/toolchain_build_cris/uClibc-0.9.29'
> >> make: *** [/home/hinkok/work/stage/git.br/toolchain_build_cris/uClibc-0.9.29/lib/libc.a] Error 2
>
> Bernhard> I don't see this. Is that uClibc-trunk or something else?
>
>I see that as well with uclibc 0.9.29.

Re the ptrace.h thing, it's a configuration problem on our side, but
it's not pretty to fix. Let's see, i think i have an idea how to do that
cleanly..

[Buildroot] cris

[Hinko Kocevar]

Bernhard Fischer wrote:
> [I'm changing the subject to something more suitable]
> On Fri, Jun 20, 2008 at 03:26:16PM +0200, Hinko Kocevar wrote:
>> Bernhard Fischer wrote:
>>> On Fri, Jun 20, 2008 at 10:40:22AM +0200, Hinko Kocevar wrote:
>>>
>>>> With gcc 4.3.1 gcc internal errors went away, so I'm really glad I found the GIT tree!
>>> I have improved (i hope) the cris support, configuration-wise, please
>>> pull and let me know if it suits your needs.
>>>
>> 1. Compilation of uClibc always fails with:
>>
>> make[1]: Entering directory `/work/stage/git.br/toolchain_build_cris/uClibc-0.9.29'
>> make[2]: `conf' is up to date.
>> /usr/bin/make locale_headers
>> make[3]: `conf' is up to date.
>>  CC ldso/ldso/ldso.oS
>>  AS ldso/ldso/cris/resolve.oS
>>  CC ldso/libdl/libdl.oS
>>  CC libcrypt/crypt.os
>>  CC libcrypt/des.os
>> In file included from ./include/sys/param.h:22,
>>                 from libcrypt/des.c:62:
>> ./include/limits.h:124:26: error: limits.h: No such file or directory
>> make[1]: *** [libcrypt/des.os] Error 1
>> make[1]: *** Waiting for unfinished jobs....
>> make[1]: Leaving directory `/work/stage/git.br/toolchain_build_cris/uClibc-0.9.29'
>> make: *** [/home/hinkok/work/stage/git.br/toolchain_build_cris/uClibc-0.9.29/lib/libc.a] Error 2
> 
> I don't see this. Is that uClibc-trunk or something else?

Sorry for not pointing that out earlier  - it's with uClibc 0.9.29. IMHO it might have something to do with sysroot prefix, as I played with toochain settings before.. Also I think it didn't happen when using gcc 4.2.4 ...

>> 2. And later:
>>
>>  CC libm/expf.os
>>  AS libc/sysdeps/linux/cris/syscall.os
>>  CC libm/expm1f.os
>>  CC libc/sysdeps/linux/common/__rt_sigtimedwait.os
>>  CC libm/fabsf.os
>> In file included from /home/hinkok/work/stage/git.br/toolchain_build_cris/linux/include/asm/sigcontext.h:6,
>>                 from ./include/bits/sigcontext.h:28,
>>                 from ./include/signal.h:332,
>>                 from libc/sysdeps/linux/common/__rt_sigtimedwait.c:11:
>> /home/hinkok/work/stage/git.br/toolchain_build_cris/linux/include/asm/ptrace.h:4:29: error: asm/arch/ptrace.h: No such file or directory
> 
> yes, i saw that too. Kernel bug.
>> diff --git a/toolchain/gcc/gcc-uclibc-4.x.mk b/toolchain/gcc/gcc-uclibc-4.x.mk
>> index e1b16a8..b4001d9 100644
>> --- a/toolchain/gcc/gcc-uclibc-4.x.mk
>> +++ b/toolchain/gcc/gcc-uclibc-4.x.mk
>> @@ -234,6 +234,10 @@ $(gcc_initial) $(STAGING_DIR)/usr/bin/$(REAL_GNU_TARGET_NAME)-gcc: $(GCC_BUILD_D
>> 	# gcc >= 4.3.0 have to also install install-target-libgcc
>> ifeq ($(BR2_GCC_SUPPORTS_FINEGRAINEDMTUNE),y)
>> 	PATH=$(TARGET_PATH) $(MAKE) -C $(GCC_BUILD_DIR1) install-gcc install-target-libgcc
>> +	# This is a must for cris arch at least, or uClibc fails with missing 
>> +	# limits.h header!
>> +	ln -snf $(STAGING_DIR)/usr/lib/gcc/$(REAL_GNU_TARGET_NAME)/$(GCC_OFFICIAL_VER)/include-fixed/limits.h \
>> +	$(STAGING_DIR)/usr/lib/gcc/$(REAL_GNU_TARGET_NAME)/$(GCC_OFFICIAL_VER)/include/limits.h
> 
> i don't think that this is correct, there must me something different
> going on.

Me too, will rebuild with and wo sysroot as I suspect to meka a difference..

>> else
>> 	PATH=$(TARGET_PATH) $(MAKE) -C $(GCC_BUILD_DIR1) install-gcc
>> endif
> 
>> diff --git a/toolchain/kernel-headers/kernel-headers-new.makefile b/toolchain/kernel-headers/kernel-headers-new.makefile
>> index 0fca24d..b04d691 100644
>> --- a/toolchain/kernel-headers/kernel-headers-new.makefile
>> +++ b/toolchain/kernel-headers/kernel-headers-new.makefile
>> @@ -74,6 +74,13 @@ $(LINUX_HEADERS_DIR)/.configured: $(LINUX_HEADERS_UNPACK_DIR)/.patched
>> 		HOSTCXX="$(HOSTCXX)" \
>> 		INSTALL_HDR_PATH=$(LINUX_HEADERS_DIR) headers_install; \
>> 	)
>> +ifeq ($(BR2_ARCH),"cris")
>> +	 cp -a $(LINUX_HEADERS_UNPACK_DIR)/include/linux/user.h $(LINUX_HEADERS_DIR)/include/linux
>> +	 cp -a $(LINUX_HEADERS_UNPACK_DIR)/include/asm-cris/user.h $(LINUX_HEADERS_DIR)/include/asm
>> +	 cp -a $(LINUX_HEADERS_UNPACK_DIR)/include/asm-cris/elf.h $(LINUX_HEADERS_DIR)/include/asm
>> +	 cp -a $(LINUX_HEADERS_UNPACK_DIR)/include/asm-cris/arch-v10 $(LINUX_HEADERS_DIR)/include/asm/arch
>> +	 sed -i -e "/^#include <asm\/page\.h>/d" $(LINUX_HEADERS_DIR)/include/asm/user.h
> 
> as you can see this wouldn't work for v8 and generally should be fixed
> in the kernel (also fails with 2.6.git).

This problem is because include/asm-cris/Kbuild does not include the correct headers when the kernel source is not configured. Both include/asm-cris/arch-vXX directories are left behind when install_headers goes through header-y target. 

I'll let Axis people sort it out (if ever), till then I guess we are stuck with the hack..

regards,
Hinko

-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si

[Buildroot] cris

[Hinko Kocevar]

Hinko Kocevar wrote:
> Bernhard Fischer wrote:
>> [I'm changing the subject to something more suitable]
>> On Fri, Jun 20, 2008 at 03:26:16PM +0200, Hinko Kocevar wrote:
>>> Bernhard Fischer wrote:
>>>> On Fri, Jun 20, 2008 at 10:40:22AM +0200, Hinko Kocevar wrote:
>>>>
>>>>> With gcc 4.3.1 gcc internal errors went away, so I'm really glad I found the GIT tree!
>>>> I have improved (i hope) the cris support, configuration-wise, please
>>>> pull and let me know if it suits your needs.
>>>>
>>> 1. Compilation of uClibc always fails with:
>>>
>>> make[1]: Entering directory `/work/stage/git.br/toolchain_build_cris/uClibc-0.9.29'
>>> make[2]: `conf' is up to date.
>>> /usr/bin/make locale_headers
>>> make[3]: `conf' is up to date.
>>>  CC ldso/ldso/ldso.oS
>>>  AS ldso/ldso/cris/resolve.oS
>>>  CC ldso/libdl/libdl.oS
>>>  CC libcrypt/crypt.os
>>>  CC libcrypt/des.os
>>> In file included from ./include/sys/param.h:22,
>>>                 from libcrypt/des.c:62:
>>> ./include/limits.h:124:26: error: limits.h: No such file or directory
>>> make[1]: *** [libcrypt/des.os] Error 1
>>> make[1]: *** Waiting for unfinished jobs....
>>> make[1]: Leaving directory `/work/stage/git.br/toolchain_build_cris/uClibc-0.9.29'
>>> make: *** [/home/hinkok/work/stage/git.br/toolchain_build_cris/uClibc-0.9.29/lib/libc.a] Error 2
>> I don't see this. Is that uClibc-trunk or something else?
> 
> Me too, will rebuild with and wo sysroot as I suspect to meka a difference..

No difference. In other words, I can't install binutils 2.18 wo using sysroot.
But using gcc 4.2.3 instead of 4.3.1 does not generate the error!

-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si

[Buildroot] GIT or SVN

[Hinko Kocevar]

Bernhard Fischer wrote:

>> (const_int -13 [0xfffffff3])
>> net/core/stream.c: In function 'sk_stream_wait_connect':
>> net/core/stream.c:78: internal compiler error: output_operand: invalid operand for 'p' modifier
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See <http://gcc.gnu.org/bugs.html> for instructions.
> 
> Well, you should do that and/or try gcc-trunk or another kernel, i suppose :)

I've filled a bug report in gcc bugzilla for this.
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36482.

-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si

[Buildroot] cris

[Bernhard Fischer]

On Mon, Jun 23, 2008 at 09:27:57AM +0200, Hinko Kocevar wrote:
>Bernhard Fischer wrote:

>>> +ifeq ($(BR2_ARCH),"cris")
>>> +	 cp -a $(LINUX_HEADERS_UNPACK_DIR)/include/linux/user.h $(LINUX_HEADERS_DIR)/include/linux
>>> +	 cp -a $(LINUX_HEADERS_UNPACK_DIR)/include/asm-cris/user.h $(LINUX_HEADERS_DIR)/include/asm
>>> +	 cp -a $(LINUX_HEADERS_UNPACK_DIR)/include/asm-cris/elf.h $(LINUX_HEADERS_DIR)/include/asm
>>> +	 cp -a $(LINUX_HEADERS_UNPACK_DIR)/include/asm-cris/arch-v10 $(LINUX_HEADERS_DIR)/include/asm/arch
>>> +	 sed -i -e "/^#include <asm\/page\.h>/d" $(LINUX_HEADERS_DIR)/include/asm/user.h
>> 
>> as you can see this wouldn't work for v8 and generally should be fixed
>> in the kernel (also fails with 2.6.git).
>
>This problem is because include/asm-cris/Kbuild does not include the correct headers when the kernel source is not configured. Both include/asm-cris/arch-vXX directories are left behind when install_headers goes through header-y target. 
>
>I'll let Axis people sort it out (if ever), till then I guess we are stuck with the hack..

Yes, we'd need to use a prepared kernel ("archprepare"), which means
dropping the one from tool_build and setting one up early in project_.

I currently don't have time to do this properly, perhaps you want to
give it a try?

[Buildroot] cris

[Bernhard Fischer]

On Mon, Jun 23, 2008 at 10:50:32AM +0200, Hinko Kocevar wrote:
>Hinko Kocevar wrote:
>> Bernhard Fischer wrote:
>>> [I'm changing the subject to something more suitable]

>>> I don't see this. Is that uClibc-trunk or something else?
>> 
>> Me too, will rebuild with and wo sysroot as I suspect to meka a difference..
>
>No difference. In other words, I can't install binutils 2.18 wo using sysroot.

Ah right, i don't do non-sysroot (there is simply no point in it)
anymore. It's better to just have a properly relocatable cross-compiler
anyway.

>But using gcc 4.2.3 instead of 4.3.1 does not generate the error!

You would have to look if these old gcc versions are treated separately
and adjust the new accordingly (in gcc-uclibc-3.x.mk, i.e. the
non-sysroot makefile; but you really don't want these).

HTH,

[Buildroot] cris

[Hinko Kocevar]

Bernhard Fischer wrote:
> On Mon, Jun 23, 2008 at 09:27:57AM +0200, Hinko Kocevar wrote:
>> Bernhard Fischer wrote:
> 
>>>> +ifeq ($(BR2_ARCH),"cris")
>>>> +	 cp -a $(LINUX_HEADERS_UNPACK_DIR)/include/linux/user.h $(LINUX_HEADERS_DIR)/include/linux
>>>> +	 cp -a $(LINUX_HEADERS_UNPACK_DIR)/include/asm-cris/user.h $(LINUX_HEADERS_DIR)/include/asm
>>>> +	 cp -a $(LINUX_HEADERS_UNPACK_DIR)/include/asm-cris/elf.h $(LINUX_HEADERS_DIR)/include/asm
>>>> +	 cp -a $(LINUX_HEADERS_UNPACK_DIR)/include/asm-cris/arch-v10 $(LINUX_HEADERS_DIR)/include/asm/arch
>>>> +	 sed -i -e "/^#include <asm\/page\.h>/d" $(LINUX_HEADERS_DIR)/include/asm/user.h
>>> as you can see this wouldn't work for v8 and generally should be fixed
>>> in the kernel (also fails with 2.6.git).
>> This problem is because include/asm-cris/Kbuild does not include the correct headers when the kernel source is not configured. Both include/asm-cris/arch-vXX directories are left behind when install_headers goes through header-y target. 
>>
>> I'll let Axis people sort it out (if ever), till then I guess we are stuck with the hack..
> 
> Yes, we'd need to use a prepared kernel ("archprepare"), which means
> dropping the one from tool_build and setting one up early in project_.
> 
> I currently don't have time to do this properly, perhaps you want to
> give it a try?

The axis devs responded with the solution that does not rely on the CONFIG_ETRAX_ARCH_Vxx but instead includes arch-v10 and arch-v32 dirs in header-y target. I guess it is OK to do so, since we might need headers for v10 and/or v32 CPUs. The only catch would be to make correct symlink to the desired arch-vxx directory.


diff --git a/include/asm-cris/Kbuild b/include/asm-cris/Kbuild
index 1745545..d5b6319 100644
--- a/include/asm-cris/Kbuild
+++ b/include/asm-cris/Kbuild
@@ -1,7 +1,7 @@
 include include/asm-generic/Kbuild.asm
 
-header-$(CONFIG_ETRAX_ARCH_V10) += arch-v10/
-header-$(CONFIG_ETRAX_ARCH_V32) += arch-v32/
+header-y += arch-v10/
+header-y += arch-v32/
 
 header-y += ethernet.h
 header-y += rtc.h


I think it is the correct path to take, but will still try to work out the best solution with the Axis devs later on..

Regards,
Hinko

-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si

[Buildroot] cris

[Bernhard Fischer]

On Mon, Jun 23, 2008 at 04:41:32PM +0200, Hinko Kocevar wrote:
>Bernhard Fischer wrote:
>> On Mon, Jun 23, 2008 at 09:27:57AM +0200, Hinko Kocevar wrote:
>>> Bernhard Fischer wrote:
>> 
>>>>> +ifeq ($(BR2_ARCH),"cris")
>>>>> +	 cp -a $(LINUX_HEADERS_UNPACK_DIR)/include/linux/user.h $(LINUX_HEADERS_DIR)/include/linux
>>>>> +	 cp -a $(LINUX_HEADERS_UNPACK_DIR)/include/asm-cris/user.h $(LINUX_HEADERS_DIR)/include/asm
>>>>> +	 cp -a $(LINUX_HEADERS_UNPACK_DIR)/include/asm-cris/elf.h $(LINUX_HEADERS_DIR)/include/asm
>>>>> +	 cp -a $(LINUX_HEADERS_UNPACK_DIR)/include/asm-cris/arch-v10 $(LINUX_HEADERS_DIR)/include/asm/arch
>>>>> +	 sed -i -e "/^#include <asm\/page\.h>/d" $(LINUX_HEADERS_DIR)/include/asm/user.h
>>>> as you can see this wouldn't work for v8 and generally should be fixed
>>>> in the kernel (also fails with 2.6.git).
>>> This problem is because include/asm-cris/Kbuild does not include the correct headers when the kernel source is not configured. Both include/asm-cris/arch-vXX directories are left behind when install_headers goes through header-y target. 
>>>
>>> I'll let Axis people sort it out (if ever), till then I guess we are stuck with the hack..
>> 
>> Yes, we'd need to use a prepared kernel ("archprepare"), which means
>> dropping the one from tool_build and setting one up early in project_.
>> 
>> I currently don't have time to do this properly, perhaps you want to
>> give it a try?
>
>The axis devs responded with the solution that does not rely on the CONFIG_ETRAX_ARCH_Vxx but instead includes arch-v10 and arch-v32 dirs in header-y target. I guess it is OK to do so, since we might need headers for v10 and/or v32 CPUs. The only catch would be to make correct symlink to the desired arch-vxx directory.
>
>
>diff --git a/include/asm-cris/Kbuild b/include/asm-cris/Kbuild
>index 1745545..d5b6319 100644
>--- a/include/asm-cris/Kbuild
>+++ b/include/asm-cris/Kbuild
>@@ -1,7 +1,7 @@
> include include/asm-generic/Kbuild.asm
> 
>-header-$(CONFIG_ETRAX_ARCH_V10) += arch-v10/
>-header-$(CONFIG_ETRAX_ARCH_V32) += arch-v32/
>+header-y += arch-v10/
>+header-y += arch-v32/

yes, i've done that too, but it is incomplete, see below.
> 
> header-y += ethernet.h
> header-y += rtc.h
>
>
>I think it is the correct path to take, but will still try to work out the best solution with the Axis devs later on..

If cris does that then the other archprepare arches still need handling,
so this is not a complete fix but purely cris-specific.
>
>Regards,
>Hinko
>
>-- 
>?ETRTA POT, d.o.o., Kranj
>Planina 3
>4000 Kranj
>Slovenia, Europe
>Tel. +386 (0) 4 280 66 03
>E-mail: hinko.kocevar at cetrtapot.si
>Http: www.cetrtapot.si
>

[Buildroot] cris

[Hinko Kocevar]

Bernhard Fischer wrote:
> On Mon, Jun 23, 2008 at 10:50:32AM +0200, Hinko Kocevar wrote:
>> Hinko Kocevar wrote:
>>> Bernhard Fischer wrote:
>>>> [I'm changing the subject to something more suitable]
> 
>>>> I don't see this. Is that uClibc-trunk or something else?
>>> Me too, will rebuild with and wo sysroot as I suspect to meka a difference..
>> No difference. In other words, I can't install binutils 2.18 wo using sysroot.
> 
> Ah right, i don't do non-sysroot (there is simply no point in it)
> anymore. It's better to just have a properly relocatable cross-compiler
> anyway.
> 
>> But using gcc 4.2.3 instead of 4.3.1 does not generate the error!
> 
> You would have to look if these old gcc versions are treated separately
> and adjust the new accordingly (in gcc-uclibc-3.x.mk, i.e. the
> non-sysroot makefile; but you really don't want these).
> 

I've misread the sysroot comment in the buildroot (I thought it was optionally to use it), but without it the buildroot tries to put resulting cross compiled binutils into /usr, which is not what I want.

Maybe finding the 'latest' known working compiler for cris would be the starting point and the move on to the newer versions. Axis has originally ported cris architecture to gcc 3.2.1 and I'm not aware if they are even trying to keep up with the gcc/glibc/uClibc/binutils mainstream changes in order to provide latest tools..

Thanks.

-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si

[Buildroot] cris

[Hinko Kocevar]

Bernhard Fischer wrote:
> On Mon, Jun 23, 2008 at 04:41:32PM +0200, Hinko Kocevar wrote:
>> Bernhard Fischer wrote:
>>> On Mon, Jun 23, 2008 at 09:27:57AM +0200, Hinko Kocevar wrote:
>>>> Bernhard Fischer wrote:
>>>>>> +ifeq ($(BR2_ARCH),"cris")
>>>>>> +	 cp -a $(LINUX_HEADERS_UNPACK_DIR)/include/linux/user.h $(LINUX_HEADERS_DIR)/include/linux
>>>>>> +	 cp -a $(LINUX_HEADERS_UNPACK_DIR)/include/asm-cris/user.h $(LINUX_HEADERS_DIR)/include/asm
>>>>>> +	 cp -a $(LINUX_HEADERS_UNPACK_DIR)/include/asm-cris/elf.h $(LINUX_HEADERS_DIR)/include/asm
>>>>>> +	 cp -a $(LINUX_HEADERS_UNPACK_DIR)/include/asm-cris/arch-v10 $(LINUX_HEADERS_DIR)/include/asm/arch
>>>>>> +	 sed -i -e "/^#include <asm\/page\.h>/d" $(LINUX_HEADERS_DIR)/include/asm/user.h
>>>>> as you can see this wouldn't work for v8 and generally should be fixed
>>>>> in the kernel (also fails with 2.6.git).
>>>> This problem is because include/asm-cris/Kbuild does not include the correct headers when the kernel source is not configured. Both include/asm-cris/arch-vXX directories are left behind when install_headers goes through header-y target. 
>>>>
>>>> I'll let Axis people sort it out (if ever), till then I guess we are stuck with the hack..
>>> Yes, we'd need to use a prepared kernel ("archprepare"), which means
>>> dropping the one from tool_build and setting one up early in project_.
>>>
>>> I currently don't have time to do this properly, perhaps you want to
>>> give it a try?
>> The axis devs responded with the solution that does not rely on the CONFIG_ETRAX_ARCH_Vxx but instead includes arch-v10 and arch-v32 dirs in header-y target. I guess it is OK to do so, since we might need headers for v10 and/or v32 CPUs. The only catch would be to make correct symlink to the desired arch-vxx directory.
>>
>>
>> diff --git a/include/asm-cris/Kbuild b/include/asm-cris/Kbuild
>> index 1745545..d5b6319 100644
>> --- a/include/asm-cris/Kbuild
>> +++ b/include/asm-cris/Kbuild
>> @@ -1,7 +1,7 @@
>> include include/asm-generic/Kbuild.asm
>>
>> -header-$(CONFIG_ETRAX_ARCH_V10) += arch-v10/
>> -header-$(CONFIG_ETRAX_ARCH_V32) += arch-v32/
>> +header-y += arch-v10/
>> +header-y += arch-v32/
> 
> yes, i've done that too, but it is incomplete, see below.
>> header-y += ethernet.h
>> header-y += rtc.h
>>
>>
>> I think it is the correct path to take, but will still try to work out the best solution with the Axis devs later on..
> 
> If cris does that then the other archprepare arches still need handling,
> so this is not a complete fix but purely cris-specific.

It is cris specific, I was not aware of the problem existing on other architectures.

I think that other arches are not affected as long as the whole need for headers goes (haven't really tried out). It is kernel bug in cris port that can't handle the headers for arch-v10 and arch-v32 correctly. So once the Axis has complete solution in order to pull all required headers from the source tree this problems will vanish.

-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si

[Buildroot] cris

[Bernhard Fischer]

On Mon, Jun 23, 2008 at 04:54:09PM +0200, Hinko Kocevar wrote:
>Bernhard Fischer wrote:
>> On Mon, Jun 23, 2008 at 04:41:32PM +0200, Hinko Kocevar wrote:

>>> I think it is the correct path to take, but will still try to work out the best solution with the Axis devs later on..
>> 
>> If cris does that then the other archprepare arches still need handling,
>> so this is not a complete fix but purely cris-specific.
>
>It is cris specific, I was not aware of the problem existing on other architectures.
>
>I think that other arches are not affected as long as the whole need for headers goes (haven't really tried out). It is kernel bug in cris port that can't handle the headers for arch-v10 and arch-v32 correctly. So once the Axis has complete solution in order to pull all required headers from the source tree this problems will vanish.

Maybe there was an additional glitch with cris, but the fundamental
shortcoming remains and needs to be fixed/improved in a general way.

Note that this particular cris glitch (missing sub-arch specific
headers) would not have been really visible if the above would be done
properly.

[Buildroot] cris

[Ralph Siemsen]

On Mon, Jun 23, 2008 at 04:54:09PM +0200, Hinko Kocevar wrote:
> 
> I think that other arches are not affected as long as the whole need for headers goes (haven't really tried out). It is kernel bug in cris port that can't handle the headers for arch-v10 and arch-v32 correctly. So once the Axis has complete solution in order to pull all required headers from the source tree this problems will vanish.

I'm compiling from GIT targeting ARM and ran into some of the same
problems as discussed in this thread.  Specifically:
 - missing limits.h
 - changing "extern" to "static" in libpthread
I was able to make things work by adapting patches posted here (Thanks!).
eg. patch sysdeps/arm/pt-machine.h instead of cris version

I ran into an additional issue when I enabled soft-float toolchain,
there was a problem linking mpfr, somehow /usr/lib/libgmp.so from my
i386 host machine is pulled instead of the ARM target version.  I
don't have a clean solution for this one, but I was able to manually
link mpfr against the correct libgmp.so

-Ralph

[Buildroot] GIT or SVN

[Hinko Kocevar]

Peter Korsgaard wrote:
>>>>>> "Hinko" == Hinko Kocevar <hinko.kocevar@cetrtapot.si> writes:
> 
> Hi,
> 
>  Hinko> I've been looking for recent gcc for the cris arch as I was
>  Hinko> seeing gcc internal errors when compiling kernel or openssl
>  Hinko> source with gcc 4.2.3 or 4.2.4.  With gcc 4.3.1 gcc internal
>  Hinko> errors went away, so I'm really glad I found the GIT tree!
> 
> Notice that 4.3.1 also has issues (on i686 atleast):
> 
> http://kerneltrap.org/Linux/Compiler_Oops
> 

To somehow close the thread about the 4.3.1 gcc and cris architecture. There
are some nice people at Axis that made some effort in order to fix the
internal compiler error (Thank you!!). The bug report exists in bugzilla 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35492.

The bug report has a patch that was tested by me and it passed the 
build of kernel and openssl that used to fail with internal compiler error
 - I haven't noticed problems with other packages yet.

Patch is at http://gcc.gnu.org/bugzilla/attachment.cgi?id=15874&action=view

Could you please pull the patch for gcc 4.3.1 into the buildroot?

Thank you,
Hinko

-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si