error processing 220-noteGNUstack-01.patch
Sat May 2 07:03:00 GMT 2009

Yann E. MORIN wrote:
> Hello all!
> On Wednesday 29 April 2009 22:59:25 wrote:
>> Yann E. MORIN wrote:
>>> OK. I guess reiser4 is case-sensitive, is it not?
>> Sure, it's case sensitive.
>> but this does not seem to be a false error , the file does already 
>> exist.
> No, it does (should) not exist. The patch creates the file:
>   boehm-gc/ia64_save_regs_in_stack.S
> and the file that already exists is:
>   boehm-gc/ia64_save_regs_in_stack.s
> The difference is subtle: the existing file has a lower-case 's' as
> extension, while the file that gets created has a upper-case 'S'.
> The patch does apply cleanly here on ext3.
> Hence the question about the case-sensitivity of your file system.
> If your file system is case sensitive, then if a file named "foo"
> exists, then testing for existence of "FOO" will succeed. And the
> patch utility will fail.
> This happens all the time under Windows/Cygwin.
>> I have not rerun anything since the run that failed. The error it  
>> states is correct.
> Telling it again and again will not make it true:
>  that file - does - not - exist - in the gcc-4.3.2 tarball.
> If you have such a file, then:
> - either your file system is not case-sensitive,
> - or your gcc-4.3.2 tarball is not pristine.
>> The file exists and has the expected content. Why is  
>> the patch being called?
> The patch creates the .S (upper-case) file and removes a file with a
> .s (lower-case) extension, and the same content. 
>> Is there a way with ct-ng to remove this patch and rebuild without it 
>> being refeched?
> No, there is none.
>> Or can you suggest another work around?
> Let's try to understand what on Earth is going on:
> - if there is a bug, let's shoot it down.
> - if there is an operator error, let's update the doc.
> Don't workaround bugs/errors: they're still there lurking until we
> forget about the workaround, and we'll get bitten back sooner or later.
> Regards,
> Yann E. MORIN.
OK, I just installed a clean 1.4.0 and loaded arm-unknown-linux-gnuabi 
sample which included the addons and cvs fetch. The extra options are 
now showing in C library menu.

I modified ARCH to armv4t to match my hardware and the gcc and glibc 
issues have disappeared.

I can only assume that the problems I was having came from installing 
1.4.0 on top of 1.3.4 rather than a clean installation and/or some other 

I have not tested the toolchain yet but I got a clean build.

Thanks for your help, Yann.


For unsubscribe information see

More information about the crossgcc mailing list