Nabble - Sourceware - crossgcc list

Re: [PATCH 0 of 1] CVS retrieval of GLIBC cannot work for 2.10.1

2009-12-02T01:12:19Z

Hello!

ng@... wrote:
> could you confirm that previous installations fo ct-ng will still function?

If you based tour work on a release tarball, then this release tarball
will still be available, and will not be impacted. So you'll be able to
reproduce your toolchains.

If you based your work on a clone of the repository, and you did note
the 'revision' of the repository you used, then you'll be able to
reproduce your toolchains.

> Maybe I'm misinterpreting what this is about but it would be good if you
> could clarify.

I am not migrating crosstool-NG to git. I am adding support in crosstool-NG
to use GIT repositories, so it can use the glibc GIT tree instead of the
CVS repository.

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^ |
| --==< O_o >==-- '------------.-------: X AGAINST | /e\ There is no |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL | """ conspiracy. |
'------------------------------'-------'------------------'--------------------'

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

Re: [PATCH 0 of 1] CVS retrieval of GLIBC cannot work for 2.10.1

2009-12-01T23:12:57Z

Hello Frederic!
Hello All!

On Wednesday 02 December 2009 02:28:16 Frederic Roussel wrote:
> I've noticed that CVS retrieval for glibc cannot work, so I made a patch
> to disable it in glibc.in.

Don't bother hacking CVS in glibc, it's going away now that there are git
trees available. CVS is already gone in my local copy, but as git is not
yet ready, I haven't pushed the changes yet. Should be done by the end of
the week...

> That being said, the upstream project advertizes the use of "git" rather
> than "cvs".
> Is there any work going on to have "git" trees retrieved ?

Yes, it's almost ready.

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
`------------------------------^-------^------------------^--------------------'

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

[PATCH 1 of 1] config/libc/glibc.in: Fix for glibc 2.10.1 CVS branch

2009-12-01T17:28:17Z

# HG changeset patch
# User "Frederic Roussel" <fr.frasc@...>
# Date 1259717263 28800
# Node ID 43ecf1db5f57abd68f0b28227d246f6bba44e05b
# Parent 5f26745a915c8bac992aee9e0453cef9c4e868e9
config/libc/glibc.in: Fix for glibc 2.10.1 CVS branch

the CVS tree doesn't have a glibc-2_10_1-branch branch. only a glibc-2_10_1 branch exists. moreovert there is no "ports" in CVS for 2.10.1. Better to disable CVS for now rather than break.

Signed-off-by: "Frederic Roussel" <fr.frasc@...>

diff -r 5f26745a915c -r 43ecf1db5f57 config/libc/glibc.in
--- a/config/libc/glibc.in Thu Nov 26 00:22:17 2009 +0100
+++ b/config/libc/glibc.in Tue Dec 01 17:27:43 2009 -0800
@@ -110,6 +110,7 @@
config LIBC_GLIBC_CVS
bool
prompt "CVS checkout"
+ depends on ! LIBC_V_2_10_1
help
See the help for the entry "Released tarball", above.

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

[PATCH 0 of 1] CVS retrieval of GLIBC cannot work for 2.10.1

2009-12-01T17:28:16Z

Hi All,

I've noticed that CVS retrieval for glibc cannot work, so I made a patch to disable it in glibc.in.

There are several reasons for the CVS retrieval to fail:
- glibc-2_10_1-branch doesn't exist in the CVS tree. only glibc-2_10_1 is there. but the CT_GetCVS assumes that -branch will always be the suffix to use.
- there is no ports module for 2.10.1 yet

I probably don't understand all the subtelty of glibc CVS tree tags naming, but I have noticed that some trees are clearly identical acrtoss versions. For instance "glibc-2_10-branch" and "glibc-2_10_1" are identical. glibc-2_10-branch/version.h carries the version 2.10.1

That being said, the upstream project advertizes the use of "git" rather than "cvs".

Is there any work going on to have "git" trees retrieved ?

Oh, before I forget, the recurring build failure for glibc (2.10.1) that I was seeing before Thanksgiving went totally away for some mysterious reasons. That had been discussed in this list around July 23. As suggested I tried 'ct-ng distclean' but no matter of cleanup solved my problem as it did for the original reporter.
The Cross-Linux From Scratch foks were seeing the same problem. Based on their findings I introduced:
CT_LIBC_GLIBC_EXTRA_CFLAGS="-U_FORTIFY_SOURCE
Yeah, I don't like it either. But that made the problm go away.

After Thanksgiving, I tried again without the flag. Lo and behold it worked. I don't know if any the checkins from Yann might have fixed that.

I just wanted to document it in the list, in case it happens again.

Thanks

--Frederic

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

Re: crosstool-ng build failure with default arm-unknown-linux-uclibcgnueabi sample

2009-12-01T16:01:02Z

Thomas,
All,

On Wednesday 02 December 2009 00:02:07 Yann E. MORIN wrote:
> > It fails while compiling the first gcc compiler
> > with /[...]/arm-unknown-linux-uclibcgnueabi/bin/as:
> > unrecognized option '-Qy'
> Hey! Looks like it's calling the _native_ assembler, here, while yours seems
> to be calling the _cross_ assembler?!? WTF is going on here?

Well, in fact it shall really call the native assembler: it's tring to
generate an executable, genmodes, to run on the build machine.

> OK, I'll look a bit more in depth at the log file to see why it does so.

Everything I could spot looked fine to me... :-(

> I'll try to replicate the problem on my i686 netbook,

The gcc pass-1 build just finished, and genmodes was successfully built
and run.

From digging the binutils source code, -Qy should mostly be ignored for
compatibility with some (legacy) SVR4 stuff. Mostly, it seems it dealt
with comment sections. Bah...

What's your host? Mine is a Debian Lenny 5.0.3 with backports:

# as --version
GNU assembler (GNU Binutils for Debian) 2.18.0.20080103
# gcc --version
gcc (Debian 4.3.2-1.1) 4.3.2
# uname -a
Linux roazhon 2.6.31.5-roazhon #1 SMP Fri Oct 23 20:17:59 CEST 2009
x86_64 GNU/Linux

Sorry, I'm out of ideas... :-(
That's all for tonight, tomorrow is a long day.

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
`------------------------------^-------^------------------^--------------------'

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

