On 31/01/2010 22:32, Sébastien Lorquet wrote:
> as is generating garbage and ld and objdump are victims.
Yep. The section headers are full of nonsense. The string table is present
and all the long section names are there, but all the section headers containt
"/1579551", which is way out of ra
sorry false alarm. This does NOT fix anything.
another sample output from my decoder:
reading global header for
C:\sources\ucvm\trunk\Debug\arm-wince\libloaderfs.a
global header: !
global header ok
file name: /
this is the symbol lookup table
file mod timestamp: 666709491344
file oid: 197232
fil
I'm sorry Dave, I'm afraid ld can't let me do that...
hrm... well
Just tried the very command you reported. My XP is SP3.
C:\mingw32ce-4.1-20100125>dir
Le volume dans le lecteur C n'a pas de nom.
Le numéro de série du volume est 80AF-8B27
Répertoire de C:\mingw32ce-4.1-20100125
31/01/20
On 31/01/2010 15:39, Dave Korn wrote:
> I'll try a full clean build with nothing preinstalled and this patch:
>
> Index: build-mingw32ce.sh
> ===
> --- build-mingw32ce.sh (revision 1440)
> +++ build-mingw32ce.sh (working copy)
>
[ I'm going AFK from a couple of hours, so let me reply quickly
just half the questions ]
On Sunday 31 January 2010 17:06:32, Dave Korn wrote:
> LOL, that made me do a double-take. Err? Is this maybe deliberate because
> (WAG) fastcall doesn't mean anything on CE or some such reason?
Yes, ex
On 31/01/2010 16:39, Pedro Alves wrote:
> These look pretty busted though:
>
> --- /opt/mingw32ce-0.59/arm-mingw32ce/include/windef.h 2010-01-31
> 15:10:18.0 +
> +++ /opt/mingw32ce-0.59/lib/gcc/arm-mingw32ce/4.4.0/include-fixed/windef.h
> 2010-01-31 15:21:19.0 +
>
On 27/01/2010 00:54, Sébastien Lorquet wrote:
> The latest toolchain, that produces the bug, is at:
> http://www.unsads.com/~squalyl/cegcc/mingw32ce-4.1-20100125.zip
I downloaded this zip and unpacked it to C:\ on a WinXpSp2 machine, then ran
PATH C:\mingw32ce-4.1-20100125\cross41\bin;%PATH%
On Sunday 31 January 2010 16:26:38, Dave Korn wrote:
> -#if defined(UNDER_CE) && defined(__arm__)
> +#if defined(__UNDER_CE__) && defined(__arm__)
> -#ifdef UNICODE
> +#ifdef __UNICODE__
> Do those look sensible to you? There could conceivably be some knock-on
> effect of having all the fixed
this will drive me nuts.
Adding a dummy.c file to the archive, containing a
char test_if_this_will_fix_the_problem; (or any name, of course ;) )
fixes the problem, and the file format invalid error disappears. This will
be a workaround, but we need to fix it.
Sebastien
-
A "working" archive file is also invalid according to my tool. I assume it
works because ld or other tools only look at the symbol table header.
Sebastien
--
The Planet: dedicated and managed hosting, cloud storage, coloca
Hi,
see
https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2942499&group_id=173455
I investigated this one too. Same as the ld one , I can't understand why
this happens only in mingw and not in linux.
I made an ar file decoder to find who is right, together with this (
http://en.wikipe
On 31/01/2010 15:31, Pedro Alves wrote:
> On Sunday 31 January 2010 15:23:05, Dave Korn wrote:
>>> in t-wince-pe (or some other make fragment) ?
>>>
>>> I see that config/i386/t-mingw32 has:
>>>
>>> NATIVE_SYSTEM_HEADER_DIR = /mingw/include
>> Will that work in cross?
>
> Yes. Due to:
>
> conf
On Sunday 31 January 2010 15:23:05, Dave Korn wrote:
>
> > in t-wince-pe (or some other make fragment) ?
> >
> > I see that config/i386/t-mingw32 has:
> >
> > NATIVE_SYSTEM_HEADER_DIR = /mingw/include
>
> Will that work in cross?
Yes. Due to:
configure.ac:
CROSS_SYSTEM_HEADER_DIR='$(TARG
On 31/01/2010 14:43, Dave Korn wrote:
> Doh. I'll try --with-headers/--with-libs instead.
So, adding "--with-headers=$prefix/arm-mingw32ce/include
--with-libs=$prefix/arm-mingw32ce/lib" to the configure line for the main gcc
build gets me an installation with lots of new fixed headers in the
On 31/01/2010 14:48, Pedro Alves wrote:
> On Sunday 31 January 2010 14:43:06, Dave Korn wrote:
>>> The directory that should contain system headers does not exist:
>>> /opt/mingw32ce/arm-mingw32ce/usr/include
>
> Hmm, or:
>
> NATIVE_SYSTEM_HEADER_DIR = /include
>
> in t-wince-pe (or some othe
On Sunday 31 January 2010 14:43:06, Dave Korn wrote:
> > The directory that should contain system headers does not exist:
> > /opt/mingw32ce/arm-mingw32ce/usr/include
Hmm, or:
NATIVE_SYSTEM_HEADER_DIR = /include
in t-wince-pe (or some other make fragment) ?
I see that config/i386/t-mingw32 h
On 31/01/2010 14:27, Dave Korn wrote:
> On 31/01/2010 12:54, Pedro Alves wrote:
>> I think we should be building gcc with
>> `--with-sysroot=${PREFIX}/arm-mingw32ce/'
>
> Just testing that in a non-bootstrap build of gcc only.
Hmm, it's not quite that directly simple:
> The directory that
On 31/01/2010 14:15, Sébastien Lorquet wrote:
> Many thanks.
>
> Do I need to file something at http://sourceware.org/bugzilla/ ?
Not for now.
cheers,
DaveK
--
The Planet: dedicated and managed hosting, clo
Many thanks.
Do I need to file something at http://sourceware.org/bugzilla/ ?
Regards
Sebastien
On Sun, Jan 31, 2010 at 1:22 PM, Dave Korn
wrote:
> On 31/01/2010 11:32, Sébastien Lorquet wrote:
>
> > Should I report this to upstream?
>
> You just did :)
>
> > who can handle that?
>
> Looks l
On 31/01/2010 12:54, Pedro Alves wrote:
> On Sunday 31 January 2010 12:32:21, Dave Korn wrote:
>> I don't think it should be necessary to patch the build system, since it's
>> already capable of doing the right thing (which is to create the private
>> header and fixed syslimits), we need to under
On 31/01/2010 12:50, Danny Backx wrote:
> Was it really that hard to wait for confirmation of another solution ?
Err, exactly the same could be said to you about the prematurity of your
patch in the first place; you haven't analyzed the problem and understood what
is going wrong yet. Pedro's a
On Sun, 2010-01-31 at 11:50 +, pedroal...@users.sourceforge.net
wrote:
> Revision: 1440
> http://cegcc.svn.sourceforge.net/cegcc/?rev=1440&view=rev
> Author: pedroalves
> Date: 2010-01-31 11:50:54 + (Sun, 31 Jan 2010)
>
> Log Message:
> ---
> Revert previous change.
On 31/01/2010 10:11, Danny Backx wrote:
> On Sat, 2010-01-30 at 18:58 +, Dave Korn wrote:
>> It goes on to suggest that it might be necessary to define "LIMITS_H_TEST =
>> true" in the t-* makefile frag, so if you guys don't get syslimits.h being
>> generated, maybe that would fix it for you
On Saturday 30 January 2010 17:48:45, Pedro Alves wrote:
> On Saturday 30 January 2010 11:35:45, Danny Backx wrote:
> > So the next best thing appears to just remove it in the
> > scripts/build-mingw32ce.h .
> > I just committed such a fix, can you verify ?
>
> Please don't. Please revert. If t
On Sunday 31 January 2010 12:32:21, Dave Korn wrote:
> I don't think it should be necessary to patch the build system, since it's
> already capable of doing the right thing (which is to create the private
> header and fixed syslimits), we need to understand why it isn't doing that.
>
My guess i
On 31/01/2010 11:32, Sébastien Lorquet wrote:
> Should I report this to upstream?
You just did :)
> who can handle that?
Looks like a job for me. I'll update my cegcc and figure out what's going on.
cheers,
DaveK
---
(previous mail was only sent to Pedro. I include the previous mail, where I
found that the segfault is in ld, not in collect2.
Some progress.
According to the code, the incriminated lines are:
/* Flag that this BFD uses long names, even though the format might
expect them to be o
On Sat, 2010-01-30 at 18:58 +, Dave Korn wrote:
> It goes on to suggest that it might be necessary to define "LIMITS_H_TEST =
> true" in the t-* makefile frag, so if you guys don't get syslimits.h being
> generated, maybe that would fix it for you too?
I must admit I didn't know I could set
28 matches
Mail list logo
