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
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-ming
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 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
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 ne
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 = /in
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 directl
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
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 a
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 31/01/2010 10:11, Danny Backx wrote:
> On Sat, 2010-01-30 at 18:58 +0000, 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
>> genera
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
---
On 30/01/2010 17:52, Pedro Alves wrote:
> There's no reason to copy a dll with debug info to
> the device. You can copy a stripped version, and keep
> the version with debug info in the host.
>
> Of course, if you want to provide a prebuilt dll with
> debug info to users, you can also provide an
On 30/01/2010 17:48, Pedro Alves wrote:
> Doesn't the gcc version include_next the mingw one? Is there
> actually a problem you're seeing?
GCC has its own private version, which is supposed to include a private
fixed version of the system's original header:
http://gcc.gnu.org/ml/gcc/2004-01
On 23/01/2010 16:08, Sean Healy wrote:
> [ ... ] gcc doesn't seem to be
> working. When I run the program, it exits with no error message - no
> message of any kind, in fact - but no output file is produced. So I get
> no output and no error message. [ ... ]
On Cygwin, this is a typical symp
Eric House wrote:
> Actually, as I understand copyright law we *can* use the values from
> the link above. It might be a violation of copyright to
> copy-and-paste from a copyrighted document, but here I'm creating a
> new document using information from another. If MS is claiming the
> values a
Danny Backx wrote:
> On Sun, 2009-12-20 at 10:59 +0100, Vincent R. wrote:
>> On Sun, 20 Dec 2009 08:12:39 +0100, Danny Backx
>> wrote:
>>> On Sat, 2009-12-19 at 08:12 -0800, Eric House wrote:
Is there another way to establish a connection? How do the rest of
you bring up a network conne
Danny Backx wrote:
> On Wed, 2009-12-09 at 15:01 +0000, Dave Korn wrote:
>> Also, what's going on there with the VMA/LMA for .data? It can't possibly
>> really be supposed to be 32 meg below the base address that the DLL gets
>> loaded at!
>
> Considering t
İsmail cartman Dönmez wrote:
> Vincent R. wrote:
>> Could you open a bugzilla and attach your coredll.dll ?
>> Thanks
>>
>
> Danny privately analyzed the file and objdump is correct it seems, so there
> is no bug. Thanks.
Well there's clearly at least a bug in objdump, since it is displaying
gi
İsmail cartman Dönmez wrote:
> The Data Directory
> Entry 0 49dec2e0 0006ea70 Export Directory [.edata (or where ever we found
> it)]
That's 100% bogus. You need to figure out whether that's what's actually in
the binary data in the PE header, put there by ld for some reason, or whether
objdu
Danny Backx wrote:
> I would
> have expected it to report that the symbol I want to look up isn't
> present, because objdump says it has no symbols, but it does find it.
"objdump -t" dumps only the COFF symbol table, that is .obj-file-style
symbols, debug symbols, etc.; what you are looking at
Vincent R. wrote:
>> So Dave, question coundn't we manually change .idata section
>> characteristics for instance instead of disabling auto-import ?
>
>
> Ok I just tried to modify .idata section characteristics by removing write
> attributes and of course now I don't even have an error messag
Vincent R. wrote:
> On Tue, 03 Nov 2009 17:59:20 +0100, Danny Backx
> wrote:
>> On Tue, 2009-11-03 at 14:10 +0100, Vincent R. wrote:
>>> I have been fired (the company I was working for doesn't have money
>>> anymore) so I have some time to answer you ;-)
>> Auch. Sorry to see that.
Welcome t
Vincent R. wrote:
> On Fri, 25 Sep 2009 08:09:26 +0100, Dave Korn
> wrote:
>> Dave Korn wrote:
>>> Vincent R. wrote:
>>>
>>>> For instance I wanted to test Dw2 exception on wince platform and from
>>>> what I know
>>>> normall
Dave Korn wrote:
> Vincent R. wrote:
>
>> For instance I wanted to test Dw2 exception on wince platform and from
>> what I know
>> normally you only need to call configure with --with-dwarf2 and it will
>> define DWARF2_DEBUGGING_INFO but it doesn't work on ceg
Vincent R. wrote:
> For instance I wanted to test Dw2 exception on wince platform and from
> what I know
> normally you only need to call configure with --with-dwarf2 and it will
> define DWARF2_DEBUGGING_INFO but it doesn't work on cegcc.
Nope, --with-dwarf2 sets the default debugging info for
Danny Backx wrote:
> Seriously : I've not looked into objc at all. Does it have porting
> issues like the rest of gcc/g++/libg++ or does it sit quietly on top of
> gcc ?
Generally speaking, it "just works": if C works, ObjC works, and if C++
works, Obj-C++ works. I've never had to patch either
Danny Backx wrote:
> 0x0040106a : movl $0x41f6c160,(%esp)
> 0x00401071 <_fu0___ZSt4cout+4>: call 0x4235c492
> 0x00401099 <__static_initialization_and_destruction_0+28>: call
> 0x4235174a
> 0x0040109e <_fu2___ZNSt8ios_base4InitC1Ev+4>: cmpl $0x0,0x8(%ebp)
So, how do those addre
Danny Backx wrote:
> global constructors keyed to main () at hello.C:8
> 8 }
> Current language: auto; currently c++
> (gdb)
> __static_initialization_and_destruction_0 (__initialize_p=1,
> __priority=65535) at hello.C:8
> 8 }
> (gdb)
> 72static ios_base::Init __ioinit;
> (g
Danny Backx wrote:
> - linker mentions ios_base::Init::Init()
> - crash occurs, says gdb, in ios_base::Init __ioinit;
> - gdbserver occasionally shows the glitch with reading dll names
> (Symbol file not found for li)
> Info: resolving std::cout by linking to __imp___ZSt4cout (auto-import)
> I
Pedro Alves wrote:
> On Monday 18 May 2009 11:56:24, Danny Backx wrote:
>> According to
>> http://fpc.freedoors.org/fpc-2.2.0.source/rtl/win/sysosh.inc
>> the definition should be something like the patch below says.
>>
>> The copyright on this stuff is LGPL so I can take it over.
>
> Huh? How
Danny Backx wrote:
> The C++ library on x86 appears to crash at initialisation even in the
> simplest of programs. At least, it does so when compiled against the DLL
> version of the library.
>
> #include
> using namespace std;
> int main(int argc, char *argv[])
> {
> cout << "Hello" << end
Dave Korn wrote:
> ... so, there was some kind of error from the half-built compiler and
> configure figured that means it can't use "$CC -E" to preprocess. Which begs
> the question "Why", because when I re-run the failing command manually, it
> passes fi
Danny Backx wrote:
> P.S. As I already said (see below) the offending code is in
> src/gcc-4.4.0/libgcc/configure.
> This is what it looks like :
>
> if test -z "$CPP"; then
> if test "${ac_cv_prog_CPP+set}" = set; then
> echo $ECHO_N "(cached) $ECHO_C" >&6
> else
> # Double
Eric House wrote:
> Danny wrote:
>> Could you apply this patch to src/binutils/configure.ac :
>> [...]
>> +AC_CHECK_HEADERS(iconv.h)
>> [...]
>> and then run
>> autoreconf
>> in the src/binutils directory.
>
> eeho...@debian:~/src/cegcc-0.55/src/binutils$ autoreconf
> configure.ac:26: error:
Danny Backx wrote:
> I'm not sure I understand what the cygwin.h code would do :
"If nothing is specified on the command line, or if -static or
-static-libgcc is present, link against the static libgcc. If -shared-libgcc
is explicitly specified, or if building a DLL (-shared) and not explicitly
Johnny Willemsen wrote:
> Hi,
>
> Thanks very much. Danny could you check Vincent patches? Maybe there are
> changes that have to applied also to the gcc 4.1 x86 toolchain.
>
> Johnny
Look at the handling of SHARED_LIBGCC_SPEC and REAL_LIBGCC_SPEC in
particular. There appears to be nothing t
Vincent R. wrote:
> On Tue, 26 May 2009 20:08:10 +0100, Dave Korn
>> I
>> haven't tried to extract any of the functional patches from your tree
> yet,
> Generally here is the patch I am using, maybe you could make a diff.
> When looking very quickly I could not see
eers,
DaveK
2009-05-26 Dave Korn
Merge cegcc and mingw32ce target name changes from CeGCC project.
2008-09-24 Pedro Alves
ld/
* configure.tgt (arm*-*-cegcc*): Set LIB_PATH to
${tooldir}/lib/w32api.
2007-12-25 Pedro Alves
bfd/
* config.bfd: Add arm*-*-cegcc* targ
Vincent R. wrote:
> On Tue, 26 May 2009 15:00:35 +0200, "Vincent R."
> wrote:
>> On Tue, 26 May 2009 14:58:12 +0200, "Vincent R."
>
>>> `/home/Vincent/projects/cegcc/src/scripts/build/w32api/libce'
>>> tail: cannot open `+18' for reading: No such file or directory
>>>
>>> Any idea why ?
>> Hum w
Johnny Willemsen wrote:
> Hi,
>
>>> It seems -Wl,--stack=0x800 works:
>>> SizeOfStackReserve 0800
>>> SizeOfStackCommit 1000
>>> SizeOfHeapReserve 0010
>>> SizeOfHeapCommit1000
>>>
>>> The question is more how this is use
Danny Backx wrote:
> I am not sure whether the compiler/linker influence this.
It is in the hands of the linker.
> Or if they do, then maybe the magic numbers in the exe files cause it,
> and these can usually be influenced.
Yes, the linker handles it by setting the parameters in the PE head
Johnny Willemsen wrote:
> Hi,
>
> It seems -Wl,--stack=0x800 works:
> SizeOfStackReserve 0800
> SizeOfStackCommit 1000
> SizeOfHeapReserve 0010
> SizeOfHeapCommit1000
>
> The question is more how this is used, do we real
Danny Backx wrote:
> On Wed, 2009-05-20 at 17:17 +0100, Dave Korn wrote:
>> I took a quick look at your SVN, you have some simple patches to files like
>> e.g. bfd/config.tgt that add the new target names, and you or someone else
>> who
>> knows the project well woul
Danny Backx wrote:
> On Tue, 2009-05-19 at 14:54 +0100, Dave Korn wrote:
> It seems to have worked.
It does :)
>> The one other thing I did want to know: what's happening about the
>> cegcc-related name changes in upstream configure and binutils? I thought I
>&
Danny Backx wrote:
> Reply to all so the list sees this.
>
> W.r.t. not getting through on the list. I've looked at the list config,
> can't find a reason. I received this message only directly, not via the
> list. I've added your E-mail address to the "explicitly allowed"
> addresses, so maybe it
Vincent R. wrote:
> Hi Dave,
>
>
> Thanks for the information but cegcc doesn't upgrade binutils very often
> and I think we don't use testsuite either (I know it's bad).
>
> By the way you are really on every mailing list and I thought cegcc ML
> would be the last shelter but you found us ;-)
Morning all!
As the subject line: I added a new testcase yesterday to binutils CVS, and
made a dumb blunder by extending it to cover more than just x86 targets
without thinking properly first. Anyone who runs an overnight autotester on
binutils may spot an extra FAIL; please disregard, as
49 matches
Mail list logo