Re: [PATCH 0 of 1] CVS retrieval of GLIBC cannot work for 2.10.1

2009-12-01T15:28:45Z

Yann E. MORIN wrote:

> Hello Frederic!
> Hello All!
>
> On Wednesday 02 December 2009 02:28:16 Frederic Roussel wrote:
>> I've noticed that CVS retrieval for glibc cannot work, so I made a patch
>> to disable it in glibc.in.
>
> Don't bother hacking CVS in glibc, it's going away now that there are git
> trees available. CVS is already gone in my local copy, but as git is not
> yet ready, I haven't pushed the changes yet. Should be done by the end of
> the week...
>
>> That being said, the upstream project advertizes the use of "git" rather
>> than "cvs".
>> Is there any work going on to have "git" trees retrieved ?
>
> Yes, it's almost ready.
>
> Regards,
> Yann E. MORIN.
>

Hi Yann,

could you confirm that previous installations fo ct-ng will still function?

I installed ct-ng just before you started moving to git and after a fair
bit of work getting to know it I built a toolchain matched to my
requirements.

Unless there are very important underlying reasons I do not intent to
disrupt a working tested development system , however I do need to
retain the possibility to recreate exactly the same thing should the
need arise (fs corruption, whatever ).

I have enough work on my plate using ct-ng, I really do not have the
time to learn git as well and start more learning curves and reinventing
the wheel in order to remain where I am now with a working system.

Maybe I'm misinterpreting what this is about but it would be good if you
could clarify.

Many thanks, Peter.

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

Re: crosstool-ng build failure with default arm-unknown-linux-uclibcgnueabi sample

2009-12-01T15:05:33Z

Thomas,
All,

On Wednesday 02 December 2009 00:02:07 Yann E. MORIN wrote:
> Hey! Looks like it's calling the _native_ assembler, here, while yours seems
> to be calling the _cross_ assembler?!? WTF is going on here?

