From: <dan...@us...> - 2007-05-17 22:02:48
|
GCC 4.2.0 has been released. What would mingw users like for a binary release package? (1) Based on pristine (well, just a few makefile.in tweaks to get around CRLF, no-symlinks, etc issues) FSF sources, as is, with known bugs. (2) As above but backporting select features from 4.3.0, fixing some aforementioned known bugs. (3) As (2) but enabling DW2 unwind. (4) As (2) but building libstdc++ and libgcc as dll's. (5) (3) | (4). (6) Your "I'd rather...". (5) has receieved the most testing on my machine. Danny |
From: Samuel T. <sam...@en...> - 2007-05-17 22:12:10
|
Hi, dannysmith, le Fri 18 May 2007 10:02:39 +1200, a écrit : > (well, just a few makefile.in tweaks to get around CRLF, no-symlinks, > etc issues) Couldn't these be commited upstream? Samuel |
From: Michael G. <mg...@te...> - 2007-05-17 23:22:42
|
> What would mingw users like for a binary release package? >=20 > (1) Based on pristine (well, just a few makefile.in tweaks to get around > CRLF, no-symlinks, etc issues) FSF sources, as is, with known bugs. > (2) As above but backporting select features from 4.3.0, fixing some > aforementioned known bugs. > (3) As (2) but enabling DW2 unwind. > (4) As (2) but building libstdc++ and libgcc as dll's. > (5) (3) | (4). > (6) Your "I'd rather...". >=20 >=20 > (5) has receieved the most testing on my machine.=20 I'd definitely prefer (5). Best, Michael =2D-=20 Technosis GmbH, Gesch=E4ftsf=FChrer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Eric W. <ewe...@cs...> - 2007-05-17 23:22:42
|
> -----Original Message----- > From: min...@li... > [mailto:min...@li...] On Behalf > Of dan...@us... > Sent: Thursday, May 17, 2007 4:03 PM > To: min...@li... > Subject: [Mingw-users] GCC 4.2.0 > > GCC 4.2.0 has been released. > > (5) has receieved the most testing on my machine. Assuming the above, what would be the ballpark timeframe for a release? Thanks Eric Weddington |
From: Brendon C. <bc...@av...> - 2007-05-17 23:44:05
|
I would prefer 5 also. dan...@us... wrote: > GCC 4.2.0 has been released. > > What would mingw users like for a binary release package? > > (1) Based on pristine (well, just a few makefile.in tweaks to get around > CRLF, no-symlinks, etc issues) FSF sources, as is, with known bugs. > (2) As above but backporting select features from 4.3.0, fixing some > aforementioned known bugs. > (3) As (2) but enabling DW2 unwind. > (4) As (2) but building libstdc++ and libgcc as dll's. > (5) (3) | (4). > (6) Your "I'd rather...". > > > (5) has receieved the most testing on my machine. > > Danny > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > > |
From: Greg C. <chi...@co...> - 2007-05-18 00:03:51
|
On 2007-05-17 22:02Z, dan...@us... wrote: > GCC 4.2.0 has been released. > > What would mingw users like for a binary release package? Is throwing and catching C++ exceptions across dll boundaries part of any of the options listed below? > (1) Based on pristine (well, just a few makefile.in tweaks to get around > CRLF, no-symlinks, etc issues) FSF sources, as is, with known bugs. > (2) As above but backporting select features from 4.3.0, fixing some > aforementioned known bugs. > (3) As (2) but enabling DW2 unwind. > (4) As (2) but building libstdc++ and libgcc as dll's. > (5) (3) | (4). Is "|" like C's bitwise OR applied to bitmasks, meaning the union of two things; or is it an either-or choice between two mutually exclusive features, perhaps implying a (3) binary and a (4) binary separately (as with separate DW2 builds in the past)? > (6) Your "I'd rather...". > > > (5) has receieved the most testing on my machine. Well, whatever you upload, I'll test, and report my results. Thanks. |
From: Charles W. <cwi...@us...> - 2007-05-18 04:00:54
|
dannysmith-g wrote: > GCC 4.2.0 has been released. > > What would mingw users like for a binary release package? > > (1) Based on pristine (well, just a few makefile.in tweaks to get around > CRLF, no-symlinks, etc issues) FSF sources, as is, with known bugs. I'm going to go out on a limb and say "1". It has been three entire /long/ development cycles -- to 4.0, to 4.1, and now to 4.2 -- since mingw had a "current" version of gcc; I don't think any of us want to see that kind of lag-behind happen again. But one way to guarantee that it WILL happen is to have "our" version be wildly divergent from the official releases: because then we keep bugfixing out on our limb, and then we get: .."it's just too hard/too big to submit these changes" .."ah, 4.2.x isn't maintained anymore, they're working on 4.5.x" .."I didn't write /that/ part so I can't submit it" .."Well, we can't release 4.3.x because it doesn't have all these custom mingw bugfixes" Hence: we drift away, and are stuck with 4.2.x for years and people start peppering the list with "when are you going to release 4.5.0?" So we get to re-experience the current pain all over again for gcc-4.7.0. No, option (1) is better. And yes, the tweaks should be submitted for 4.2.1+. And THEN, we can start backporting select features from 4.3.x -- but only those that would be candidates for submission to the official 4.2.x branch. And then we /should/ submit those also to 4.2.[1+] In Chuck's world, the *only* exception to the preceeding rules would be the shared libgcc stuff: because that's the recommended (only?) road to getting exceptions-across-dll-boundaries working for both C++ and java post 3.4.x. If people want spiffy new features (along with spiffy new bugfixes AND spiffy new /bugs/) then maybe an EXPR-gcc-4.3.0 release would be a better testbed for /that/, with all the dw2 and shared libgcc bells ad whistles. Besides, gcc trunk will have modern, mingw/cygwin-friendly libtool support before long <g>. > (2) As above but backporting select features from 4.3.0, fixing some > aforementioned known bugs. > (3) As (2) but enabling DW2 unwind. > (4) As (2) but building libstdc++ and libgcc as dll's. > (5) (3) | (4). Just a side note: even though DW2 unwind is faster, better, and more widely used (and thus more widely tested) than sjlj, IMO mingw should still supply a sjlj compiler, at least as an alternate download -- until the foreign frame problem is solved: http://gcc.gnu.org/wiki/WindowsGCCImprovements "DW2 EH is supported for Windows, but someone needs to implement the part that makes it possible for GUI callbacks to throw exceptions that can be caught in the main event loop, i.e. make exception-propagation work through "foreign" call frames in the stack. If I understand correctly, ^^^ is predicated on having shared libgcc -- hence the exception-to-the-rule in Chuck's world. For my own use, I'd *love* (5) -- but I'm deathly afraid that we'd just be ASKING for trouble down the road if, once again, the official mingw compiler version "x.y.z" deviates so significantly from the official GNU compiler version "x.y.z". I can deal with a slightly less capable 4.2.x on mingw -- and simply wait another six months or so for 4.3.0, in which all these spiffy new things will be integrated into the official GNU release (we all hope -- since we'll all be working feverishly on gcc trunk rather than haring off on our own kinda-looks-like-gcc-4.2.x-but-man-it-is-WAY-different). And, for mission critical stuff, 3.4.5 isn't going anywhere. -- Chuck |
From: Zuxy M. <zux...@gm...> - 2007-05-18 06:43:17
|
<dan...@us...> ??????:000001c798cf$18413f90$b44861cb@anykey... > GCC 4.2.0 has been released. > > What would mingw users like for a binary release package? > > (1) Based on pristine (well, just a few makefile.in tweaks to get around > CRLF, no-symlinks, etc issues) FSF sources, as is, with known bugs. > (2) As above but backporting select features from 4.3.0, fixing some > aforementioned known bugs. > (3) As (2) but enabling DW2 unwind. > (4) As (2) but building libstdc++ and libgcc as dll's. > (5) (3) | (4). > (6) Your "I'd rather...". > > > (5) has receieved the most testing on my machine. Does (4) imply that every app mingw32 build (regardless whether the source is in C, C++, or FORTRAN) now must be shipped with a libgcc.dll? How much is the code size incease if we continue to use the static libgcc? -- Zuxy |
From: David L. <yak...@ya...> - 2007-05-18 07:34:57
|
--- dan...@us... escribió: > GCC 4.2.0 has been released. > > What would mingw users like for a binary release package? > > (1) Based on pristine (well, just a few makefile.in tweaks to get around > CRLF, no-symlinks, etc issues) FSF sources, as is, with known bugs. > (2) As above but backporting select features from 4.3.0, fixing some > aforementioned known bugs. > (3) As (2) but enabling DW2 unwind. > (4) As (2) but building libstdc++ and libgcc as dll's. > (5) (3) | (4). > (6) Your "I'd rather...". > > > (5) has receieved the most testing on my machine. > > Danny > Well, I would like something just simple. That it WORKS on vista 64 8). Regards. __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.yahoo.es |
From: Jonathan W. <jf...@tp...> - 2007-05-18 09:05:39
|
My vote is (5) with the people who are actually doing windows specific patches and development making more effort to get the patches into FSF sources than has happened in the past. The less lines of code that MingW has outside of FSF sources the better IMO (and this opinion applies to Binutils, GDB and the other projects MingW produces too) Is the problem on the GCC side? (i.e. GCC people refusing to accept certain MingW patches or not wanting to do the work required to get the patches into FSF sources) Or is it on the MingW side? (i.e. MingW people not wanting to do the work required on their end to get the patches into FSF source, not wanting to get a copyright assignment or wanting to do the work "the right way" before submitting to GCC) |
From: David L. <yak...@ya...> - 2007-05-18 15:17:38
|
I finally surrender and copied gcc.exe and collect2.exe from Danny Smith found wherever in some post. After overwriting tried to build again wxWidgets. Now cc1.exe is found, but stdio.h don't. It seems that cc1.exe does not tries to find it in /mingw/include directory, but in wxWidgets include's, and of course, fails. Is this another vista issue? wxBuilds is told to need mingw32-make be run in a cmd.exe command prompt, not msys console with msys make.exe. Is there any environment variable where to tell gcc where to look for the includes/libraries? gcc --print-search-paths does not show any include directory. Since got vista I feel like I am losing my time, but have to choose either losing my time/patience, or losing my money (vista was not cheap). Help would be appreciated. Thanks in advance. ____________________________________________________________________________________ ¡Descubre una nueva forma de obtener respuestas a tus preguntas! Entra en Yahoo! Respuestas. http://es.answers.yahoo.com/info/welcome |
From: Keith M. <kei...@us...> - 2007-05-19 19:56:28
|
In reply to a message, with the original subject `GCC 4.2.0' On Friday 18 May 2007 16:17, David Lucena wrote: [... content snipped ...] David, I notice that you have introduced a new topic by replying to an unrelated message, so hi-jacking the original topic thread. Please, DO NOT DO THIS AGAIN. If you want to start a new topic, then start a new thread. Thank you. Keith. |
From: Zhong L. <zl...@ho...> - 2007-05-21 14:36:58
Attachments:
Makefile.orig
Makefile
|
Dear MinGW experts, I am new to MinGW and found this email list while looking for help on using MinGW to compile a linux program into a window executable. Thanks to Mr. Jean-Sébastien Pédron's excellent instructions (http://www.dumbbell.fr/howto/win32-cross-compilation.en.html), I was able to build a mingw32 cross-compiler on Linux. Although I was able to generate those two helloworld examples, I immediately hit a wall when trying to compile my own program. I have attached two files with this message. I will greatly appreciate if you can take a look and give me some guidance. The first file "Makefile.orig" is the original make file. The second file "Makefile" is the one I modified by changing the gcc compiler (line 4) and the name of one of the final programs "eigenstrat" (line 33). When executing the orignal make file, all code were successfully compiled with the output shown below: mkdir -p /home/zli/ThirdParty/Eigensoft/src/smartlib mkdir -p /home/zli/ThirdParty/Eigensoft/src/smarttables mkdir -p /home/zli/ThirdParty/Eigensoft/src/smartinclude mkdir -p /home/zli/ThirdParty/Eigensoft/src/bin cp twtable /home/zli/ThirdParty/Eigensoft/src/smarttables cp nicksrc/*.h /home/zli/ThirdParty/Eigensoft/src/smartinclude cc -c -O -I/home/zli/ThirdParty/Eigensoft/src/smartinclude -Wimplicit -c -o strsubs.o nicksrc/strsubs.c cc -c -O -I/home/zli/ThirdParty/Eigensoft/src/smartinclude -Wimplicit -c -o sortit.o nicksrc/sortit.c cc -c -O -I/home/zli/ThirdParty/Eigensoft/src/smartinclude -Wimplicit -c -o vsubs.o nicksrc/vsubs.c cc -c -O -I/home/zli/ThirdParty/Eigensoft/src/smartinclude -Wimplicit -DTWTAB=\"/home/zli/ThirdParty/Eigensoft/src/smarttables/twtable\" -o statsubs.o nicksrc/statsubs.c cc -c -O -I/home/zli/ThirdParty/Eigensoft/src/smartinclude -Wimplicit -c -o linsubs.o nicksrc/linsubs.c cc -c -O -I/home/zli/ThirdParty/Eigensoft/src/smartinclude -Wimplicit -c -o getpars.o nicksrc/getpars.c cc -c -O -I/home/zli/ThirdParty/Eigensoft/src/smartinclude -Wimplicit -c -o xsearch.o nicksrc/xsearch.c cc -c -O -I/home/zli/ThirdParty/Eigensoft/src/smartinclude -Wimplicit -c -o gauss.o nicksrc/gauss.c cc -c -O -I/home/zli/ThirdParty/Eigensoft/src/smartinclude -Wimplicit -c -o gds.o nicksrc/gds.c ar -r libnick.a strsubs.o sortit.o vsubs.o statsubs.o linsubs.o getpars.o xsearch.o gauss.o gds.o ar: creating libnick.a cp libnick.a /home/zli/ThirdParty/Eigensoft/src/smartlib/nicklib.a cc -c -O -I/home/zli/ThirdParty/Eigensoft/src/smartinclude -Wimplicit -c -o eigenstrat.o eigenstrat.c gcc -O -I/home/zli/ThirdParty/Eigensoft/src/smartinclude -g -pg -lm -o eigenstrat eigenstrat.o /home/zli/ThirdParty/Eigensoft/src/smartlib/nicklib.a -Wimplicit However when executing my own make file, I got the following error: mkdir -p /home/zli/ThirdParty/Eigensoft/src/smartlib mkdir -p /home/zli/ThirdParty/Eigensoft/src/smarttables mkdir -p /home/zli/ThirdParty/Eigensoft/src/smartinclude mkdir -p /home/zli/ThirdParty/Eigensoft/src/bin cp twtable /home/zli/ThirdParty/Eigensoft/src/smarttables cp nicksrc/*.h /home/zli/ThirdParty/Eigensoft/src/smartinclude i386-linux-mingw32-gcc -c -O -I/home/zli/ThirdParty/Eigensoft/src/smartinclude -Wimplicit -c -o strsubs.o nicksrc/strsubs.c nicksrc/strsubs.c:6:23: sys/times.h: No such file or directory nicksrc/strsubs.c: In function `seednum': nicksrc/strsubs.c:189: error: storage size of 'tbuff' isn't known nicksrc/strsubs.c:192: warning: implicit declaration of function `getuid' nicksrc/strsubs.c:193: warning: implicit declaration of function `times' make: *** [strsubs.o] Error 1 It seems that some header files are missing. Does it mean that I need to include some window header files instead? I am also wondering if I need to change the make file further since it first generates a bunch of .o files, on which I don't know whether they should be .exe in window (I doubt it). I apologize for this unsolicited long message. I did post it at source forge but had yet to receive a response. Thank you very much in advance! Zhong Li Original Makefile: HOMEL=$(PWD) DEBUG_OPTIONS= -g -pg BIN=$(HOMEL)/bin # "make eigenstrat" to make eigenstrat program (ditto for other programs) # "mv eigenstrat ../bin" (or "make install" to copy all C programs to ../bin) # "make clean" to clean up extra files in this directory # "make clobber" to clobber all files and subdirectories except source files # so as to enable recompiling from scratch. NLIB=$(HOMEL)/smartlib/nicklib.a IDIR=$(HOMEL)/smartinclude VPATH=.:nicksrc BLAS = blas-3 # may need to change to BLAS = blas (depends on blas/lapack installation) CFLAGS= -c -O -I$(IDIR) -Wimplicit OBJ=strsubs.o sortit.o vsubs.o statsubs.o linsubs.o getpars.o xsearch.o gauss.o gds.o TWTAB=\"$(HOMEL)/smarttables/twtable\" statsubs.o: nicksrc/statsubs.c $(CC) $(CFLAGS) -DTWTAB=$(TWTAB) -o statsubs.o nicksrc/statsubs.c M1=smartpca M1O=smartpca.o twsubs.o mcio.o admutils.o egsubs.o eigsubs.o eigx.o M2=convertf M2O=convertf.o mcio.o admutils.o M3=twstats M3O=twstats.o M4=eigenstrat M4O=eigenstrat.o M5=eigenstratQTL M5O=eigenstratQTL.o M6=pca M6O=pca.o eigsubs.o eigx.o PROGS= smartpca convertf twstats eigenstrat eigenstratQTL pca all: nicklib $(PROGS) install: all cp $(PROGS) $(HOMEL)/bin uninstall: rm -f $(BIN)/smartpca rm -f $(BIN)/convertf rm -f $(BIN)/twstats rm -f $(BIN)/eigenstrat rm -f $(BIN)/eigenstratQTL rm -f $(BIN)/pca rm -f $(NLIB)/libnick.a $(M1): nicklib $(M1O) gcc -O -I$(IDIR) $(DEBUG_OPTIONS) -o $(M1) $(M1O) $(NLIB) -lm -llapack -l$(BLAS) -lf2c -Wimplicit $(M2): nicklib $(M2O) gcc -O -I$(IDIR) $(DEBUG_OPTIONS) -lm -o $(M2) $(M2O) $(NLIB) -Wimplicit $(M3): nicklib $(M3O) gcc -O -I$(IDIR) $(DEBUG_OPTIONS) -lm -o $(M3) $(M3O) $(NLIB) -Wimplicit $(M4): nicklib $(M4O) gcc -O -I$(IDIR) $(DEBUG_OPTIONS) -lm -o $(M4) $(M4O) $(NLIB) -Wimplicit $(M5): nicklib $(M5O) gcc -O -I$(IDIR) $(DEBUG_OPTIONS) -lm -o $(M5) $(M5O) $(NLIB) -Wimplicit $(M6): nicklib $(M6O) gcc -O -I$(IDIR) $(DEBUG_OPTIONS) -o $(M6) $(M6O) $(NLIB) -lm -llapack -l$(BLAS) -lf2c -Wimplicit libnick.a: dirs $(OBJ) ar -r libnick.a $(OBJ) nicklib: dirs libnick.a cp libnick.a $(NLIB) dirs: mkdir -p $(HOMEL)/smartlib mkdir -p $(HOMEL)/smarttables mkdir -p $(HOMEL)/smartinclude mkdir -p $(BIN) cp twtable $(HOMEL)/smarttables cp nicksrc/*.h $(IDIR) clean: rm -f *.o rm -f core rm -f libnick.a rm -f $(PROGS) clobber: clean rmdirs uninstall rmdirs: rm -rf $(HOMEL)/smartlib rm -rf $(HOMEL)/smarttables rm -rf $(HOMEL)/smartinclude Modified Makefile fo minGW: HOMEL=$(PWD) DEBUG_OPTIONS= -g -pg BIN=$(HOMEL)/bin CC=i386-linux-mingw32-gcc # "make eigenstrat" to make eigenstrat program (ditto for other programs) # "mv eigenstrat ../bin" (or "make install" to copy all C programs to ../bin) # "make clean" to clean up extra files in this directory # "make clobber" to clobber all files and subdirectories except source files # so as to enable recompiling from scratch. NLIB=$(HOMEL)/smartlib/nicklib.a IDIR=$(HOMEL)/smartinclude VPATH=.:nicksrc BLAS = blas-3 # may need to change to BLAS = blas (depends on blas/lapack installation) CFLAGS= -c -O -I$(IDIR) -Wimplicit OBJ=strsubs.o sortit.o vsubs.o statsubs.o linsubs.o getpars.o xsearch.o gauss.o gds.o TWTAB=\"$(HOMEL)/smarttables/twtable\" statsubs.o: nicksrc/statsubs.c $(CC) $(CFLAGS) -DTWTAB=$(TWTAB) -o statsubs.o nicksrc/statsubs.c M1=smartpca M1O=smartpca.o twsubs.o mcio.o admutils.o egsubs.o eigsubs.o eigx.o M2=convertf M2O=convertf.o mcio.o admutils.o M3=twstats M3O=twstats.o M4=eigenstrat.exe M4O=eigenstrat.o M5=eigenstratQTL M5O=eigenstratQTL.o M6=pca M6O=pca.o eigsubs.o eigx.o PROGS= smartpca convertf twstats eigenstrat eigenstratQTL pca all: nicklib $(PROGS) install: all cp $(PROGS) $(HOMEL)/bin uninstall: rm -f $(BIN)/smartpca rm -f $(BIN)/convertf rm -f $(BIN)/twstats rm -f $(BIN)/eigenstrat rm -f $(BIN)/eigenstratQTL rm -f $(BIN)/pca rm -f $(NLIB)/libnick.a $(M1): nicklib $(M1O) gcc -O -I$(IDIR) $(DEBUG_OPTIONS) -o $(M1) $(M1O) $(NLIB) -lm -llapack -l$(BLAS) -lf2c -Wimplicit $(M2): nicklib $(M2O) gcc -O -I$(IDIR) $(DEBUG_OPTIONS) -lm -o $(M2) $(M2O) $(NLIB) -Wimplicit $(M3): nicklib $(M3O) gcc -O -I$(IDIR) $(DEBUG_OPTIONS) -lm -o $(M3) $(M3O) $(NLIB) -Wimplicit $(M4): nicklib $(M4O) gcc -O -I$(IDIR) $(DEBUG_OPTIONS) -lm -o $(M4) $(M4O) $(NLIB) -Wimplicit $(M5): nicklib $(M5O) gcc -O -I$(IDIR) $(DEBUG_OPTIONS) -lm -o $(M5) $(M5O) $(NLIB) -Wimplicit $(M6): nicklib $(M6O) gcc -O -I$(IDIR) $(DEBUG_OPTIONS) -o $(M6) $(M6O) $(NLIB) -lm -llapack -l$(BLAS) -lf2c -Wimplicit libnick.a: dirs $(OBJ) ar -r libnick.a $(OBJ) nicklib: dirs libnick.a cp libnick.a $(NLIB) dirs: mkdir -p $(HOMEL)/smartlib mkdir -p $(HOMEL)/smarttables mkdir -p $(HOMEL)/smartinclude mkdir -p $(BIN) cp twtable $(HOMEL)/smarttables cp nicksrc/*.h $(IDIR) clean: rm -f *.o rm -f core rm -f libnick.a rm -f $(PROGS) clobber: clean rmdirs uninstall rmdirs: rm -rf $(HOMEL)/smartlib rm -rf $(HOMEL)/smarttables rm -rf $(HOMEL)/smartinclude |
From: Michael G. <mg...@te...> - 2007-05-21 15:02:12
|
Dear Zhong Li, > Thanks to Mr. Jean-S=C3=A9bastien P=C3=A9dron's excellent instructions=20 > (http://www.dumbbell.fr/howto/win32-cross-compilation.en.html), I was abl= e=20 > to build a mingw32 cross-compiler on Linux. I strongly suggest you use our scripts to create your xcompiler. https://sourceforge.net/project/showfiles.php?group_id=3D2435&package_id=3D= 82724&release_id=3D461967 [I'm aware this isn't too easy to find...] While your above instructions may create a working xcompiler we can't support other persons scripts especially since we provide our own set of scripts that many of us use on a daily basis. [long problem description deleted] Best way to actually get someone to look at your problem is to reduce it as much as possible. Apart from creating a minimal source file showing the problem you should also try to reproduce the problem by issuing the offending command from a shell alone. That way you (and we) can easiest rule out other influences from using other tools. Best, Michael =2D-=20 Technosis GmbH, Gesch=C3=A4ftsf=C3=BChrer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Keith M. <kei...@to...> - 2007-05-21 15:31:48
|
Zhong Li wrote: > I am new to MinGW and found this email list while looking for help on= > using MinGW to compile a linux program into a window executable. > > Thanks to Mr. Jean-S=E9bastien P=E9dron's excellent instructions > (http://www.dumbbell.fr/howto/win32-cross-compilation.en.html), I was= > able to build a mingw32 cross-compiler on Linux. I'm not familiar with those particular instructions. We do provide our= own set of user friendly build scripts, for building a Linux-x-MinGW cross compiler: https://sourceforge.net/project/showfiles.php?group_id=3D2435&package_i= d=3D82724&release_id=3D461967 but let's assume that the one you've built works just as well. (Since you can successfully build a `hello world' example, we know at least that the fundamentals work). > Although I was able to generate those two helloworld examples, I > immediately hit a wall when trying to compile my own program. I have > attached two files with this message. I will greatly appreciate if yo= u > can take a look and give me some guidance. > > The first file "Makefile.orig" is the original make file. The second > file "Makefile" is the one I modified by changing the gcc compiler > (line 4) and the name of one of the final programs "eigenstrat" (line= > 33). When executing the orignal make file, all code were successfull= y > compiled with the output shown below: [... output snipped ...] This is to be expected; you've taken a working program, written for Linux, so naturally it builds natively there. > However when executing my own make file, I got the following error: > > [...] > > i386-linux-mingw32-gcc -c -O \ > -I/home/zli/ThirdParty/Eigensoft/src/smartinclude \ > -Wimplicit -c -o strsubs.o nicksrc/strsubs.c > nicksrc/strsubs.c:6:23: sys/times.h: No such file or directory This is your first clue to the problem. It isn't that your Makefile is= flawed, for that command appears fine. The problem is that the API whi= ch is described by the `sys/times.h' header is not supported directly in Woe32, so the header simply is not provided with the cross-compiler. This isn't a problem with the compiler either; it simply means that you= must modify the program source code, either removing that API dependent= functionality entirely, or reimplementing it using suitable Woe32 APIs.= > nicksrc/strsubs.c: In function `seednum': > nicksrc/strsubs.c:189: error: storage size of 'tbuff' isn't known > nicksrc/strsubs.c:192: warning: implicit declaration of function `get= uid' > nicksrc/strsubs.c:193: warning: implicit declaration of function `tim= es' > make: *** [strsubs.o] Error 1 And these functions also require API adaptation to the Woe32 world. > It seems that some header files are missing. Deliberately so. > Does it mean that I need to include some window header files instead?= Possibly. You will also need to rewrite portions of the source code. > I am also wondering if I need to change the make file further since i= t > first generates a bunch of .o files, This is normal. > on which I don't know whether they should be .exe in window (I doubt = it). No; they are the intermediate object files, which will eventually be li= nked together, to create the `.exe'. BTW, I must echo Michael Gerdau's comment about reducing a fault log to= the minimum required to reproduce the problem: > Best way to actually get someone to look at your problem is to > reduce it as much as possible. Apart from creating a minimal source > file showing the problem you should also try to reproduce the problem= > by issuing the offending command from a shell alone. In this case, only those snippets I've reproduced above are necessary t= o identify the probable cause of your problem; the remainder was nothing = more than confusing noise. A *small* example of a self contained source fil= e, just sufficient to reproduce the problem would also have been helpful. Regards, Keith. = |
From: Zhong L. <zl...@ho...> - 2007-05-21 16:09:16
|
Thank you very much, Mr. Marshall and Mr. Gerdau, for your immediate responses to my question. I will follow your comments and see how far I can go. Best, Zhong ----- Original Message ----- From: "Keith MARSHALL" <kei...@to...> To: "MinGW Users List" <min...@li...> Sent: Monday, May 21, 2007 11:29 AM Subject: Re: [Mingw-users] stdio.h not found Zhong Li wrote: > I am new to MinGW and found this email list while looking for help on > using MinGW to compile a linux program into a window executable. > > Thanks to Mr. Jean-Sébastien Pédron's excellent instructions > (http://www.dumbbell.fr/howto/win32-cross-compilation.en.html), I was > able to build a mingw32 cross-compiler on Linux. I'm not familiar with those particular instructions. We do provide our own set of user friendly build scripts, for building a Linux-x-MinGW cross compiler: https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82724&release_id=461967 but let's assume that the one you've built works just as well. (Since you can successfully build a `hello world' example, we know at least that the fundamentals work). > Although I was able to generate those two helloworld examples, I > immediately hit a wall when trying to compile my own program. I have > attached two files with this message. I will greatly appreciate if you > can take a look and give me some guidance. > > The first file "Makefile.orig" is the original make file. The second > file "Makefile" is the one I modified by changing the gcc compiler > (line 4) and the name of one of the final programs "eigenstrat" (line > 33). When executing the orignal make file, all code were successfully > compiled with the output shown below: [... output snipped ...] This is to be expected; you've taken a working program, written for Linux, so naturally it builds natively there. > However when executing my own make file, I got the following error: > > [...] > > i386-linux-mingw32-gcc -c -O \ > -I/home/zli/ThirdParty/Eigensoft/src/smartinclude \ > -Wimplicit -c -o strsubs.o nicksrc/strsubs.c > nicksrc/strsubs.c:6:23: sys/times.h: No such file or directory This is your first clue to the problem. It isn't that your Makefile is flawed, for that command appears fine. The problem is that the API which is described by the `sys/times.h' header is not supported directly in Woe32, so the header simply is not provided with the cross-compiler. This isn't a problem with the compiler either; it simply means that you must modify the program source code, either removing that API dependent functionality entirely, or reimplementing it using suitable Woe32 APIs. > nicksrc/strsubs.c: In function `seednum': > nicksrc/strsubs.c:189: error: storage size of 'tbuff' isn't known > nicksrc/strsubs.c:192: warning: implicit declaration of function `getuid' > nicksrc/strsubs.c:193: warning: implicit declaration of function `times' > make: *** [strsubs.o] Error 1 And these functions also require API adaptation to the Woe32 world. > It seems that some header files are missing. Deliberately so. > Does it mean that I need to include some window header files instead? Possibly. You will also need to rewrite portions of the source code. > I am also wondering if I need to change the make file further since it > first generates a bunch of .o files, This is normal. > on which I don't know whether they should be .exe in window (I doubt it). No; they are the intermediate object files, which will eventually be linked together, to create the `.exe'. BTW, I must echo Michael Gerdau's comment about reducing a fault log to the minimum required to reproduce the problem: > Best way to actually get someone to look at your problem is to > reduce it as much as possible. Apart from creating a minimal source > file showing the problem you should also try to reproduce the problem > by issuing the offending command from a shell alone. In this case, only those snippets I've reproduced above are necessary to identify the probable cause of your problem; the remainder was nothing more than confusing noise. A *small* example of a self contained source file, just sufficient to reproduce the problem would also have been helpful. Regards, Keith. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ MinGW-users mailing list Min...@li... You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Tim S. <sta...@ne...> - 2007-05-18 15:45:12
|
Have you changed /etc/profile? Tim S >From Code::Blocks forum post http://forums.codeblocks.org/index.php/topic,5870.msg45302.html#msg45302 Suggested adding for an expermental unsupported build of GCC 4.3.0, replace 4.3.0 with 4.2.0 export CPLUS_INCLUDE_PATH=/mingw/include:/mingw/include/c++/4.3.0: \ /mingw/include/c++/4.3.0/mingw32:/mingw/lib/gcc/mingw32/4.3.0/include |
From: Aaron W. L. <aar...@aa...> - 2007-05-18 15:28:01
|
dan...@us... wrote: > What would mingw users like for a binary release package? The only fix I need in 4.2.0 is PR27067 <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27067>. I hope that, whatever you do, you include your excellent fix for this issue in the mingw.org build, as it's likely to be a deal-breaker for people other than me too. |
From: David G. <jdg...@am...> - 2007-05-18 16:14:46
|
dan...@us... wrote: > GCC 4.2.0 has been released. > > What would mingw users like for a binary release package? > > (1) Based on pristine (well, just a few makefile.in tweaks to get around > CRLF, no-symlinks, etc issues) FSF sources, as is, with known bugs. > (2) As above but backporting select features from 4.3.0, fixing some > aforementioned known bugs. > (3) As (2) but enabling DW2 unwind. > (4) As (2) but building libstdc++ and libgcc as dll's. > (5) (3) | (4). > (6) Your "I'd rather...". > > > (5) has receieved the most testing on my machine. > > Danny > "most testing" sounds very attractive to me. My big-ticket item is Ada. I would like to have a 4.2 Ada compiler that works well with GWindows, (A Sourceforge project) which I use to write Windows programs with Ada. I do think that it would be a good idea to keep in mind portability of patches to the main FSF gcc sources. IIRC, Windows will be a supported secondary platform starting with gcc 4.3. If good Windows patches can be integrated into the mainstream of gcc development, the job of future MinGW/MSYS development will be simpler, as scarce resources can go into other useful things, rather than compiler support. |
From: Eric W. <ewe...@cs...> - 2007-05-18 18:40:05
|
> -----Original Message----- > From: min...@li... > [mailto:min...@li...] On Behalf > Of David Gressett > Sent: Friday, May 18, 2007 10:14 AM > To: MinGW Users List > Subject: Re: [Mingw-users] GCC 4.2.0 > My big-ticket > item is Ada. > I would like to have a 4.2 Ada compiler Ok, I have a vote for a 4.2 Ada compiler too. I need it to build an Ada cross-compiler for the AVR target. Eric Weddington |
From: David D. <dav...@rs...> - 2007-05-18 20:36:59
|
If (4) is required for using strings between an application and it's DLLs, or if it is required for throwing exceptions between application and DLL boundaries then I say (5) as well. Anything that will help GDB be more accurate under windows (for example maybe (3)?) would also be a plus. Most importantly, thank you for your time and dedication. Without MinGW, our build process would be much more complicated and expensive. - Dave On Fri, 2007-05-18 at 10:02 +1200, dan...@us... wrote: > GCC 4.2.0 has been released. > > What would mingw users like for a binary release package? > > (1) Based on pristine (well, just a few makefile.in tweaks to get around > CRLF, no-symlinks, etc issues) FSF sources, as is, with known bugs. > (2) As above but backporting select features from 4.3.0, fixing some > aforementioned known bugs. > (3) As (2) but enabling DW2 unwind. > (4) As (2) but building libstdc++ and libgcc as dll's. > (5) (3) | (4). > (6) Your "I'd rather...". > > > (5) has receieved the most testing on my machine. > > Danny > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
From: Keith M. <kei...@us...> - 2007-05-19 20:14:06
|
On Thursday 17 May 2007 23:02, dan...@us... wrote: > GCC 4.2.0 has been released. > > What would mingw users like for a binary release package? > > (1) Based on pristine (well, just a few makefile.in tweaks to get > around CRLF, no-symlinks, etc issues) FSF sources, as is, with known > bugs. (2) As above but backporting select features from 4.3.0, fixing > some aforementioned known bugs. > (3) As (2) but enabling DW2 unwind. > (4) As (2) but building libstdc++ and libgcc as dll's. > (5) (3) | (4). > (6) Your "I'd rather...". > > (5) has receieved the most testing on my machine. Danny, Whatever you've devoted most attention to testing seems like the most attractive proposition to me. I do, however, share Chuck Wilson's concerns over the dangers of departing too far from FSF mainline code, and the likely effect of that on future MinGW development; (a concern which seems to be lent credence by your own): > I was hoping everyone would say "(1) and if we find any bugs we'll > send patches to FSF" Nonetheless, if you are happy to go with (5), which seems to be the majority preference, and you don't forsee any negative impact on the future course of MinGW development, then that's fine by me. I would just ask, when you roll the tarballs, that you take note of: https://sourceforge.net/tracker/index.php?func=detail&aid=1712703&group_id=2435&atid=102435 Regards, Keith. |
From: John P. <joh...@st...> - 2007-05-20 11:41:26
|
Hi Danny & all, Can anyone clarify whether this GCC release is likely to resolve the MSVCRT linking problem that has caused problems with the C FILE* API when writing Python extensions previously discussed on this list? Or does that remain a separate issue? Cheers JP dan...@us... wrote: > GCC 4.2.0 has been released. > > What would mingw users like for a binary release package? > > (1) Based on pristine (well, just a few makefile.in tweaks to get around > CRLF, no-symlinks, etc issues) FSF sources, as is, with known bugs. > (2) As above but backporting select features from 4.3.0, fixing some > aforementioned known bugs. > (3) As (2) but enabling DW2 unwind. > (4) As (2) but building libstdc++ and libgcc as dll's. > (5) (3) | (4). > (6) Your "I'd rather...". > > > (5) has receieved the most testing on my machine. > > Danny > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > -- John Pye Department of Mechanical and Manufacturing Engineering University of New South Wales, Sydney, Australia http://pye.dyndns.org/ |
From: Keith M. <kei...@to...> - 2007-05-21 08:25:34
|
John Pye wrote: > Can anyone clarify whether this GCC release is likely to resolve the > MSVCRT linking problem that has caused problems with the C FILE* API > when writing Python extensions previously discussed on this list? Or > does that remain a separate issue? I believe that is a completely separate issue. Regards, Keith. |
From: Gilles D. <gil...@ma...> - 2007-05-20 12:57:40
|
Hi Danny, I would vote for either (1) because closer to FSF release are therefore maybe less work for the next release or (5) since you mention it has received more testing. I'll be happy to test whatever you release (as a candidate to replace GCC 3.4.5) and I would like to thank you and the other volunteers for providing such a useful prebuilt binary of GCC for MinGW. Best regards, Gilles > (1) Based on pristine (well, just a few makefile.in tweaks to get > around > CRLF, no-symlinks, etc issues) FSF sources, as is, with known bugs. > (2) As above but backporting select features from 4.3.0, fixing some > aforementioned known bugs. > (3) As (2) but enabling DW2 unwind. > (4) As (2) but building libstdc++ and libgcc as dll's. > (5) (3) | (4). > (6) Your "I'd rather...". > > > (5) has receieved the most testing on my machine. -- Gilles Depeyrot <mailto:gil...@ma...> |