On Thu, 2009-10-01 at 18:04 +0200, Vincent R. wrote:
> So it's a problem with gettext makefile.
Yeah, these tools are great but they're getting really complicated so
sometimes you spend quite some time looking for something trivial.
Luckily they usually just work ...
Danny
--
Danny Backx
On Thu, 01 Oct 2009 12:57:46 +0200, "Vincent R."
wrote:
> Hi,
>
> I wrote a simple compatibility libarry that implements missing mingw
> functions (_errno, getenv,GetCurrentDirectory, ...)
> and I am using it to port some software and especially glib and its
> dependencies.
> The first dependency
Hi,
I wrote a simple compatibility libarry that implements missing mingw
functions (_errno, getenv,GetCurrentDirectory, ...)
and I am using it to port some software and especially glib and its
dependencies.
The first dependency I am porting is gettext and I got an error when
compiling some C++ cod
This is very valuable input, but I'm not sure that this is the same
problem.
Consider the attached test program. I'm not sure how sensible it is, but
it shows at least two current problems. Its output, with the gcc 4.4
build chain on my disk, is :
pavilion: {233} arm-mingw32ce-gcc -o float-n2.exe
Here is the patchtracker reference :
http://sourceforge.net/tracker/?func=detail&aid=2813569&group_id=2435&atid=302435
and the patch
http://sourceforge.net/tracker/download.php?group_id=2435&atid=302435&file_id=332699&aid=2813569
It will be easier than looking at svn changelog...
--
>> > cegcc-4.4 doesn't seem to make any progress ? Could someone give a
>> > current
>> > status of what is missing/not working ?
>> > I can see that float issues have been patched on mingw project and
>> > reported upstream so maybe cegcc could update
>> > its sources and it might solve at least
On Sat, 2009-07-18 at 20:43 +0200, Johnny Willemsen wrote:
> Hi,
>
> Danny is currently on vacation. Besides the float issue there is the
> iostream exception when using x86 and shared libraries.
>
> Johnny
>
> > cegcc-4.4 doesn't seem to make any progress ? Could someone give a
> > current
> >
Hi,
Danny is currently on vacation. Besides the float issue there is the
iostream exception when using x86 and shared libraries.
Johnny
> cegcc-4.4 doesn't seem to make any progress ? Could someone give a
> current
> status of what is missing/not working ?
> I can see that float issues have been
Hi,
cegcc-4.4 doesn't seem to make any progress ? Could someone give a current
status of what is missing/not working ?
I can see that float issues have been patched on mingw project and
reported upstream so maybe cegcc could update
its sources and it might solve at least the float issue.
Thanks
On Tue, 10 Mar 2009 23:52:36 +0100, "Vincent R."
wrote:
> On Tue, 10 Mar 2009 20:44:27 +0100, "Vincent R."
> wrote:
>> Hi,
>>
>> When trying to compile the following code with cegcc-4.4 I get undefined
>> reference to `__floatdidf' :
>>
>> find__floatdidf.c:
>>
>>
>> #include
>>
>> LONG
On Tue, 10 Mar 2009 20:44:27 +0100, "Vincent R."
wrote:
> Hi,
>
> When trying to compile the following code with cegcc-4.4 I get undefined
> reference to `__floatdidf' :
>
> find__floatdidf.c:
>
>
> #include
>
> LONGLONG _evil_time_freq;
> LONGLONG _evil_time_count;
> long _evil_time
Hi,
When trying to compile the following code with cegcc-4.4 I get undefined
reference to `__floatdidf' :
find__floatdidf.c:
#include
LONGLONG _evil_time_freq;
LONGLONG _evil_time_count;
long _evil_time_second;
double
evil_time_get()
{
LARGE_INTEGER count;
QueryPerformanceCounte
On Wed, 18 Feb 2009 15:12:27 +, Pedro Alves
wrote:
> On Tuesday 17 February 2009 12:11:47, Vincent R. wrote:
>
>> When testing cegcc-4.4 when compiling a lib from EFL
>> libtool: link: arm-mingw32ce-gcc -O3 -pipe -Wl,--enable-auto-import
>> -Wl,-s
>> -o .libs/evil_suite.exe evil_suite.o evil_
On Tuesday 17 February 2009 12:11:47, Vincent R. wrote:
> When testing cegcc-4.4 when compiling a lib from EFL
> libtool: link: arm-mingw32ce-gcc -O3 -pipe -Wl,--enable-auto-import -Wl,-s
> -o .libs/evil_suite.exe evil_suite.o evil_test_dlfcn.o
> evil_test_environment.o evil_test_gettimeofday.o ev
On Tue, 17 Feb 2009 13:11:47 +0100, "Vincent R."
wrote:
> On Tue, 17 Feb 2009 01:22:37 +, Pedro Alves
> wrote:
>> On Monday 16 February 2009 22:55:27, Vincent R. wrote:
>>> I have also noticed that you have hardcoded exception mode in
t-wince-pe
>>> :
>>>
>>> ...
>>> # This should go somewhe
On Tue, 17 Feb 2009 13:15:29 +0100 (CET), Vincent Torri
wrote:
> On Tue, 17 Feb 2009, Vincent R. wrote:
>
>> When testing cegcc-4.4 when compiling a lib from EFL
>> libtool: link: arm-mingw32ce-gcc -O3 -pipe -Wl,--enable-auto-import
>> -Wl,-s
>> -o .libs/evil_suite.exe evil_suite.o evil_test_dlfc
On Tue, 17 Feb 2009, Vincent R. wrote:
> When testing cegcc-4.4 when compiling a lib from EFL
> libtool: link: arm-mingw32ce-gcc -O3 -pipe -Wl,--enable-auto-import -Wl,-s
> -o .libs/evil_suite.exe evil_suite.o evil_test_dlfcn.o
> evil_test_environment.o evil_test_gettimeofday.o evil_test_link.o
On Tue, 17 Feb 2009 01:22:37 +, Pedro Alves
wrote:
> On Monday 16 February 2009 22:55:27, Vincent R. wrote:
>> I have also noticed that you have hardcoded exception mode in t-wince-pe
>> :
>>
>> ...
>> # This should go somewhere else.
>> # We are using SjLj EH.
>> EH_MODEL = sjlj
>>
>>
>> W
On Monday 16 February 2009 22:55:27, Vincent R. wrote:
> I have also noticed that you have hardcoded exception mode in t-wince-pe :
>
> ...
> # This should go somewhere else.
> # We are using SjLj EH.
> EH_MODEL = sjlj
>
>
> Wouldn't be possible to do what I suggest in a previous email and use t
A Monday 16 February 2009 22:55:27, Vincent R. escreveu:
> in mingw32.g/wince-pe.h/wince-cegcc.h, you should replace LIBGCC_SPEC by
> REAL_LIBGCC_SPEC
> because it seems to be the new prefered define.
Thanks, I'll take a look at that.
--
Pedro Alves
-
On Monday 16 February 2009 21:48:20, Vincent R. wrote:
> actually there are some issue with Pedro's patch, I don't know why but
> libstdc++-v3/configure.host
> is not patched :
E, because I changed it?
>
> mingw32ce*)
> os_include_dir="os/mingw32" !! Should be os/mingw32ce
> er
Pedro,
I have also noticed that you have hardcoded exception mode in t-wince-pe :
...
# This should go somewhere else.
# We are using SjLj EH.
EH_MODEL = sjlj
Wouldn't be possible to do what I suggest in a previous email and use the
same logic as mingw ?
> config.gcc:
>
> ...
> + if test
On Mon, 16 Feb 2009 21:56:06 +0100, Danny Backx
wrote:
> I'm getting quite far. No time today though to figure out what's wrong.
> This is, I believe, with just Pedro's stuff, based on gcc-trunk as of a
> couple of hours ago.
>
> Danny
>
> gmake[3]: Entering directory
>
`/home/danny/src/ce
I'm getting quite far. No time today though to figure out what's wrong.
This is, I believe, with just Pedro's stuff, based on gcc-trunk as of a
couple of hours ago.
Danny
gmake[3]: Entering directory
`/home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/build-4.4/gcc/arm-mingw32ce/libst
On Monday 16 February 2009 17:47:09, Vincent R. wrote:
> When I try your patch from cegcc svn I have the following message :
>
> make AS="arm-mingw32ce-as" CC="gcc" CFLAGS="-O2 -g " CXXFLAGS="@CXXFLAGS@
^^^
Wrong gcc here. Hmmm, did I forget that w32api does n
When I try your patch from cegcc svn I have the following message :
make AS="arm-mingw32ce-as" CC="gcc" CFLAGS="-O2 -g " CXXFLAGS="@CXXFLAGS@
" CPPFLAGS=" " AR="arm-mingw32ce-ar" RANLIB="arm-mingw32ce-ranlib"
LD="arm-mingw32ce-ld" DLLTOOL="arm-mingw32ce-dlltool"
exec_prefix="/opt/mingw32ce-4.4.
Uurgh, I totally missed this message before posting the other one...
I've posted an updated patch against trunk at cegcc-de...@. It should
fix the alignment issue. ".align FOO" on ARM coff works like on elf, that
is, FOO is power 2 aligment... I've also fixed a couple of __dllimport
issues on A
On Tuesday 03 February 2009 19:55:36, Vincent R. wrote:
> 2) I made a patch for mingw to use static crt, it will be consistent with
> future cegcc-4.4
> and with mingw-w64. Now I need people to test it and if it works fine we
> could apply it to
> current svn.
Sorry, but I don't like this patch --
On Wed, 2009-02-04 at 22:16 +, Pedro Alves wrote:
> On Wednesday 04 February 2009 20:55:28, Danny Backx wrote:
> > The next thing to fail is mingw. I'm not sure whether I want to invest
> > in that given your remarks on mingw-w64. Is your experience that it can
> > replace the src/mingw in the
On Wednesday 04 February 2009 20:55:28, Danny Backx wrote:
> We have the same goal.
>
> But if nobody assembles the bits and pieces and turns them into
> something that's ready to use, then acceptance and use will be lower
> than they could be.
True.
>
> In the past, a lot of effort has gone i
We have the same goal.
But if nobody assembles the bits and pieces and turns them into
something that's ready to use, then acceptance and use will be lower
than they could be.
In the past, a lot of effort has gone into getting stuff to work. The
time this took has made us lag behind gcc/binutils/
On Wednesday 04 February 2009 18:55:32, Vincent R. wrote:
> This is my last contribution to cegcc project, it should allow you to
> generate a cross-compiler
> using the upcoming gcc-4.4. You will find instructions in the
> HOWTO-cegcc-4.4.txt.
Thanks, I'll take a look.
> Unfortunately, I don't
Hi,
Pedro, Danny,
This is my last contribution to cegcc project, it should allow you to
generate a cross-compiler
using the upcoming gcc-4.4. You will find instructions in the
HOWTO-cegcc-4.4.txt.
Unfortunately, I don't think it's a good thing to have a separate project
from gcc because
it add a
On Tue, 03 Feb 2009 20:28:50 +0100, Danny Backx
wrote:
> This one message has answers to questions/remarks from several mails.
>
> On Tue, 2009-02-03 at 14:42 +0100, Vincent R. wrote:
>> I feel a bit alone so Pedro if could take some time to give your opinion
>> it
>> would be great.
>
> That's
This one message has answers to questions/remarks from several mails.
On Tue, 2009-02-03 at 14:42 +0100, Vincent R. wrote:
> I feel a bit alone so Pedro if could take some time to give your opinion it
> would be great.
That's why I really want to put this in a public spot. Others will work
on/wit
I am progressing, I have found why Dll addresses were not good, actually I
started
from i386/mingw32.h and forget to remove the --enable-auto-image-base.
It seems this option is not compatible with our arm architecture ...
I will post a new patch very soon.
On Tue, 03 Feb 2009 09:41:04 +0100, "
Hi Vincent,
On Tue, 3 Feb 2009 00:26:55 +0100 (CET), Vincent Torri
wrote:
> On Mon, 2 Feb 2009, Danny Backx wrote:
>
>> I'm inclined to put this work (based on the current gcc from their svn)
>> in our repository.
>>
>> Upgrading to 4.4.0 once it's out shouldn't be hard.
>>
>> Does anyone have i
On Mon, 2 Feb 2009, Danny Backx wrote:
> I'm inclined to put this work (based on the current gcc from their svn)
> in our repository.
>
> Upgrading to 4.4.0 once it's out shouldn't be hard.
>
> Does anyone have ideas (objections or hurrays) about that ?
going to 4.4.0 would be nice. Just some r
I'm inclined to put this work (based on the current gcc from their svn)
in our repository.
Upgrading to 4.4.0 once it's out shouldn't be hard.
Does anyone have ideas (objections or hurrays) about that ?
Danny
On Mon, 2009-02-02 at 22:32 +0100, Vincent R. wrote:
> On Mon, 02 Feb 2009
I'm not making any promises, as I said I am a bit short on time right
now.
But what are the things we want ?
- gcc 4.4.x -> is it stable enough yet ?
- binutils 2.19 ?
Danny
On Sun, 2009-02-01 at 21:00 +0100, Vincent R. wrote:
> I already tried so many things that now I don't think I wil
On Sun, 01 Feb 2009 20:12:40 +0100, Danny Backx
wrote:
> That's not a real problem, it's just configuration :-)
>
> You'll need to learn about the gcc configuration. All that kind of stuff
> is fully configurable in the gcc sources.
>
> There's a (complicated) set of sources and include files th
That's not a real problem, it's just configuration :-)
You'll need to learn about the gcc configuration. All that kind of stuff
is fully configurable in the gcc sources.
There's a (complicated) set of sources and include files that are vital
for you to understand if you're working on this. Look i
On Fri, 2009-01-30 at 14:43 +0100, Vincent R. wrote:
> I also tried to generate a cegcc-4.4.0 but unfortuantely it DOESN'T WORK
> because it seems
> there is an issue with crtstuff. Indeed binaries starts at wrong virtual
> address !!!
I've not tried your patch yet (other urgent things to do this
43 matches
Mail list logo