Bah, forget it. I forgot the PATH... :-(

Yann.

--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
`------------------------------^-------^------------------^--------------------'

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

Re: crosstool-ng build failure with default arm-unknown-linux-uclibcgnueabi sample

2009-12-01T15:02:07Z

Hello Thomas!
Hello All!

On Tuesday 01 December 2009 22:34:03 Thomas Petazzoni wrote:
> I'm having a build failure with the current (mercurial) crosstool-ng
> while building the toolchain of sample arm-unknown-linux-uclibcgnueabi
> sample.
> It fails while compiling the first gcc compiler

It just worked fine for me here:

--8<--
[INFO ] Installing C library headers: done in 4.58s (at 05:26)
[INFO ] =================================================================
[INFO ] Installing static core C compiler
[EXTRA] Configuring static core C compiler
[EXTRA] Building static core C compiler
[EXTRA] Installing static core C compiler
[INFO ] Installing static core C compiler: done in 93.74s (at 07:00)
[INFO ] =================================================================
[INFO ] Installing C library
--8<--

[it bails out while trying to build ltrace, later, but that's nother issue]

> .config and build.log attached.

I extracted the failing commandline from your log file (i486.dat, in the
diff below), and compared it to the one from mine (x86_64.dat, below):

--8<--
# diff -u i486.dat x86_64.dat
--- i486.dat 2009-12-01 23:36:45.000000000 +0100
+++ x86_64.dat 2009-12-01 23:36:48.000000000 +0100
@@ -1,4 +1,4 @@
-i486-build_pc-linux-gnu-gcc
+x86_64-build_pc-linux-gnu-gcc
-c
-pipe
-DIN_GCC
@@ -20,18 +20,18 @@
-DGENERATOR_FILE
-I.
-Ibuild
--I/home/thomas/projets/crosstool-ng/targets/src/gcc-4.4.0/gcc
--I/home/thomas/projets/crosstool-ng/targets/src/gcc-4.4.0/gcc/build
--I/home/thomas/projets/crosstool-ng/targets/src/gcc-4.4.0/gcc/../include
--I/home/thomas/projets/crosstool-ng/targets/src/gcc-4.4.0/gcc/../libcpp/include
--I/usr/local/xtools/arm-unknown-linux-uclibcgnueabi/include
--I/usr/local/xtools/arm-unknown-linux-uclibcgnueabi/include
--I/home/thomas/projets/crosstool-ng/targets/src/gcc-4.4.0/gcc/../libdecnumber
--I/home/thomas/projets/crosstool-ng/targets/src/gcc-4.4.0/gcc/../libdecnumber/dpd
+-I/home/ymorin/dev/crosstool-NG/ct-ng.temp/targets/src/gcc-4.4.0/gcc
+-I/home/ymorin/dev/crosstool-NG/ct-ng.temp/targets/src/gcc-4.4.0/gcc/build
+-I/home/ymorin/dev/crosstool-NG/ct-ng.temp/targets/src/gcc-4.4.0/gcc/../include
+-I/home/ymorin/dev/crosstool-NG/ct-ng.temp/targets/src/gcc-4.4.0/gcc/../libcpp/include
+-I/home/ymorin/x-tools/arm-unknown-linux-uclibcgnueabi/include
+-I/home/ymorin/x-tools/arm-unknown-linux-uclibcgnueabi/include
+-I/home/ymorin/dev/crosstool-NG/ct-ng.temp/targets/src/gcc-4.4.0/gcc/../libdecnumber
+-I/home/ymorin/dev/crosstool-NG/ct-ng.temp/targets/src/gcc-4.4.0/gcc/../libdecnumber/dpd
-I../libdecnumber
--I/usr/local/xtools/arm-unknown-linux-uclibcgnueabi/include
--I/usr/local/xtools/arm-unknown-linux-uclibcgnueabi/include
+-I/home/ymorin/x-tools/arm-unknown-linux-uclibcgnueabi/include
+-I/home/ymorin/x-tools/arm-unknown-linux-uclibcgnueabi/include
-DCLOOG_PPL_BACKEND
-o
build/genmodes.o
-/home/thomas/projets/crosstool-ng/targets/src/gcc-4.4.0/gcc/genmodes.c
+/home/ymorin/dev/crosstool-NG/ct-ng.temp/targets/src/gcc-4.4.0/gcc/genmodes.c
--8<--

OK, so apart from the path being different, there is nothing that differs:
this is the exact same command line. Well, you're using an i486 host while
I'm using an x86_64, but that should not be an issue. Or may be it is...

> with /[...]/arm-unknown-linux-uclibcgnueabi/bin/as:
> unrecognized option '-Qy'

There's no mention of any '-Qy' option in the as man page (nor is there any
on the online manual either).

Hmm, doing the command by hand, and adding '--verbose -Wl,--verbose' gives
me (excerpt):

--8<--
[...]
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/cc1 [...] -Wno-variadic-macros
-Wno-overlength-strings -version -o - |
as -V -Qy -o build/genmodes.o -
[...]
--8<--

Hey! Looks like it's calling the _native_ assembler, here, while yours seems
to be calling the _cross_ assembler?!? WTF is going on here?

OK, I'll look a bit more in depth at the log file to see why it does so.
I'll try to replicate the problem on my i686 netbook, but that machine is
slow, so if you have a little time to investigate on your side in the
meantime...

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
`------------------------------^-------^------------------^--------------------'

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

crosstool-ng build failure with default arm-unknown-linux-uclibcgnueabi sample

2009-12-01T13:34:03Z

Hi,

I'm having a build failure with the current (mercurial) crosstool-ng
while building the toolchain of sample arm-unknown-linux-uclibcgnueabi
sample.

It fails while compiling the first gcc compiler
with /home/thomas/projets/crosstool-ng/targets/arm-unknown-linux-uclibcgnueabi/build/gcc-core-static/arm-unknown-linux-uclibcgnueabi/bin/as:
unrecognized option '-Qy'

.config and build.log attached.

Sincerly,

Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

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

.config (12K) Download Attachment
build.log.bz2 (533K) Download Attachment

Re: ng-1.5.2: "long-term stable" kernel version

2009-11-30T20:42:14Z

Dear Mr. Morin,

I tried the following kernel versions on RTD's PC104 Core2Duo:

2.6.29: I had a problem with remap_pfn_range. I used it to map phisical
memory to a user space virtual memory. This problem is mentined in osdir and
in the kernel's BugZilla.

2.6.31.1: After the extraction of the bzImage, the screen is black for a
second and then boot continues. But sometimes, boot does not continue and PC
starts from BIOS (as in cold reset). This problem is not deterministic.

As I said, I'm sure the cause is not the toolchain but linux code.

Thanks.

----- Original Message -----
From: "Yann E. MORIN" <yann.morin.1998@...>
To: <crossgcc@...>
Cc: "Zvi Vered" <veredz72@...>
Sent: Monday, November 30, 2009 10:28 PM
Subject: Re: ng-1.5.2: "long-term stable" kernel version

> Zvi,
> All,
>
> On Monday 30 November 2009 20:46:29 Zvi Vered wrote:
>> I built a toolchain for i686 using 2.6.31.1
>> Then I noticed the words "long-term stable" near 2.6.27.35
>> What does it mean ?
>> Did someone made QA tests for this version ?
>
> http://marc.info/?l=linux-kernel&m=122375909403298&w=2
>
>> I had problems with 2.6.29 and 2.6.31.1.
>> I'm sure the cause to the problems is not the toolchain but the kernel
>> code.
>
> Without the error message, the context, and other related information, we
> are
> not able to help you.
>
>
> --
> .-----------------.--------------------.------------------.--------------------.
> | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics'
> conspiracy: |
> | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___
> |
> | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is
> no |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v
> conspiracy. |
> `------------------------------^-------^------------------^--------------------'
>

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

Re: x86 cross toolchain and pthread_* weak symbols

2009-11-30T15:56:24Z

On Monday 30 November 2009 16:12:08 Lionel Landwerlin wrote:

> I'm using crosstool-ng to generate a cross toolchain for an x86 target
> (nothing too exciting...) and I'm kind of disappointed because I get
> some pthread_* weak symbols inside my toolchain :
>
> /opt/cross_x86/i686-cm-linux-gnu/lib/libdl-2.10.2.so
> w __pthread_getspecific
> w __pthread_key_create
> w __pthread_once
> w __pthread_setspecific
>
> I'm wondering why I don't have these weak symbols on my host system
> (debian unstable) which is an x86 too, and using the same toolchain
> (both using gcc-4.3.4 + eglibc-2.10/nptl, but binutils 2.19 in my cross
> toolchain, 2.20 on my host system).

maybe you're comparing apples to oranges. such weak references make sense if
you've spent time reading the code in question, and i have them on my host x86
system.
-mike

signature.asc (853 bytes) Download Attachment

Re: x86 cross toolchain and pthread_* weak symbols

2009-11-30T14:20:46Z

Le lundi 30 novembre 2009 à 21:51 +0000, Martin Guy a écrit :

> On 11/30/09, Lionel Landwerlin <llandwerlin@...> wrote:
> > I'm using crosstool-ng to generate a cross toolchain for an x86 target
> > (nothing too exciting...) and I'm kind of disappointed because I get
> > some pthread_* weak symbols inside my toolchain :
> >
> > /opt/cross_x86/i686-cm-linux-gnu/lib/libdl-2.10.2.so
> > w __pthread_getspecific
> > w __pthread_key_create
> > w __pthread_once
> > w __pthread_setspecific
> >
> > I'm wondering why I don't have these weak symbols on my host system
> > (debian unstable) which is an x86 too, and using the same toolchain
> > (both using gcc-4.3.4 + eglibc-2.10/nptl, but binutils 2.19 in my cross
> > toolchain, 2.20 on my host system).
>
> Does that cause any disfunction or is it just annoying?
>
> M
>

Well, after I built my toolchain, I started playing a little with
buildroot. I did build a rootfs with it, containing directfb.
Every directfb application I launched used to crash early in the
initialization of directfb. After launching gdb on a directfb example, I
found that the process was crashing with its pc at 0x0. The previous
function in the stack was pthread_once. The address of the pthread_once
symbol in the process was wrong (that's what I though first), it was
inside the mapped code of libdl.so, instead of the mapped code of
libpthread.
Finally I found these weak symbols all over the toolchain.

The stack was something like that :

0x0
pthread_once
dlopen

(I will provide stack trace later)

Directfb examples'/applications' are the only binary crashing as
described. But I didn't build a lot of packages and directfb might be
the only binary using dlopen in my setup.

Regards,

--
Lionel Landwerlin

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

Re: x86 cross toolchain and pthread_* weak symbols

2009-11-30T13:51:27Z

On 11/30/09, Lionel Landwerlin <llandwerlin@...> wrote:

Does that cause any disfunction or is it just annoying?

M

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

x86 cross toolchain and pthread_* weak symbols

2009-11-30T13:12:08Z

Hi all,

I'm using crosstool-ng to generate a cross toolchain for an x86 target
(nothing too exciting...) and I'm kind of disappointed because I get
some pthread_* weak symbols inside my toolchain :

/opt/cross_x86/i686-cm-linux-gnu/lib/libdl-2.10.2.so
w __pthread_getspecific
w __pthread_key_create
w __pthread_once
w __pthread_setspecific

I'm wondering why I don't have these weak symbols on my host system
(debian unstable) which is an x86 too, and using the same toolchain
(both using gcc-4.3.4 + eglibc-2.10/nptl, but binutils 2.19 in my cross
toolchain, 2.20 on my host system).

Thanks for your responses.

Regards,

--
Lionel Landwerlin

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

Re: ng-1.5.2: "long-term stable" kernel version

2009-11-30T12:28:29Z

Zvi,
All,

On Monday 30 November 2009 20:46:29 Zvi Vered wrote:
> I built a toolchain for i686 using 2.6.31.1
> Then I noticed the words "long-term stable" near 2.6.27.35
> What does it mean ?
> Did someone made QA tests for this version ?

http://marc.info/?l=linux-kernel&m=122375909403298&w=2

> I had problems with 2.6.29 and 2.6.31.1.
> I'm sure the cause to the problems is not the toolchain but the kernel code.

Without the error message, the context, and other related information, we are
not able to help you.

--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
`------------------------------^-------^------------------^--------------------'

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

ng-1.5.2: "long-term stable" kernel version

2009-11-30T11:46:29Z

Hello,

I built a toolchain for i686 using 2.6.31.1
Then I noticed the words "long-term stable" near 2.6.27.35
What does it mean ?
Did someone made QA tests for this version ?

I had problems with 2.6.29 and 2.6.31.1.
I'm sure the cause to the problems is not the toolchain but the kernel code.

Thanks.

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

[Fwd: Re: 1.5.2 built, but with error]

2009-11-28T02:21:31Z

Forgot reply all...

-------- Original Message --------
Subject: Re: 1.5.2 built, but with error
Date: Fri, 27 Nov 2009 07:34:50 -0600
From: Harold Grovesteen <h.grovsteen@...>
To: piper.guy1 <piper.guy1@...>
References: <dafb71610911262147s6b1e8d9fr707da95563416c4d@...>

piper.guy1 wrote:

>I successfully built 1.5.2. It built to completion. However I noticed
>this error which took place way before the build ended.
>
>Should I be concerned?
>
>thanx
>/carl h
>
>
>INFO ] =================================================================
>[INFO ] Installing final compiler
>[EXTRA] Configuring final compiler
>[EXTRA] Building final compiler
>[ERROR] libtool.m4: error: problem compiling FC test program
>[EXTRA] Installing final compiler
>[INFO ] Installing final compiler: done in 859.56s (at 63:12)
>
>--
>For unsubscribe information see http://sourceware.org/lists.html#faq
>
>
>

No, gcc is trying to test the Fortran compiler. If you did not build a
Fortran compiler, this result is correct. It should fail. Why gcc
wants to test it when it wasn't built of course could be perceived as a
separate type of error, but does not likely reflect a problem with your
toolchain.

I get this too when I build my toolchain. Yann researched this a while
back and you might find it if you google the error. It should be in the
email archive somewhere.

Harold Grovesteen

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

1.5.2 built, but with error

2009-11-26T21:47:00Z

I successfully built 1.5.2. It built to completion. However I noticed
this error which took place way before the build ended.

Should I be concerned?

thanx
/carl h

INFO ] =================================================================
[INFO ] Installing final compiler
[EXTRA] Configuring final compiler
[EXTRA] Building final compiler
[ERROR] libtool.m4: error: problem compiling FC test program
[EXTRA] Installing final compiler
[INFO ] Installing final compiler: done in 859.56s (at 63:12)

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

Re: getline conflict error

2009-11-26T10:49:08Z

Carl,
All,

On Thursday 26 November 2009 18:40:36 piper.guy1 wrote:
> Sorry to ask again but I didn't get a response yet. Any ideas on this?

> > [ALL ] HOSTCC extra/scripts/unifdef
> > [ERROR] extra/scripts/unifdef.c:209: error: conflicting types for 'getline'
> > [ALL ] /usr/include/stdio.h:651: note: previous declaration of
> > 'getline' was here
> > [ERROR] make[1]: *** [extra/scripts/unifdef] Error 1
> > [ALL ] make[1]: Leaving directory

This has already been dealt with at least twice on the list, search the
archives.

Here's the thread containing the answer:
http://sourceware.org/ml/crossgcc/2009-10/msg00066.html

And here's the corresponding commit in the crosstool-NG repository:
http://ymorin.is-a-geek.org/hg/crosstool-ng/rev/1ba79f2126df

And the same commit backported to the 1.5 branch:
http://ymorin.is-a-geek.org/hg/crosstool-ng/rev/01d01185eb18

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
`------------------------------^-------^------------------^--------------------'

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

Re: getline conflict error

2009-11-26T09:40:36Z

Yann or anyone,

Sorry to ask again but I didn't get a response yet. Any ideas on this?
I'm stuck.

thanx
/carl h.

On Wed, Nov 25, 2009 at 12:29 PM, piper.guy1 <piper.guy1@...> wrote:

> My build failed. Seems to be a 'getline' conflict.
>
> Any help would be appreciated.
>
> thanx
> /carl h.
>
> [ALL ] LN include/sys/ptrace.h
> [ALL ] LN include/sys/elf.h
> [ALL ] LN include/sys/io.h
> [ALL ] LN include/sys/procfs.h
> [ALL ] LN include/sys/ucontext.h
> [ALL ] LN include/sys/user.h
> [ALL ] make[1]: Leaving directory
> `/home/carl/felabs/sysdev/toolchain/crosstool-ng-1.5.1/targets/arm-unknown-linux-uclibcgnueabi/build/build-libc-headers'
> [EXTRA] Installing headers
> [DEBUG] ==> Executing: 'make CROSS=
> PREFIX=/usr/local/xtools/arm-unknown-linux-uclibcgnueabi/arm-unknown-linux-uclibcgnueabi//sys-root/
> install_headers'
> [ALL ] make[1]: Entering directory
> `/home/carl/felabs/sysdev/toolchain/crosstool-ng-1.5.1/targets/arm-unknown-linux-uclibcgnueabi/build/build-libc-headers'
> [ALL ] HOSTCC extra/scripts/unifdef
> [ERROR] extra/scripts/unifdef.c:209: error: conflicting types for 'getline'
> [ALL ] /usr/include/stdio.h:651: note: previous declaration of
> 'getline' was here
> [ERROR] make[1]: *** [extra/scripts/unifdef] Error 1
> [ALL ] make[1]: Leaving directory
> `/home/carl/felabs/sysdev/toolchain/crosstool-ng-1.5.1/targets/arm-unknown-linux-uclibcgnueabi/build/build-libc-headers'
> [ERROR] Build failed in step 'Installing C library headers'
> [ERROR] Error happened in
> '/home/carl/felabs/sysdev/toolchain/crosstool-ng-1.5.1/scripts/functions'
> in function 'CT_DoExecLog' (line unknown, sorry)
> [ERROR] called from
> '/home/carl/felabs/sysdev/toolchain/crosstool-ng-1.5.1/scripts/build/libc/uClibc.sh'
> at line # 88 in function 'do_libc_headers'
> [ERROR] called from
> '/home/carl/felabs/sysdev/toolchain/crosstool-ng-1.5.1/scripts/crosstool-NG.sh'
> at line # 544 in function 'main'
> [ERROR] Look at
> '/usr/local/xtools/arm-unknown-linux-uclibcgnueabi/build.log' for more
> info on this error.
> [ERROR] (elapsed: 43:43.10)
>

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

Re: New Alpha cross-toolchain

2009-11-25T22:23:14Z

Hello,

> Hello Ioannis!
> Hello All!
>
> On Wednesday 25 November 2009 20:09:02 venetis@... wrote:
>> I managed to build the following set of tools for Alpha EV56 (basically,
>> all the latest versions supported from ct-ng when I copied it from the
>> trunk):
>
> Hey, nice!
>
>> gcc-4.2.2 (including C++ and Fortran)
>
> You mean, gcc-4.4.2, not gcc-4.2.2 (which is quite old, now) ?

Yes, indeed, I mean gcc-4.4.2 here.

>> glibc-2.10.1
>> binutils-2.20
>> linux-2.6.31.5
>> gmp-4.3.1
>> mpfr-2.4.1
>> ppl-0.10.2
>> cloog/ppl-0.15.7
>> mpc-0.7
>
>> In order to complete the build, however, I had to do the following:
>> 1) Copy these 3 files from patches/glibc/2.9 to
>> patches/glibc/ports-2.10.1
>> a) 540-alpha-atfcts.patch
>> b) 560-syslog.patch
>> c) 570-debug-readlink_chk-readklinkat_chk.patch
>
> OK, done.
>
>> 2) Replace the file
>> patches/glibc/ports-2.10.1/440-alpha-cache-shape.patch
>> with the file patches/glibc/2.9/480-alpha-glibc-2.8-cache-shape.patch
>
> Not really: they are not based on the same directory depth. But once that
> was
> fixed, then the build succeeded. I'll trust you that the resulting
> toolchain
> is indeed operational.

And yes to this one too. I forgot to mention it :-)

Best regards,

Ioannis E. Venetis

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

Re: New Alpha cross-toolchain

2009-11-25T14:12:32Z

Hello Ioannis!
Hello All!

On Wednesday 25 November 2009 20:09:02 venetis@... wrote:
> I managed to build the following set of tools for Alpha EV56 (basically,
> all the latest versions supported from ct-ng when I copied it from the
> trunk):

Hey, nice!

> gcc-4.2.2 (including C++ and Fortran)

You mean, gcc-4.4.2, not gcc-4.2.2 (which is quite old, now) ?

> glibc-2.10.1
> binutils-2.20
> linux-2.6.31.5
> gmp-4.3.1
> mpfr-2.4.1
> ppl-0.10.2
> cloog/ppl-0.15.7
> mpc-0.7

> In order to complete the build, however, I had to do the following:
> 1) Copy these 3 files from patches/glibc/2.9 to patches/glibc/ports-2.10.1
> a) 540-alpha-atfcts.patch
> b) 560-syslog.patch
> c) 570-debug-readlink_chk-readklinkat_chk.patch

OK, done.

> 2) Replace the file patches/glibc/ports-2.10.1/440-alpha-cache-shape.patch
> with the file patches/glibc/2.9/480-alpha-glibc-2.8-cache-shape.patch

Not really: they are not based on the same directory depth. But once that was
fixed, then the build succeeded. I'll trust you that the resulting toolchain
is indeed operational.

Thank you for the update! I'll publish it soon.

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
`------------------------------^-------^------------------^--------------------'

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

New Alpha cross-toolchain

2009-11-25T11:09:02Z

Hello,

I managed to build the following set of tools for Alpha EV56 (basically,
all the latest versions supported from ct-ng when I copied it from the
trunk):

gcc-4.2.2 (including C++ and Fortran)
glibc-2.10.1
binutils-2.20
linux-2.6.31.5
gmp-4.3.1
mpfr-2.4.1
ppl-0.10.2
cloog/ppl-0.15.7
mpc-0.7

In order to complete the build, however, I had to do the following:

1) Copy these 3 files from patches/glibc/2.9 to patches/glibc/ports-2.10.1
a) 540-alpha-atfcts.patch
b) 560-syslog.patch
c) 570-debug-readlink_chk-readklinkat_chk.patch

2) Replace the file patches/glibc/ports-2.10.1/440-alpha-cache-shape.patch
with the file patches/glibc/2.9/480-alpha-glibc-2.8-cache-shape.patch

No problems after that.

Ioannis E. Venetis

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

Re: Mac OS X compiling

2009-11-25T10:43:10Z

Ryan,
All,

Sorry for the delay, I've been a bit busy lately...

On Monday 16 November 2009 23:43:24 Ryan Govostes wrote:
> I'm attaching a patch to the configure script. Since I'm not too familiar
> with the build system I'd like some feedback on it while I continue to make
> more changes.

I'm uneasy with so much changes in one go. Could you try to split the path
up into separate, self-contained and maeningful changes, please?

For example, avoid presentation-related changes (eg. correct indentation)
with functional changes; add the check for 'stat', libtool, libtoolize each
in their own patch; and so on...

If possible, please use Mercurial the Mercurial repository to base your
changes on, and use the Mercurial patchbomb extension to send your patches,
it's much easier to work with. Look at docs/overview.txt, section titled
"Contributing" for a quick explanations.

> 1) More effective detection of sed parameters. Checks for the correct
> format of the zero-length -i option, as well as -r vs -E for extended
> regex.

Well, GNU sed interprets '-i' as 'in-place', which means the result goes
back into the input file. OSX sed has no such option. So you have to handle
it otherwise, just dumping the '-i' is not he solution.

> 2) More effective detection of libtool / libtoolize. Looks for glibtool
> / glibtoolize if the first check fails.

You have to save the result in the paths.mk, and then use that in
scripts/crosstool-NG.sh to create a bin-override wrapper (at about line 76).

> 3) More effective of detection of stat. So far, just determines whether
> to pass -c or -f, but since the format strings are different, this should
> be elaborated on.

Ditto. Applies to scripts/functions and scripts/populate.in

> 4) Custom implementation of recursive readlink (i.e., `readlink -e`). This
> option is not supported on BSD, so we simulate it.

@@ -22,6 +22,14 @@
exit 1
}

+# Recursively run `readlink' in lieu of the -e option on BSD hosts.
+rreadlink() {
+ where="${@}"
+ until [ "${where}" = "$(readlink "${where}")" ]; do
+ where="$(readlink "${where}")"

Please use a temporary variable to avoid calling readlink twice.

+ done
+}
+
# Given an option string and the following argument,
# echoes the value of the option.
# If --var=val => echoes val and returns 0, meaning second arg was not consumed
@@ -160,7 +168,7 @@
printf "Checking for '${item}'... "
where="$( gcc -print-file-name="${item}" )"
if [ "${where}" != "${item}" ]; then
- where="$( readlink -e "${where}" )"
+ rreadlink "${where}"

Nope, please use like that:
where="$(rreadlink "${where}")"

> I think the options detected during configuration still need to be somehow
> passed through to the build scripts, since right now they are used to
> generate the Makefile and then go out of scope.

Yep, use the bin-override directory, as mentioned above.

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
`------------------------------^-------^------------------^--------------------'

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

Re: [PATCH 0 of 1] compiling glibc-2.9 with binutils-2.20 [RETRY]

2009-11-25T10:14:03Z

Frederic,
All,

On Wednesday 25 November 2009 09:11:42 Frederic Roussel wrote:
> Here's a glibc patch to allow compiling glibc-2.9 with binutils-2.20. Just
> configure needed change. I am far from certain that my configure.in change
> is 100% correct.

It's not, but is highly sufficient for our use case and the forseeable future
(IMHO). And, BTW, your submission was correct, I just have to convince the
administrators of my mail-relay (anciens.enib.fr) that their anti-spam and
anti-virus are deffective (or at least that their configuration is).

Anyway, patch applied, thank you! :-)

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
`------------------------------^-------^------------------^--------------------'

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

getline conflict error

2009-11-25T09:29:26Z

My build failed. Seems to be a 'getline' conflict.

Any help would be appreciated.

thanx
/carl h.

[ALL ] LN include/sys/ptrace.h
[ALL ] LN include/sys/elf.h
[ALL ] LN include/sys/io.h
[ALL ] LN include/sys/procfs.h
[ALL ] LN include/sys/ucontext.h
[ALL ] LN include/sys/user.h
[ALL ] make[1]: Leaving directory
`/home/carl/felabs/sysdev/toolchain/crosstool-ng-1.5.1/targets/arm-unknown-linux-uclibcgnueabi/build/build-libc-headers'
[EXTRA] Installing headers
[DEBUG] ==> Executing: 'make CROSS=
PREFIX=/usr/local/xtools/arm-unknown-linux-uclibcgnueabi/arm-unknown-linux-uclibcgnueabi//sys-root/
install_headers'
[ALL ] make[1]: Entering directory
`/home/carl/felabs/sysdev/toolchain/crosstool-ng-1.5.1/targets/arm-unknown-linux-uclibcgnueabi/build/build-libc-headers'
[ALL ] HOSTCC extra/scripts/unifdef
[ERROR] extra/scripts/unifdef.c:209: error: conflicting types for 'getline'
[ALL ] /usr/include/stdio.h:651: note: previous declaration of
'getline' was here
[ERROR] make[1]: *** [extra/scripts/unifdef] Error 1
[ALL ] make[1]: Leaving directory
`/home/carl/felabs/sysdev/toolchain/crosstool-ng-1.5.1/targets/arm-unknown-linux-uclibcgnueabi/build/build-libc-headers'
[ERROR] Build failed in step 'Installing C library headers'
[ERROR] Error happened in
'/home/carl/felabs/sysdev/toolchain/crosstool-ng-1.5.1/scripts/functions'
in function 'CT_DoExecLog' (line unknown, sorry)
[ERROR] called from
'/home/carl/felabs/sysdev/toolchain/crosstool-ng-1.5.1/scripts/build/libc/uClibc.sh'
at line # 88 in function 'do_libc_headers'
[ERROR] called from
'/home/carl/felabs/sysdev/toolchain/crosstool-ng-1.5.1/scripts/crosstool-NG.sh'
at line # 544 in function 'main'
[ERROR] Look at
'/usr/local/xtools/arm-unknown-linux-uclibcgnueabi/build.log' for more
info on this error.
[ERROR] (elapsed: 43:43.10)

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

Re: crosstool-NG build fails

2009-11-25T09:17:10Z

thanks
/carl

On Wed, Nov 25, 2009 at 11:36 AM, Yann E. MORIN
<yann.morin.1998@...> wrote:

> Carl,
> All,
>
> piper.guy1 wrote:
>>
>> Upon investigation of your wget command string, it appears to have to
>> do with your 10 second timeout. When I increased the timeout to 30
>> secs it worked all the time. The same problem happened for the uClibc
>> tarball, and when I increased the timeout to 30 sec, it worked too.
>> The other locations for the other tarballs I guess are more responsive
>> as the script had no problems with them.
>
> Ah, OK. You should tweak the CONNECT_TIMEOUT option:
>
> Paths and misc options --->
> (10) connection timeout
>
> The default is 10s, but read the help entry.
>
> We do need the connection timeout value to detect hosts that are down, so we
> can fallback to other sources, and ultimately to try the mirror.
>
>> So I'm manually downloading any troublesome tarballs and putting them
>> into the tarball folder. Am I safe to do it this way as a work around?
>
> Yes, you can do it that way. Yet, the best is to correctly set the
> connection
> timeout value.
>
> Regards,
> Yann E. MORIN.
>
> --
> .-----------------.--------------------.------------------.--------------------.
> | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics'
> conspiracy: |
> | +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^
> |
> | --==< O_o >==-- '------------.-------: X AGAINST | /e\ There is
> no |
> | http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL | """
> conspiracy. |
> '------------------------------'-------'------------------'--------------------'
>

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

Re: crosstool-NG build fails

2009-11-25T08:36:28Z

Carl,
All,

piper.guy1 wrote:
> Upon investigation of your wget command string, it appears to have to
> do with your 10 second timeout. When I increased the timeout to 30
> secs it worked all the time. The same problem happened for the uClibc
> tarball, and when I increased the timeout to 30 sec, it worked too.
> The other locations for the other tarballs I guess are more responsive
> as the script had no problems with them.

Ah, OK. You should tweak the CONNECT_TIMEOUT option:

Paths and misc options --->
(10) connection timeout

The default is 10s, but read the help entry.

We do need the connection timeout value to detect hosts that are down, so we
can fallback to other sources, and ultimately to try the mirror.

> So I'm manually downloading any troublesome tarballs and putting them
> into the tarball folder. Am I safe to do it this way as a work around?

Yes, you can do it that way. Yet, the best is to correctly set the connection
timeout value.

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^ |
| --==< O_o >==-- '------------.-------: X AGAINST | /e\ There is no |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL | """ conspiracy. |
'------------------------------'-------'------------------'--------------------'

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

Re: crosstool-NG build fails

2009-11-25T08:21:32Z

On Wed, Nov 25, 2009 at 2:01 AM, Yann E. MORIN
<yann.morin.1998@...> wrote:

> Carl,
> All,
>
> On Wednesday 25 November 2009 05:08:18 piper.guy1 wrote:
>> Here's what your script does. I extracted it from the log file and
>> tried it at the command line. It doesn't work.
>> carl@xu-mobile1:~/felabs/sysdev/toolchain/crosstool-ng-1.5.1$ wget
>> -T 10 -nc --progress=dot:binary --tries=1 ftp://gcc.gnu.org
>> /pub/gcc/infrastructure/cloog-ppl-0.15.7.tar.gz
>> --2009-11-24 22:51:20--
>> ftp://gcc.gnu.org/pub/gcc/infrastructure/cloog-ppl-0.15.7.tar.gz
>> => `cloog-ppl-0.15.7.tar.gz'
>> Resolving gcc.gnu.org... 209.132.176.174
>> Connecting to gcc.gnu.org|209.132.176.174|:21... connected.
>> Logging in as anonymous ...
>> Error in server response, closing control connection.
>> Giving up.
>
> Here's my own try:
>
> # wget -T 10 -nc --progress=dot:binary --tries=1 \
> ftp://gcc.gnu.org/pub/gcc/infrastructure/cloog-ppl-0.15.7.tar.gz
> --2009-11-25 07:54:05-- ftp://gcc.gnu.org/pub/gcc/infrastructure/cloog-ppl-0.15.7.tar.gz
> => `cloog-ppl-0.15.7.tar.gz'
> Resolving gcc.gnu.org... 209.132.176.174
> Connecting to gcc.gnu.org|209.132.176.174|:21... connected.
> Logging in as anonymous ... Logged in!
> ==> SYST ... done. ==> PWD ... done.
> ==> TYPE I ... done. ==> CWD /pub/gcc/infrastructure ... done.
> ==> SIZE cloog-ppl-0.15.7.tar.gz ... 767746
> ==> PASV ... done. ==> RETR cloog-ppl-0.15.7.tar.gz ... done.
> Length: 767746 (750K)
>
> 0K ................ ................ ................ 51% 196K 2s
> 384K ................ ................ ............. 100% 352K=3.0s
>
> 2009-11-25 07:54:11 (250 KB/s) - `cloog-ppl-0.15.7.tar.gz' saved [767746]
>
> So it *is* working for me here!
>
> Definitely, there is a problem on your side. I don't see what to invetigate
> upon, beside what I suggested in my previous mail. I'm sorry, but I have
> no other clue.
>
> Regards,
> Yann E. MORIN.
>
> --
> .-----------------.--------------------.------------------.--------------------.
> | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
> | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
> `------------------------------^-------^------------------^--------------------'
>
>
>

Upon investigation of your wget command string, it appears to have to
do with your 10 second timeout. When I increased the timeout to 30
secs it worked all the time. The same problem happened for the uClibc
tarball, and when I increased the timeout to 30 sec, it worked too.
The other locations for the other tarballs I guess are more responsive
as the script had no problems with them.

So I'm manually downloading any troublesome tarballs and putting them
into the tarball folder. Am I safe to do it this way as a work around?

thanx
/carl h.

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

Re: [PATCH 0 of 1] compiling glibc-2.9 with binutils-2.20 [RETRY]

2009-11-25T04:45:00Z

Frederic Roussel wrote:

>Hi all
>
>Sorry for the retry - I'm still a mercurial noobie and it shows :-(
>
A lot of that going on here. You are not alone.

Harold

>
>
>
>

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

[PATCH 1 of 1] patches/glibc: allows glibc2.9 to be compiled with binutils 2.20

2009-11-25T00:11:43Z

# HG changeset patch
# User "Frederic Roussel" <fr.frasc@...>
# Date 1259136642 28800
# Node ID 489e9f2158fa8bd86e3080af1c63983b097fc93e
# Parent 496eeb7effad7574955bceb2cbec7c3b970189ed
patches/glibc: allows glibc2.9 to be compiled with binutils 2.20

the configure script had to be modified to accept as/ld at versions greater
than 2.19
Signed-off-by: Frederic Roussel <fr.frasc@...>

diff -r 496eeb7effad -r 489e9f2158fa patches/glibc/2.9/600-recent-binutils.patch
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/patches/glibc/2.9/600-recent-binutils.patch Wed Nov 25 00:10:42 2009 -0800
@@ -0,0 +1,37 @@
+diff -r -u glibc-cvs-2.9.orig/configure glibc-cvs-2.9/configure
+--- glibc-cvs-2.9.orig/configure 2008-11-11 01:50:11.000000000 -0800
++++ glibc-cvs-2.9/configure 2009-11-24 17:52:27.000000000 -0800
+@@ -4531,7 +4531,7 @@
+ ac_prog_version=`$AS --version 2>&1 | sed -n 's/^.*GNU assembler.* $[0-9]*\.[0-9.]*$.*$/\1/p'`
+ case $ac_prog_version in
+ '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;;
+- 2.1[3-9]*)
++ 2.1[3-9]*|2.20)
+ ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;;
+ *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;;
+
+@@ -4594,7 +4594,7 @@
+ ac_prog_version=`$LD --version 2>&1 | sed -n 's/^.*GNU ld.* $[0-9][0-9]*\.[0-9.]*$.*$/\1/p'`
+ case $ac_prog_version in
+ '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;;
+- 2.1[3-9]*)
++ 2.1[3-9]*|2.20)
+ ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;;
+ *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;;
+
+diff -r -u glibc-cvs-2.9.orig/configure.in glibc-cvs-2.9/configure.in
+--- glibc-cvs-2.9.orig/configure.in 2008-11-11 01:50:11.000000000 -0800
++++ glibc-cvs-2.9/configure.in 2009-11-24 17:53:35.000000000 -0800
+@@ -844,10 +844,10 @@
+ # Accept binutils 2.13 or newer.
+ AC_CHECK_PROG_VER(AS, $AS, --version,
+ [GNU assembler.* $[0-9]*\.[0-9.]*$],
+- [2.1[3-9]*], AS=: critic_missing="$critic_missing as")
++ [2.1[3-9]*|2.20], AS=: critic_missing="$critic_missing as")
+ AC_CHECK_PROG_VER(LD, $LD, --version,
+ [GNU ld.* $[0-9][0-9]*\.[0-9.]*$],
+- [2.1[3-9]*], LD=: critic_missing="$critic_missing ld")
++ [2.1[3-9]*|2.20], LD=: critic_missing="$critic_missing ld")
+
+ # We need the physical current working directory. We cannot use the
+ # "pwd -P" shell builtin since that's not portable. Instead we try to

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

[PATCH 0 of 1] compiling glibc-2.9 with binutils-2.20 [RETRY]

2009-11-25T00:11:42Z

Hi all

Sorry for the retry - I'm still a mercurial noobie and it shows :-(

Here's a glibc patch to allow compiling glibc-2.9 with binutils-2.20. Just
configure needed change. I am far from certain that my configure.in change
is 100% correct.

The problem showed up when I tried to compile glibc-2.10.1, but it failed with
a problem already discussed earlier (July 23 in the mailing list). So I changed
the glibc version without back-revving the binutils too. Anyway, more on that
after the turkey ;-)

Happy Thanksgiving

--Frederic

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

cross compiling under cygwin problem

2009-11-24T23:47:18Z

Hi,
I am trying compiling a cross compiler for linux running in cygwin
(build=host = cygwin/target=linux x86), using crosstools-ng-1.5.1
I have got my compilation stopped here :

checking for .popsection assembler directive... no
[ERROR] checking for .protected and .hidden assembler directive...
configure: error: assembler support for symbol visibility is required
[ERROR] Build failed in step 'Installing C library headers / start
files'
[ERROR] Error happened in
'/usr/local/lib/ct-ng-1.5.1/scripts/functions' in function 'CT_DoExecLog'
(line unknown, sorry)
[ERROR] called from
'/usr/local/lib/ct-ng-1.5.1/scripts/build/libc/eglibc.sh' at line # 156 in
function 'do_libc_start_files'
[ERROR] called from
'/usr/local/lib/ct-ng-1.5.1/scripts/crosstool-NG.sh' at line # 544 in
function 'main'
[ERROR] Look at '/test/x-tools/i686-unknown-linux-gnu/build

I googled and found the following similar problem :
http://old.nabble.com/Re:-Fwd:-Cross-compiler-build-stops-td14243012.html

any idea ?

enclosed is the build log

Best Regards
S.Ancelot

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

build.log (1M) Download Attachment

[PATCH 1 of 1] patches/glibc: allows glibc2.9 to be compiled with binutils 2.20

2009-11-24T23:18:26Z

# HG changeset patch
# User "Frederic Roussel" <fr.frasc@...>
# Date 1259133428 28800
# Node ID 427cca5560d3ff2df143e6fb4e3b34028c094e97
# Parent 496eeb7effad7574955bceb2cbec7c3b970189ed
patches/glibc: allows glibc2.9 to be compiled with binutils 2.20

the configure script had to be modified to accept as/ld at versions greater
than 2.19
Signed-off-by: Frederic Roussel <fr.frasc@...>

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

[PATCH 0 of 1] compilinmg glibc-2.9 with binutils-2.20

2009-11-24T23:18:25Z

Hi all

Here's a glibc patch to allow compiling glibc-2.9 with binutils-2.20. Just
configure needed change. I am far from certain that my configure.in change
is 100% correct.

The problem showed up when I tried to compile glibc-2.10.1, but it failed with
a problem already discussed earlier (July 23 in the mailing list). So I changed
the glibc version without back-revving the binutils too. Anyway, more on that
after the turkey ;-)

Happy Thanksgiving

--Frederic

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