* Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 @ 2002-07-11 2:19 Christopher Faylor 2002-07-11 3:47 ` Charles Wilson ` (2 more replies) 0 siblings, 3 replies; 30+ messages in thread From: Christopher Faylor @ 2002-07-11 2:19 UTC (permalink / raw) To: cygwin Fixes in gcc2: -mno-cygwin works with c++ now? HOWEVER, I've fixed this problem by creating a separate g++-3 directory in /usr/include. If you have a symbolic link there or if you have modified files in that directory they will be wiped out. Or, er, I actually don't know what will happen to the symbolic link. It is probably a good idea to eliminate it before installing the package. (I'm taking bets now on when we'll see the first bug report as a result of this change.) Fixes in gcc3: g77 included. libgcj included. (does this mean gcj works? Who knows...) c++ header issues solved? (This turned out to partially be a problem in the generic gcc 3.1 branch) syslimits.h now included. __fastcall works now? (should be fixed by new version of binutils, actually) cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-11 2:19 Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 Christopher Faylor @ 2002-07-11 3:47 ` Charles Wilson 2002-07-11 3:49 ` Charles Wilson ` (2 more replies) 2002-07-11 7:19 ` Nicholas Wourms 2002-07-11 8:49 ` Pavel Tsekov 2 siblings, 3 replies; 30+ messages in thread From: Charles Wilson @ 2002-07-11 3:47 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 6628 bytes --] Christopher Faylor wrote: > Fixes in gcc2: > > -mno-cygwin works with c++ now? > > HOWEVER, I've fixed this problem by creating a separate g++-3 > directory in /usr/include. If you have a symbolic link there or > if you have modified files in that directory they will be wiped > out. Or, er, I actually don't know what will happen to the symbolic > link. It is probably a good idea to eliminate it before installing > the package. > > (I'm taking bets now on when we'll see the first bug report as a > result of this change.) Okay, there's just one thing I forgot to mention last time: there still is no mingw libstdc++(-2).a for gcc-2.95.3-8 (of course, 2.95.3-5 didn't have one either, so this is no big deal. However, since you're providing the mingw/g++-3 headers ... Anyway, see below. The attached test "suite" provides stripped down versions of the C, C++, and Fortran dllhelpers examples, plus several -mno-cygwin invocation scripts. I tested thus: unpack cd gcc-tests/c unset CC export CC make make clean export CC=mgcc make make clean export CC=gcc-2 make make clean export CC=mgcc-2 make make clean Then, same thing in the cxx directory, using CXX=[],mg++,g++-2,mg++-2. Ditto in f77 dir, using FC=[],mg77,g77-2,mg77-2 Results: 3.1.1: gcc works gcc -mno-cygwin works g++ works g++ -mno-cygwin works g77 works g77 -mno-cygwin works 2.95.3-8: /usr/lib/libstdc++.a.2.1.0 ?? what is this file? gcc-2 works gcc-2 -mno-cygwin works g++-2 works g++-2 -mno-cygwin links against the /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-8/libstdc++-2.a (oh yeah -- there is no mingw libstdc++ for this release. I copied my mingw libstdc++.a to libstdc++-2.a, and then got *different* errors) see below. Shouldn't be a mangling issue; it was build with 2.95.3-5. g77-2 breaks: /usr/lib/libcygwin.a(libcmain.o)(.text+0x81): undefined reference to `WinMain@16' g77-2 -mno-cygwin breaks: /usr/lib/mingw/libmingw32.a(main.o)(.text+0x8d):main.c: undefined reference to `WinMain@16' Note the g++-2 IS finding my custom libstdc++-2.a (which is a copy of a libstdc++.a that worked just fine with gcc-2.95.3-5). mg++-2 -o usedll.exe -g usedll.o -L./ -lcxxdll usedll.o: In function `main': /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:21: undefined reference to `endl(ostream &)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:21: undefined reference to `endl(ostream &)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:21: undefined reference to `endl(ostream &)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:21: undefined reference to `endl(ostream &)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:21: undefined reference to `endl(ostream &)' usedll.o:/usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:21: more undefined references to `endl(ostream &)' follow usedll.o: In function `main': /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:21: undefined reference to `cout' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(char const *)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(int)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(char const *)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(char const *)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(int)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(char const *)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(int)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(char const *)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(int)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(char const *)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(char const *)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(int)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(char const *)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(int)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(char const *)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(int)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:29: undefined reference to `endl(ostream &)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:29: undefined reference to `endl(ostream &)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:29: undefined reference to `endl(ostream &)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:29: undefined reference to `endl(ostream &)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:29: undefined reference to `cout' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:29: undefined reference to `ostream::operator<<(char const *)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:29: undefined reference to `ostream::operator<<(char const *)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:29: undefined reference to `ostream::operator<<(int)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:29: undefined reference to `ostream::operator<<(char const *)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:29: undefined reference to `ostream::operator<<(int)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:29: undefined reference to `ostream::operator<<(char const *)' /usr/local/src/dllhelpers/dllhelpers-0.4.1/cxx/usedll.cc:29: undefined reference to `ostream::operator<<(int)' Info: resolving DllClass::instances by linking to __imp___8DllClass$instances (auto-import) Info: resolving _global_dllclass2 by linking to __imp__global_dllclass2 (auto-import) Info: resolving _global_dllclass1 by linking to __imp__global_dllclass1 (auto-import) Info: resolving _global_int_variable by linking to __imp__global_int_variable (auto-import) collect2: ld returned 1 exit status make: *** [usedll.exe] Error 1 [-- Attachment #2: gcc-tests.tar.bz2 --] [-- Type: application/octet-stream, Size: 3708 bytes --] [-- Attachment #3: Type: text/plain, Size: 214 bytes --] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-11 3:47 ` Charles Wilson @ 2002-07-11 3:49 ` Charles Wilson 2002-07-11 6:47 ` Nicholas Wourms 2002-07-11 20:26 ` Christopher Faylor 2002-07-11 10:19 ` Christopher Faylor 2002-07-15 0:55 ` Charles Wilson 2 siblings, 2 replies; 30+ messages in thread From: Charles Wilson @ 2002-07-11 3:49 UTC (permalink / raw) To: Charles Wilson; +Cc: cygwin Charles Wilson wrote: > 2.95.3-8: > > g77-2 breaks: > /usr/lib/libcygwin.a(libcmain.o)(.text+0x81): undefined reference to > `WinMain@16' ^^^^^ this is new. g77-2 worked in 2.95.3-7. > g77-2 -mno-cygwin breaks: > /usr/lib/mingw/libmingw32.a(main.o)(.text+0x8d):main.c: undefined > reference to `WinMain@16' Didn't test g77-2 -mno-cygwin in 2.95.3-7 --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-11 3:49 ` Charles Wilson @ 2002-07-11 6:47 ` Nicholas Wourms 2002-07-11 8:26 ` Charles Wilson 2002-07-11 20:26 ` Christopher Faylor 1 sibling, 1 reply; 30+ messages in thread From: Nicholas Wourms @ 2002-07-11 6:47 UTC (permalink / raw) To: Charles Wilson; +Cc: cygwin --- Charles Wilson <cwilson@ece.gatech.edu> wrote: > Charles Wilson wrote: > > > 2.95.3-8: > > > > g77-2 breaks: > > /usr/lib/libcygwin.a(libcmain.o)(.text+0x81): undefined reference to > > `WinMain@16' > > > ^^^^^ this is new. g77-2 worked in 2.95.3-7. > > > > g77-2 -mno-cygwin breaks: > > /usr/lib/mingw/libmingw32.a(main.o)(.text+0x8d):main.c: undefined > > reference to `WinMain@16' > > Didn't test g77-2 -mno-cygwin in 2.95.3-7 Chuck, Out of curiosity, do you still have a link called g++-3 in /usr/include/mingw that points to /usr/include/g++-3? (This was required in the past, but now...) Or is this not necessary anymore? I'm trying to evaluate what's required now to compile mingw apps inside cygwin. (I.E. I'm trying to compile setup.exe) Cheers, Nicholas __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-11 6:47 ` Nicholas Wourms @ 2002-07-11 8:26 ` Charles Wilson 0 siblings, 0 replies; 30+ messages in thread From: Charles Wilson @ 2002-07-11 8:26 UTC (permalink / raw) To: Nicholas Wourms; +Cc: cygwin Nicholas Wourms wrote: > Chuck, > > Out of curiosity, do you still have a link called g++-3 in > /usr/include/mingw that points to /usr/include/g++-3? (This was required > in the past, but now...) Or is this not necessary anymore? I'm trying to > evaluate what's required now to compile mingw apps inside cygwin. (I.E. > I'm trying to compile setup.exe) No, I removed it before installing gcc2-2.95.3-8, as instructed in Chris' announcement. --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-11 3:49 ` Charles Wilson 2002-07-11 6:47 ` Nicholas Wourms @ 2002-07-11 20:26 ` Christopher Faylor 2002-07-11 20:50 ` Christopher Faylor 1 sibling, 1 reply; 30+ messages in thread From: Christopher Faylor @ 2002-07-11 20:26 UTC (permalink / raw) To: cygwin On Thu, Jul 11, 2002 at 03:25:54AM -0400, Charles Wilson wrote: >Charles Wilson wrote: > >>2.95.3-8: >> >>g77-2 breaks: >> /usr/lib/libcygwin.a(libcmain.o)(.text+0x81): undefined reference to >>`WinMain@16' > > >^^^^^ this is new. g77-2 worked in 2.95.3-7. This is very very strange. I duplicated your problem and decided it was due to something wrong in libg2c.a so I copied the 2.95.3-7 into the appropriate place. Your test case worked. Aha! So, I copied the 2.95.3-8 version back. And it worked. Dweui? So, I uninstalled my gcc2 installation and reinstalled it. Still works. Snort. Like I said. Strange. I'm probably doing something very stupid, which will occur to me 2 seconds after I send this, but could I ask you to wipe out your current gcc2 installation, reinstall it, and see what happens? cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-11 20:26 ` Christopher Faylor @ 2002-07-11 20:50 ` Christopher Faylor 0 siblings, 0 replies; 30+ messages in thread From: Christopher Faylor @ 2002-07-11 20:50 UTC (permalink / raw) To: cygwin On Thu, Jul 11, 2002 at 07:35:56PM -0400, Christopher Faylor wrote: >On Thu, Jul 11, 2002 at 03:25:54AM -0400, Charles Wilson wrote: >>Charles Wilson wrote: >> >>>2.95.3-8: >>> >>>g77-2 breaks: >>> /usr/lib/libcygwin.a(libcmain.o)(.text+0x81): undefined reference to >>>`WinMain@16' >> >> >>^^^^^ this is new. g77-2 worked in 2.95.3-7. > >This is very very strange. > >I duplicated your problem and decided it was due to something wrong in >libg2c.a so I copied the 2.95.3-7 into the appropriate place. Your >test case worked. Aha! > >So, I copied the 2.95.3-8 version back. > >And it worked. Dweui? > >So, I uninstalled my gcc2 installation and reinstalled it. > >Still works. Snort. > >Like I said. Strange. > >I'm probably doing something very stupid, which will occur to me 2 >seconds after I send this, but could I ask you to wipe out your current >gcc2 installation, reinstall it, and see what happens? Sorry. I was slow. It took me about twenty seconds. You can disregard this email. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-11 3:47 ` Charles Wilson 2002-07-11 3:49 ` Charles Wilson @ 2002-07-11 10:19 ` Christopher Faylor 2002-07-11 11:56 ` Charles Wilson 2002-07-15 0:55 ` Charles Wilson 2 siblings, 1 reply; 30+ messages in thread From: Christopher Faylor @ 2002-07-11 10:19 UTC (permalink / raw) To: cygwin On Thu, Jul 11, 2002 at 03:21:41AM -0400, Charles Wilson wrote: >Okay, there's just one thing I forgot to mention last time: there still >is no mingw libstdc++(-2).a for gcc-2.95.3-8 (of course, 2.95.3-5 didn't >have one either, so this is no big deal. However, since you're >providing the mingw/g++-3 headers ... I wasn't really planning on providing this. The goal is to switch to v3, really. The only reason I provided the headers was to allow g++ to work the same with -mno-cygwin as it did before. >Anyway, see below. > >The attached test "suite" provides stripped down versions of the C, C++, >and Fortran dllhelpers examples, plus several -mno-cygwin invocation >scripts. > >I tested thus: > unpack > cd gcc-tests/c > unset CC > export CC > make > make clean > > export CC=mgcc > make > make clean > > export CC=gcc-2 > make > make clean > > export CC=mgcc-2 > make > make clean > >Then, same thing in the cxx directory, using CXX=[],mg++,g++-2,mg++-2. >Ditto in f77 dir, using FC=[],mg77,g77-2,mg77-2 > >Results: > > >3.1.1: > >gcc works >gcc -mno-cygwin works >g++ works >g++ -mno-cygwin works >g77 works >g77 -mno-cygwin works > >2.95.3-8: > >/usr/lib/libstdc++.a.2.1.0 ?? what is this file? It's been around for some time. It's the libstdc++.a library for gcc 2.95.3 + libstdc++. >gcc-2 works >gcc-2 -mno-cygwin works > >g++-2 works >g++-2 -mno-cygwin links against the >/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-8/libstdc++-2.a > (oh yeah -- there is no mingw libstdc++ for this release. > I copied my mingw libstdc++.a to libstdc++-2.a, and then got *different* > errors) > see below. Shouldn't be a mangling issue; it was build with 2.95.3-5. Are you sure this is being used, though? >g77-2 breaks: > /usr/lib/libcygwin.a(libcmain.o)(.text+0x81): undefined reference to > `WinMain@16' >g77-2 -mno-cygwin breaks: > /usr/lib/mingw/libmingw32.a(main.o)(.text+0x8d):main.c: undefined reference > to `WinMain@16' Strange. I didn't touch g77 at all. >Note the g++-2 IS finding my custom libstdc++-2.a (which is a >copy of a libstdc++.a that worked just fine with gcc-2.95.3-5). > >mg++-2 -o usedll.exe -g usedll.o -L./ -lcxxdll >usedll.o: In function `main': Can you add a -v here, just to verify what library is being used? cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-11 10:19 ` Christopher Faylor @ 2002-07-11 11:56 ` Charles Wilson 2002-07-11 21:09 ` Christopher Faylor 0 siblings, 1 reply; 30+ messages in thread From: Charles Wilson @ 2002-07-11 11:56 UTC (permalink / raw) To: cygwin Christopher Faylor wrote: > On Thu, Jul 11, 2002 at 03:21:41AM -0400, Charles Wilson wrote: > >>Okay, there's just one thing I forgot to mention last time: there still >>is no mingw libstdc++(-2).a for gcc-2.95.3-8 (of course, 2.95.3-5 didn't >>have one either, so this is no big deal. However, since you're >>providing the mingw/g++-3 headers ... >> > > I wasn't really planning on providing this. The goal is to switch to v3, > really. The only reason I provided the headers was to allow g++ to work > the same with -mno-cygwin as it did before. > Right. The thought occurred to me that perhaps the addition of mingw/include/g++-3 files is incomplete: either it shouldn't be done at all, or should be accompanied by the library. However, doing a diff on my cross-compiler g++-3 files and yours, gives me only _G_config.h -- but yours is identical to mine in /opt/mingw/i686-pc-mingw32/... So, the headers you provided were identical to the ones I was using before -- but your spec file now searches for "libstdc++-2.a". fine, I copied my libstdc++.a to there: but still get link errors...understandable if the ABI changed, but it hasn't. So I'm confused, but it seems as tho one cannot get g++-2 -mno-cygwin from 2.95.3-8 to work even after taking the steps that previously were sufficient to get g++ -mno-cygwin from 2.95.3-5 to work. >>/usr/lib/libstdc++.a.2.1.0 ?? what is this file? >> > > It's been around for some time. It's the libstdc++.a library for gcc > 2.95.3 + libstdc++. Okay -- I remember it from 2.95.3-5, but I thought it was removed in 2.95.3-7. It doesn't cause any problems either way; it's never used. >>gcc-2 works >>gcc-2 -mno-cygwin works >> >>g++-2 works >>g++-2 -mno-cygwin links against the >>/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-8/libstdc++-2.a >>(oh yeah -- there is no mingw libstdc++ for this release. >>I copied my mingw libstdc++.a to libstdc++-2.a, and then got *different* >>errors) >>see below. Shouldn't be a mangling issue; it was build with 2.95.3-5. >> > > Are you sure this is being used, though? > Yes, I verified by using g++ --verbose, and then copying the collect2.exe line by hand, and adding --verbose to THAT-- which should that YES, it was linking to my /usr/lib/mingw/libstdc++-2.a library (which was a copy of libstdc++.a yadda yadda yadda) I duplicated this below... >>g77-2 breaks: >>/usr/lib/libcygwin.a(libcmain.o)(.text+0x81): undefined reference to >>`WinMain@16' >>g77-2 -mno-cygwin breaks: >>/usr/lib/mingw/libmingw32.a(main.o)(.text+0x8d):main.c: undefined reference >>to `WinMain@16' >> > > Strange. I didn't touch g77 at all. Weird. > >>Note the g++-2 IS finding my custom libstdc++-2.a (which is a >>copy of a libstdc++.a that worked just fine with gcc-2.95.3-5). >> >>mg++-2 -o usedll.exe -g usedll.o -L./ -lcxxdll >>usedll.o: In function `main': >> > > Can you add a -v here, just to verify what library is being used? I did, but I redid that and copied the results below... --Chuck $ ./mg++-2 -o usedll.exe -g usedll.o -L./ -lcxxdll -v Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-8/specs gcc version 2.95.3-8 (cygwin special) /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-8/collect2.exe -Bdynamic -o usedll.exe /usr/lib/mingw/crt2.o -L./ -L/usr/lib/mingw -L/usr/lib/w32api -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-8 usedll.o -lcxxdll -lstdc++-2 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -lmingw32 -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt ---- above will result in the same errors posted previously. ----- ---- so, try again by calling ld directly ---- $ ld -Bdynamic -o usedll.exe /usr/lib/mingw/crt2.o -L./ -L/usr/lib/mingw -L/usr/lib/w32api -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-8 usedll.o -lcxxdll -lstdc++-2 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -lmingw32 -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt --verbose GNU ld version 2.12.90 20020706 Supported emulations: i386pe using internal linker script: ================================================== /* Default linker script, for normal executables */ OUTPUT_FORMAT(pei-i386) SEARCH_DIR("/usr/i686-pc-cygwin/lib"); SEARCH_DIR("/usr/lib"); SEARCH_DIR("/usr/lib/w32api"); ENTRY(_mainCRTStartup) SECTIONS { .text __image_base__ + __section_alignment__ : { *(.init) *(.text) *(SORT(.text$*)) *(.glue_7t) *(.glue_7) ___CTOR_LIST__ = .; __CTOR_LIST__ = . ; LONG (-1); *(SORT(.ctors.*)); *(.ctors); *(.ctor); LONG (0); ___DTOR_LIST__ = .; __DTOR_LIST__ = . ; LONG (-1); *(SORT(.dtors.*)); *(.dtors); *(.dtor); LONG (0); *(.fini) /* ??? Why is .gcc_exc here? */ *(.gcc_exc) etext = .; *(.gcc_except_table) } /* The Cygwin32 library uses a section to avoid copying certain data on fork. This used to be named ".data". The linker used to include this between __data_start__ and __data_end__, but that breaks building the cygwin32 dll. Instead, we name the section ".data_cygwin_nocopy" and explictly include it after __data_end__. */ .data BLOCK(__section_alignment__) : { __data_start__ = . ; *(.data) *(.data2) *(SORT(.data$*)) __data_end__ = . ; *(.data_cygwin_nocopy) } .rdata BLOCK(__section_alignment__) : { *(.rdata) *(SORT(.rdata$*)) *(.eh_frame) } .pdata BLOCK(__section_alignment__) : { *(.pdata) } .bss BLOCK(__section_alignment__) : { __bss_start__ = . ; *(.bss) *(COMMON) __bss_end__ = . ; } .edata BLOCK(__section_alignment__) : { *(.edata) } /DISCARD/ : { *(.debug$S) *(.debug$T) *(.debug$F) *(.drectve) } .idata BLOCK(__section_alignment__) : { /* This cannot currently be handled with grouped sections. See pe.em:sort_sections. */ SORT(*)(.idata$2) SORT(*)(.idata$3) /* These zeroes mark the end of the import list. */ LONG (0); LONG (0); LONG (0); LONG (0); LONG (0); SORT(*)(.idata$4) SORT(*)(.idata$5) SORT(*)(.idata$6) SORT(*)(.idata$7) } .CRT BLOCK(__section_alignment__) : { *(SORT(.CRT$*)) } .endjunk BLOCK(__section_alignment__) : { /* end is deprecated, don't use it */ end = .; _end = .; __end__ = .; } .rsrc BLOCK(__section_alignment__) : { *(.rsrc) *(SORT(.rsrc$*)) } .reloc BLOCK(__section_alignment__) : { *(.reloc) } .stab BLOCK(__section_alignment__) (NOLOAD) : { [ .stab ] } .stabstr BLOCK(__section_alignment__) (NOLOAD) : { [ .stabstr ] } } ================================================== attempt to open /usr/lib/mingw/crt2.o succeeded /usr/lib/mingw/crt2.o attempt to open usedll.o succeeded usedll.o attempt to open .//libcxxdll.dll.a succeeded (.//libcxxdll.dll.a)d000002.o (.//libcxxdll.dll.a)d000012.o (.//libcxxdll.dll.a)d000011.o (.//libcxxdll.dll.a)d000013.o (.//libcxxdll.dll.a)d000004.o (.//libcxxdll.dll.a)d000001.o (.//libcxxdll.dll.a)d000014.o (.//libcxxdll.dll.a)d000016.o (.//libcxxdll.dll.a)d000000.o (.//libcxxdll.dll.a)d000017.o attempt to open .//libstdc++-2.dll.a failed attempt to open .//stdc++-2.dll.a failed attempt to open .//libstdc++-2.a failed attempt to open .//libstdc++-2.dll failed attempt to open .//stdc++-2.dll failed attempt to open .//libstdc++-2.a failed attempt to open /usr/lib/mingw/libstdc++-2.dll.a failed attempt to open /usr/lib/mingw/stdc++-2.dll.a failed attempt to open /usr/lib/mingw/libstdc++-2.a succeeded attempt to open .//libmingw32.dll.a failed attempt to open .//mingw32.dll.a failed attempt to open .//libmingw32.a failed attempt to open .//libmingw32.dll failed attempt to open .//mingw32.dll failed attempt to open .//libmingw32.a failed attempt to open /usr/lib/mingw/libmingw32.dll.a failed attempt to open /usr/lib/mingw/mingw32.dll.a failed attempt to open /usr/lib/mingw/libmingw32.a succeeded (/usr/lib/mingw/libmingw32.a)CRTglob.o (/usr/lib/mingw/libmingw32.a)CRTfmode.o (/usr/lib/mingw/libmingw32.a)CRT_fp10.o (/usr/lib/mingw/libmingw32.a)gccmain.o attempt to open .//libgcc.dll.a failed attempt to open .//gcc.dll.a failed attempt to open .//libgcc.a failed attempt to open .//libgcc.dll failed attempt to open .//gcc.dll failed attempt to open .//libgcc.a failed attempt to open /usr/lib/mingw/libgcc.dll.a failed attempt to open /usr/lib/mingw/gcc.dll.a failed attempt to open /usr/lib/mingw/libgcc.a failed attempt to open /usr/lib/mingw/libgcc.dll failed attempt to open /usr/lib/mingw/gcc.dll failed attempt to open /usr/lib/mingw/libgcc.a failed attempt to open /usr/lib/w32api/libgcc.dll.a failed attempt to open /usr/lib/w32api/gcc.dll.a failed attempt to open /usr/lib/w32api/libgcc.a failed attempt to open /usr/lib/w32api/libgcc.dll failed attempt to open /usr/lib/w32api/gcc.dll failed attempt to open /usr/lib/w32api/libgcc.a failed attempt to open /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-8/libgcc.dll.a failed attempt to open /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-8/gcc.dll.a failed attempt to open /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-8/libgcc.a succeeded (/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-8/libgcc.a)_eh.o (/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-8/libgcc.a)_ctors.o (/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-8/libgcc.a)frame.o (/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-8/libgcc.a)_chkstk.o attempt to open .//libmoldname.dll.a failed attempt to open .//moldname.dll.a failed attempt to open .//libmoldname.a failed attempt to open .//libmoldname.dll failed attempt to open .//moldname.dll failed attempt to open .//libmoldname.a failed attempt to open /usr/lib/mingw/libmoldname.dll.a failed attempt to open /usr/lib/mingw/moldname.dll.a failed attempt to open /usr/lib/mingw/libmoldname.a succeeded (/usr/lib/mingw/libmoldname.a)ds00104.o (/usr/lib/mingw/libmoldname.a)dh.o (/usr/lib/mingw/libmoldname.a)dt.o attempt to open .//libmingwex.dll.a failed attempt to open .//mingwex.dll.a failed attempt to open .//libmingwex.a failed attempt to open .//libmingwex.dll failed attempt to open .//mingwex.dll failed attempt to open .//libmingwex.a failed attempt to open /usr/lib/mingw/libmingwex.dll.a failed attempt to open /usr/lib/mingw/mingwex.dll.a failed attempt to open /usr/lib/mingw/libmingwex.a succeeded attempt to open .//libmsvcrt.dll.a failed attempt to open .//msvcrt.dll.a failed attempt to open .//libmsvcrt.a failed attempt to open .//libmsvcrt.dll failed attempt to open .//msvcrt.dll failed attempt to open .//libmsvcrt.a failed attempt to open /usr/lib/mingw/libmsvcrt.dll.a failed attempt to open /usr/lib/mingw/msvcrt.dll.a failed attempt to open /usr/lib/mingw/libmsvcrt.a succeeded (/usr/lib/mingw/libmsvcrt.a)ds00178.o (/usr/lib/mingw/libmsvcrt.a)ds00222.o (/usr/lib/mingw/libmsvcrt.a)ds00517.o (/usr/lib/mingw/libmsvcrt.a)ds00336.o (/usr/lib/mingw/libmsvcrt.a)ds00078.o (/usr/lib/mingw/libmsvcrt.a)ds00118.o (/usr/lib/mingw/libmsvcrt.a)ds00059.o (/usr/lib/mingw/libmsvcrt.a)ds00633.o (/usr/lib/mingw/libmsvcrt.a)ds00169.o (/usr/lib/mingw/libmsvcrt.a)ds00373.o (/usr/lib/mingw/libmsvcrt.a)ds00039.o (/usr/lib/mingw/libmsvcrt.a)ds00609.o (/usr/lib/mingw/libmsvcrt.a)ds00552.o (/usr/lib/mingw/libmsvcrt.a)ds00603.o (/usr/lib/mingw/libmsvcrt.a)ds00642.o (/usr/lib/mingw/libmsvcrt.a)ds00510.o (/usr/lib/mingw/libmsvcrt.a)dh.o (/usr/lib/mingw/libmsvcrt.a)dt.o attempt to open .//libmingw32.dll.a failed attempt to open .//mingw32.dll.a failed attempt to open .//libmingw32.a failed attempt to open .//libmingw32.dll failed attempt to open .//mingw32.dll failed attempt to open .//libmingw32.a failed attempt to open /usr/lib/mingw/libmingw32.dll.a failed attempt to open /usr/lib/mingw/mingw32.dll.a failed attempt to open /usr/lib/mingw/libmingw32.a succeeded attempt to open .//libuser32.dll.a failed attempt to open .//user32.dll.a failed attempt to open .//libuser32.a failed attempt to open .//libuser32.dll failed attempt to open .//user32.dll failed attempt to open .//libuser32.a failed attempt to open /usr/lib/mingw/libuser32.dll.a failed attempt to open /usr/lib/mingw/user32.dll.a failed attempt to open /usr/lib/mingw/libuser32.a failed attempt to open /usr/lib/mingw/libuser32.dll failed attempt to open /usr/lib/mingw/user32.dll failed attempt to open /usr/lib/mingw/libuser32.a failed attempt to open /usr/lib/w32api/libuser32.dll.a failed attempt to open /usr/lib/w32api/user32.dll.a failed attempt to open /usr/lib/w32api/libuser32.a succeeded attempt to open .//libkernel32.dll.a failed attempt to open .//kernel32.dll.a failed attempt to open .//libkernel32.a failed attempt to open .//libkernel32.dll failed attempt to open .//kernel32.dll failed attempt to open .//libkernel32.a failed attempt to open /usr/lib/mingw/libkernel32.dll.a failed attempt to open /usr/lib/mingw/kernel32.dll.a failed attempt to open /usr/lib/mingw/libkernel32.a failed attempt to open /usr/lib/mingw/libkernel32.dll failed attempt to open /usr/lib/mingw/kernel32.dll failed attempt to open /usr/lib/mingw/libkernel32.a failed attempt to open /usr/lib/w32api/libkernel32.dll.a failed attempt to open /usr/lib/w32api/kernel32.dll.a failed attempt to open /usr/lib/w32api/libkernel32.a succeeded (/usr/lib/w32api/libkernel32.a)ds00643.o (/usr/lib/w32api/libkernel32.a)ds00130.o (/usr/lib/w32api/libkernel32.a)ds00664.o (/usr/lib/w32api/libkernel32.a)ds00285.o (/usr/lib/w32api/libkernel32.a)ds00438.o (/usr/lib/w32api/libkernel32.a)ds00654.o (/usr/lib/w32api/libkernel32.a)ds00666.o (/usr/lib/w32api/libkernel32.a)ds00617.o (/usr/lib/w32api/libkernel32.a)ds00667.o (/usr/lib/w32api/libkernel32.a)ds00064.o (/usr/lib/w32api/libkernel32.a)ds00706.o (/usr/lib/w32api/libkernel32.a)ds00545.o (/usr/lib/w32api/libkernel32.a)dh.o (/usr/lib/w32api/libkernel32.a)dt.o attempt to open .//libadvapi32.dll.a failed attempt to open .//advapi32.dll.a failed attempt to open .//libadvapi32.a failed attempt to open .//libadvapi32.dll failed attempt to open .//advapi32.dll failed attempt to open .//libadvapi32.a failed attempt to open /usr/lib/mingw/libadvapi32.dll.a failed attempt to open /usr/lib/mingw/advapi32.dll.a failed attempt to open /usr/lib/mingw/libadvapi32.a failed attempt to open /usr/lib/mingw/libadvapi32.dll failed attempt to open /usr/lib/mingw/advapi32.dll failed attempt to open /usr/lib/mingw/libadvapi32.a failed attempt to open /usr/lib/w32api/libadvapi32.dll.a failed attempt to open /usr/lib/w32api/advapi32.dll.a failed attempt to open /usr/lib/w32api/libadvapi32.a succeeded attempt to open .//libshell32.dll.a failed attempt to open .//shell32.dll.a failed attempt to open .//libshell32.a failed attempt to open .//libshell32.dll failed attempt to open .//shell32.dll failed attempt to open .//libshell32.a failed attempt to open /usr/lib/mingw/libshell32.dll.a failed attempt to open /usr/lib/mingw/shell32.dll.a failed attempt to open /usr/lib/mingw/libshell32.a failed attempt to open /usr/lib/mingw/libshell32.dll failed attempt to open /usr/lib/mingw/shell32.dll failed attempt to open /usr/lib/mingw/libshell32.a failed attempt to open /usr/lib/w32api/libshell32.dll.a failed attempt to open /usr/lib/w32api/shell32.dll.a failed attempt to open /usr/lib/w32api/libshell32.a succeeded attempt to open .//libmingw32.dll.a failed attempt to open .//mingw32.dll.a failed attempt to open .//libmingw32.a failed attempt to open .//libmingw32.dll failed attempt to open .//mingw32.dll failed attempt to open .//libmingw32.a failed attempt to open /usr/lib/mingw/libmingw32.dll.a failed attempt to open /usr/lib/mingw/mingw32.dll.a failed attempt to open /usr/lib/mingw/libmingw32.a succeeded attempt to open .//libgcc.dll.a failed attempt to open .//gcc.dll.a failed attempt to open .//libgcc.a failed attempt to open .//libgcc.dll failed attempt to open .//gcc.dll failed attempt to open .//libgcc.a failed attempt to open /usr/lib/mingw/libgcc.dll.a failed attempt to open /usr/lib/mingw/gcc.dll.a failed attempt to open /usr/lib/mingw/libgcc.a failed attempt to open /usr/lib/mingw/libgcc.dll failed attempt to open /usr/lib/mingw/gcc.dll failed attempt to open /usr/lib/mingw/libgcc.a failed attempt to open /usr/lib/w32api/libgcc.dll.a failed attempt to open /usr/lib/w32api/gcc.dll.a failed attempt to open /usr/lib/w32api/libgcc.a failed attempt to open /usr/lib/w32api/libgcc.dll failed attempt to open /usr/lib/w32api/gcc.dll failed attempt to open /usr/lib/w32api/libgcc.a failed attempt to open /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-8/libgcc.dll.a failed attempt to open /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-8/gcc.dll.a failed attempt to open /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-8/libgcc.a succeeded attempt to open .//libmoldname.dll.a failed attempt to open .//moldname.dll.a failed attempt to open .//libmoldname.a failed attempt to open .//libmoldname.dll failed attempt to open .//moldname.dll failed attempt to open .//libmoldname.a failed attempt to open /usr/lib/mingw/libmoldname.dll.a failed attempt to open /usr/lib/mingw/moldname.dll.a failed attempt to open /usr/lib/mingw/libmoldname.a succeeded attempt to open .//libmingwex.dll.a failed attempt to open .//mingwex.dll.a failed attempt to open .//libmingwex.a failed attempt to open .//libmingwex.dll failed attempt to open .//mingwex.dll failed attempt to open .//libmingwex.a failed attempt to open /usedll.o: In function `main': /tmp/gcc-tests/cxx/usedll.cc:21: undefined reference to `endl(ostream &)' /tmp/gcc-tests/cxx/usedll.cc:21: undefined reference to `endl(ostream &)' /tmp/gcc-tests/cxx/usedll.cc:21: undefined reference to `endl(ostream &)' /tmp/gcc-tests/cxx/usedll.cc:21: undefined reference to `endl(ostream &)' /tmp/gcc-tests/cxx/usedll.cc:21: undefined reference to `endl(ostream &)' usedll.o:/tmp/gcc-tests/cxx/usedll.cc:21: more undefined references to `endl(ostream &)' follow usedll.o: In function `main': /tmp/gcc-tests/cxx/usedll.cc:21: undefined reference to `cout' /tmp/gcc-tests/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(char const *)' /tmp/gcc-tests/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(int)' /tmp/gcc-tests/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(char const *)' /tmp/gcc-tests/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(char const *)' /tmp/gcc-tests/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(int)' /tmp/gcc-tests/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(char const *)' /tmp/gcc-tests/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(int)' /tmp/gcc-tests/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(char const *)' /tmp/gcc-tests/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(int)' /tmp/gcc-tests/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(char const *)' /tmp/gcc-tests/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(char const *)' /tmp/gcc-tests/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(int)' /tmp/gcc-tests/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(char const *)' /tmp/gcc-tests/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(int)' /tmp/gcc-tests/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(char const *)' /tmp/gcc-tests/cxx/usedll.cc:21: undefined reference to `ostream::operator<<(int)' /tmp/gcc-tests/cxx/usedll.cc:29: undefined reference to `endl(ostream &)' /tmp/gcc-tests/cxx/usedll.cc:29: undefined reference to `endl(ostream &)' /tmp/gcc-tests/cxx/usedll.cc:29: undefined reference to `endl(ostream &)' /tmp/gcc-tests/cxx/usedll.cc:29: undefined reference to `endl(ostream &)' /tmp/gcc-tests/cxx/usedll.cc:29: undefined reference to `cout' /tmp/gcc-tests/cxx/usedll.cc:29: undefined reference to `ostream::operator<<(char const *)' /tmp/gcc-tests/cxx/usedll.cc:29: undefined reference to `ostream::operator<<(char const *)' /tmp/gcc-tests/cxx/usedll.cc:29: undefined reference to `ostream::operator<<(int)' /tmp/gcc-tests/cxx/usedll.cc:29: undefined reference to `ostream::operator<<(char const *)' /tmp/gcc-tests/cxx/usedll.cc:29: undefined reference to `ostream::operator<<(int)' /tmp/gcc-tests/cxx/usedll.cc:29: undefined reference to `ostream::operator<<(char const *)' /tmp/gcc-tests/cxx/usedll.cc:29: undefined reference to `ostream::operator<<(int)' usr/lib/mingw/libmingwex.dll.a failed attempt to open /usr/lib/mingw/mingwex.dll.a failed attempt to open /usr/lib/mingw/libmingwex.a succeeded attempt to open .//libmsvcrt.dll.a failed attempt to open .//msvcrt.dll.a failed attempt to open .//libmsvcrt.a failed attempt to open .//libmsvcrt.dll failed attempt to open .//msvcrt.dll failed attempt to open .//libmsvcrt.a failed attempt to open /usr/lib/mingw/libmsvcrt.dll.a failed attempt to open /usr/lib/mingw/msvcrt.dll.a failed attempt to open /usr/lib/mingw/libmsvcrt.a succeeded Info: resolving __8DllClass$instances by linking to __imp___8DllClass$instances (auto-import) Info: resolving _global_dllclass2 by linking to __imp__global_dllclass2 (auto-import) Info: resolving _global_dllclass1 by linking to __imp__global_dllclass1 (auto-import) Info: resolving _global_int_variable by linking to __imp__global_int_variable (auto-import) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-11 11:56 ` Charles Wilson @ 2002-07-11 21:09 ` Christopher Faylor 2002-07-11 21:33 ` Unscrible--liangalei@CS.SJTU.EDU.CN liangalei 2002-07-11 23:59 ` Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 Charles Wilson 0 siblings, 2 replies; 30+ messages in thread From: Christopher Faylor @ 2002-07-11 21:09 UTC (permalink / raw) To: cygwin On Thu, Jul 11, 2002 at 01:19:03PM -0400, Charles Wilson wrote: >attempt to open /usr/lib/mingw/libstdc++-2.a succeeded This is suspicious. It almost looks like libstdc++-2.a is empty. Otherwise, you would have seen some symbols being loaded here. I just tried this with the copy of libstdc++-2.a that I'd been using for setup builds and it seems to work ok. Could you do a "nm" on this file and make sure that it is not corrupted? Or maybe you need to do a ranlib on it? I've put the copy of libstdc++-2.a that I'm using at ftp://cygwin.com/pub/cygwin/tmp/libstdc++-2.a.bz2 if you want to try it. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Unscrible--liangalei@CS.SJTU.EDU.CN 2002-07-11 21:09 ` Christopher Faylor @ 2002-07-11 21:33 ` liangalei 2002-07-11 23:59 ` Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 Charles Wilson 1 sibling, 0 replies; 30+ messages in thread From: liangalei @ 2002-07-11 21:33 UTC (permalink / raw) To: cygwin Why I cannot unscrible this maillist? It's so too many email for me to understand, so I pause my subscribing to maillist. But I have do unscrible, and ack the Confirm mail, but still ba-la-ba-la so many mail. ----- Original Message ----- From: "Christopher Faylor" <cgf@redhat.com> To: <cygwin@cygwin.com> Sent: Friday, July 12, 2002 8:06 AM Subject: Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 > On Thu, Jul 11, 2002 at 01:19:03PM -0400, Charles Wilson wrote: > >attempt to open /usr/lib/mingw/libstdc++-2.a succeeded > > This is suspicious. It almost looks like libstdc++-2.a is empty. > Otherwise, you would have seen some symbols being loaded here. > > I just tried this with the copy of libstdc++-2.a that I'd been > using for setup builds and it seems to work ok. > > Could you do a "nm" on this file and make sure that it is not > corrupted? Or maybe you need to do a ranlib on it? > > I've put the copy of libstdc++-2.a that I'm using at > > ftp://cygwin.com/pub/cygwin/tmp/libstdc++-2.a.bz2 > > if you want to try it. > > cgf > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting: http://cygwin.com/bugs.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-11 21:09 ` Christopher Faylor 2002-07-11 21:33 ` Unscrible--liangalei@CS.SJTU.EDU.CN liangalei @ 2002-07-11 23:59 ` Charles Wilson 2002-07-12 0:27 ` Christopher Faylor 1 sibling, 1 reply; 30+ messages in thread From: Charles Wilson @ 2002-07-11 23:59 UTC (permalink / raw) To: cygwin Christopher Faylor wrote: > On Thu, Jul 11, 2002 at 01:19:03PM -0400, Charles Wilson wrote: > >>attempt to open /usr/lib/mingw/libstdc++-2.a succeeded >> > > This is suspicious. It almost looks like libstdc++-2.a is empty. > Otherwise, you would have seen some symbols being loaded here. > > I just tried this with the copy of libstdc++-2.a that I'd been > using for setup builds and it seems to work ok. > > Could you do a "nm" on this file and make sure that it is not > corrupted? Or maybe you need to do a ranlib on it? It had symbols. > I've put the copy of libstdc++-2.a that I'm using at > > ftp://cygwin.com/pub/cygwin/tmp/libstdc++-2.a.bz2 > > if you want to try it. DOH! gcc-3.1.1 (or maybe gcc-mingw-3_1-20020516-1) clobbered my old gcc-2.95.3 (mingw) version of /usr/lib/mingw/libstdc++.a. I copied it to libstdc++-2.a AFTER installing gcc-3.1.1. After restoring my original file (to libstdc++-2.a), everything worked. Sorry for the confusion (boy, I feel silly). So, 3.1.1: gcc works gcc -mno-cygwin works g++ works g++ -mno-cygwin works g77 works g77 -mno-cygwin works 2.95.3-8: gcc-2 works gcc-2 -mno-cygwin works g++-2 works g++-2 -mno-cygwin works (provided one installs libstdc++.a from mingw's gcc as /usr/lib/mingw/libstdc++-2.a) g77-2 breaks: /usr/lib/libcygwin.a(libcmain.o)(.text+0x81): undefined reference to `WinMain@16' g77-2 -mno-cygwin breaks: /usr/lib/mingw/libmingw32.a(main.o)(.text+0x8d):main.c: undefined reference to `WinMain@16' >> I'm probably doing something very stupid, which will occur to me 2 >>seconds after I send this, but could I ask you to wipe out your current >>gcc2 installation, reinstall it, and see what happens? > > > Sorry. I was slow. It took me about twenty seconds. > > You can disregard this email. I gather you figured out what was "wrong" with g77-2 in gcc2-2.95.3-8 ? --Chuck P.S. Now, my tests are very very simple. Consider them "basic" functionality tests. We still need more "real world" testing before these are ready to go, IMO. Also, I'm thinking that the files in /usr/include/g++-3/ (including _G_config.h) should go into a gcc2-mingw-2.95_YYYYMMDD-X package (perhaps along with usr/lib/mingw/libg2c.a usr/lib/mingw/libgcc.a usr/lib/mingw/libobjc.a usr/lib/mingw/libstdc++.a from mingw's gcc, appropriately '-2' renamed) Hey, wait a minute -- maybe that's why g77-2 is failing? It's linking against libg2c.a from 3.1? Yep, seems so! --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-11 23:59 ` Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 Charles Wilson @ 2002-07-12 0:27 ` Christopher Faylor 2002-07-12 0:31 ` Charles Wilson 0 siblings, 1 reply; 30+ messages in thread From: Christopher Faylor @ 2002-07-12 0:27 UTC (permalink / raw) To: cygwin On Thu, Jul 11, 2002 at 11:50:05PM -0400, Charles Wilson wrote: >g++ -mno-cygwin works Actually, this fails for me, for some reason. >>Sorry. I was slow. It took me about twenty seconds. >> >>You can disregard this email. > >I gather you figured out what was "wrong" with g77-2 in gcc2-2.95.3-8 ? Yes, the lack of libg2c-2.a. :-( The 3.1.1 version was always being picked up. So if you tried this before installing 3.1.1, it worked. I tried reinstalling gcc 2.95.3-5 to see if that worked, and, of course, it did. Once I installed that, gcc-2 started working, too. Doh. So, I've got a new version of gcc2 coming. I don't think that g77 -mno-cygwin ever worked before, AFAICT. I guess it should. So, I give up. The next version of gcc2 will have mingw libraries for libg2c-2.a and libstdc++-2.a. >P.S. Now, my tests are very very simple. Consider them "basic" >functionality tests. We still need more "real world" testing before >these are ready to go, IMO. > >Also, I'm thinking that the files in > /usr/include/g++-3/ (including _G_config.h) >should go into a > gcc2-mingw-2.95_YYYYMMDD-X >package (perhaps along with gcc2 is supposed to be going away someday (soon). I am just trying to repackage it so that people aren't left with problems in the short term. It's a royal pain to support this. Once gcc2 seems as stable as 2.95.3-5 used to be, that will be it for any further releases. I'm not going to complicate the process by adding extra packages. I know that Danny will be coming out with new 3.1 versions of gcc for mingw and that they will not be tied in any way to my gcc releases, so I thought it prudent to split the mingw stuff out so that I wouldn't have to respin the whole, huge gcc 3.1.1 package. I don't have to do that for 2.95.3. It's not going anywhere. I doubt that Danny will be making future releases or I'll be building mingw gcc's myself. >usr/lib/mingw/libgcc.a The 2.95.3-* version of libgcc.a is mingw compatible. I went to some pains to ensure that. >usr/lib/mingw/libobjc.a >usr/lib/mingw/libstdc++.a from mingw's gcc, appropriately '-2' renamed) > >Hey, wait a minute -- maybe that's why g77-2 is failing? It's linking >against libg2c.a from 3.1? Yep, seems so! Yep, you got it. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-12 0:27 ` Christopher Faylor @ 2002-07-12 0:31 ` Charles Wilson 2002-07-12 1:32 ` Christopher Faylor 2002-07-12 7:27 ` Nicholas Wourms 0 siblings, 2 replies; 30+ messages in thread From: Charles Wilson @ 2002-07-12 0:31 UTC (permalink / raw) To: cygwin Christopher Faylor wrote: > On Thu, Jul 11, 2002 at 11:50:05PM -0400, Charles Wilson wrote: > >>g++ -mno-cygwin works >> > > Actually, this fails for me, for some reason. Hmm... > > I don't think that g77 -mno-cygwin ever worked before, AFAICT. Perhaps not -- I was just being thorough. > I guess > it should. So, I give up. The next version of gcc2 will have mingw > libraries for libg2c-2.a and libstdc++-2.a. Cool. > gcc2 is supposed to be going away someday (soon). As long as there are (supported) C++ libraries that use the 2.95.3 ABI, we'll need gcc2. E.g. libncurses6++, and the others that were mentioned onlist, unless gcc-3.1.1 goes gold before they do. > I am just trying to > repackage it so that people aren't left with problems in the short term. Right, good, good... > It's a royal pain to support this. Once gcc2 seems as stable as > 2.95.3-5 used to be, that will be it for any further releases. Absolutely. > I'm not > going to complicate the process by adding extra packages. Oh, okay -- if you're going to add the mingw libs directly into gcc2, that'll work. And, since gcc2 will be effectively frozen, hopefully maintainance will drop to practically nil, so might as well anticipate things now... > I know that Danny will be coming out with new 3.1 versions of gcc for > mingw and that they will not be tied in any way to my gcc releases, so I > thought it prudent to split the mingw stuff out so that I wouldn't have > to respin the whole, huge gcc 3.1.1 package. I understand. > I don't have to do that > for 2.95.3. It's not going anywhere. I doubt that Danny will be > making future releases or I'll be building mingw gcc's myself. Right. > The 2.95.3-* version of libgcc.a is mingw compatible. I went to some > pains to ensure that. Nifty keen. 'Course, for my cygwin-host, mingw-target cross compiler, I'll need to respin it so that it coexists with the official gcc and gcc2 and gcc-mingw packages...sigh. Say, where do you change gcc(2.95.3) so that g++-2 links against libstdc++-2.a instead of libstdc++.a? (Ditto g77). It doesn't seem to be in the specs file, so I dunno WHERE that is done... --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-12 0:31 ` Charles Wilson @ 2002-07-12 1:32 ` Christopher Faylor 2002-07-12 2:54 ` Charles Wilson 2002-07-12 7:27 ` Nicholas Wourms 1 sibling, 1 reply; 30+ messages in thread From: Christopher Faylor @ 2002-07-12 1:32 UTC (permalink / raw) To: cygwin On Fri, Jul 12, 2002 at 12:33:31AM -0400, Charles Wilson wrote: >'Course, for my cygwin-host, mingw-target cross compiler, I'll need to >respin >it so that it coexists with the official gcc and gcc2 and gcc-mingw >packages...sigh. Do you need this anymore, though? You could get by with this, couldn't you: i686-pc-mingw32-gcc is: #!/bin/sh gcc -mno-cygwin $(@+"$@"} Or, should I not be coopting the i686-pc-mingw32 target directory? Maybe it really should be something like i686-pc-mingw32-cygwin. Bleah. >Say, where do you change gcc(2.95.3) so that g++-2 links against >libstdc++-2.a instead of libstdc++.a? (Ditto g77). It doesn't seem to >be in the specs file, so I dunno WHERE that is done... It is in the last two lines of the specs file: #define LIBSTDCXX "-lstdc++-2" #define FORTRAN_LIBRARY "-lg2c-2" The files themselves get munged by mknetrel's extra/gcc2 script. Btw, I moved that libstdc++.a.whatever file out of /usr/lib for the next release. Although, actually, if I had just moved it into the /usr/i686-pc-cygwin/lib directory, I might not have had to add the -2 part. Argh. Not going to change it now... cgf (Who's off for the 4000th rebuild of these packages...) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-12 1:32 ` Christopher Faylor @ 2002-07-12 2:54 ` Charles Wilson 2002-07-12 4:40 ` Christopher Faylor 0 siblings, 1 reply; 30+ messages in thread From: Charles Wilson @ 2002-07-12 2:54 UTC (permalink / raw) To: cygwin Christopher Faylor wrote: > On Fri, Jul 12, 2002 at 12:33:31AM -0400, Charles Wilson wrote: > >>'Course, for my cygwin-host, mingw-target cross compiler, I'll need to >>respin >>it so that it coexists with the official gcc and gcc2 and gcc-mingw >>packages...sigh. >> > > Do you need this anymore, though? Perhaps not. It was really just an experiment: everybody including me has been claiming that "just build a real cross-compiler; that's 'the right way to do it'" so I gave it a shot. It wasn't as easy as everyone thought. Lots of weirdness (mostly in directory layout) to make it coexist peacefully with the mingw bits of cygwin. > You could get by with this, couldn't > you: > > i686-pc-mingw32-gcc is: > #!/bin/sh > gcc -mno-cygwin $(@+"$@"} Probably. > > Or, should I not be coopting the i686-pc-mingw32 target directory? > Maybe it really should be something like i686-pc-mingw32-cygwin. Bleah. No, I think you made the right choice. Besides, my cross compiler goes into /opt/mingw/* -- so no conflict there. Also, if one were to install mingw itself, it goes into /mingw. >>Say, where do you change gcc(2.95.3) so that g++-2 links against >>libstdc++-2.a instead of libstdc++.a? (Ditto g77). It doesn't seem to >>be in the specs file, so I dunno WHERE that is done... >> > > It is in the last two lines of the specs file: > > #define LIBSTDCXX "-lstdc++-2" > #define FORTRAN_LIBRARY "-lg2c-2" I'll look for it -- it's not in my "normal" sources, so I guess normal sources use a default definition from somewhere else. I'll download your gcc2-src package and use that... > The files themselves get munged by mknetrel's extra/gcc2 script. Ah. But if you munge the filenames at install time, then don't stage2 and stage3 break? > Btw, I moved that libstdc++.a.whatever file out of /usr/lib for the next > release. Although, actually, if I had just moved it into the > /usr/i686-pc-cygwin/lib directory, I might not have had to add the -2 > part. Argh. Not going to change it now... Agreed -- I actually LIKE the -2 distinction. > > cgf > (Who's off for the 4000th rebuild of these packages...) <groan> --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-12 2:54 ` Charles Wilson @ 2002-07-12 4:40 ` Christopher Faylor 2002-07-12 9:22 ` Charles Wilson 0 siblings, 1 reply; 30+ messages in thread From: Christopher Faylor @ 2002-07-12 4:40 UTC (permalink / raw) To: cygwin On Fri, Jul 12, 2002 at 01:14:20AM -0400, Charles Wilson wrote: >>It is in the last two lines of the specs file: >> >>#define LIBSTDCXX "-lstdc++-2" >>#define FORTRAN_LIBRARY "-lg2c-2" > > >I'll look for it -- it's not in my "normal" sources, so I guess normal >sources use a default definition from somewhere else. I'll download >your gcc2-src package and use that... The gcc-2.95.3 that I distribute has a lot of gcc/mingw changes. Many of them come from Mumit. So, if you grab "my" package you get something that is different from the sources at gcc.gnu.org. >>The files themselves get munged by mknetrel's extra/gcc2 script. > >Ah. But if you munge the filenames at install time, then don't stage2 >and stage3 break? I copy around stuff by hand for the first stage (building the cross compiler). I don't build a native compiler first, so there are only two stages. And, yes, copying stuff around by hand is a real pain... >>(Who's off for the 4000th rebuild of these packages...) > > ><groan> I'm on 4001 now. Forgot to merge with the current gcc branch. Looked like an possible code gen bug got fixed. Thank god for ccache, though. I'd still be scratching my head about the best way to deal with -mno-cygwin if it wasn't for that. It's really amazing. Oops. Forgot to regen stage one for this go-around. That would screw up the specs file. Time for build 4002 and 4003. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-12 4:40 ` Christopher Faylor @ 2002-07-12 9:22 ` Charles Wilson 2002-07-12 18:46 ` Christopher Faylor 0 siblings, 1 reply; 30+ messages in thread From: Charles Wilson @ 2002-07-12 9:22 UTC (permalink / raw) To: cygwin Christopher Faylor wrote: > On Fri, Jul 12, 2002 at 01:14:20AM -0400, Charles Wilson wrote: > >>>It is in the last two lines of the specs file: >>> >>>#define LIBSTDCXX "-lstdc++-2" >>>#define FORTRAN_LIBRARY "-lg2c-2" >>> >> >>I'll look for it -- it's not in my "normal" sources, so I guess normal >>sources use a default definition from somewhere else. I'll download >>your gcc2-src package and use that... >> > > The gcc-2.95.3 that I distribute has a lot of gcc/mingw changes. Many > of them come from Mumit. So, if you grab "my" package you get something > that is different from the sources at gcc.gnu.org. > Well, I guess "normal" wasn't the correct term. I'm using Danny's gcc-2.95.3 -src package from mingw.org (seemed appropriate since I was building a mingw-target compiler). I'm unsure how large the differences are between your version and Danny's (of 2.95.3). I guess I'll find out... >>>The files themselves get munged by mknetrel's extra/gcc2 script. >>> >>Ah. But if you munge the filenames at install time, then don't stage2 >>and stage3 break? >> > > I copy around stuff by hand for the first stage (building the cross > compiler). I don't build a native compiler first, so there are only > two stages. > > And, yes, copying stuff around by hand is a real pain... As in, "a PITA to maintain". Hopefully, gcc2 will be a "release and forget" package. > I'm on 4001 now. Forgot to merge with the current gcc branch. Looked > like an possible code gen bug got fixed. > > Thank god for ccache, though. I'd still be scratching my head about the > best way to deal with -mno-cygwin if it wasn't for that. It's really > amazing. > > Oops. Forgot to regen stage one for this go-around. That would screw > up the specs file. Time for build 4002 and 4003. <Argh!> Sounds very frustrating. Thanks for all your hard work -- and take care of your hands. --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-12 9:22 ` Charles Wilson @ 2002-07-12 18:46 ` Christopher Faylor 0 siblings, 0 replies; 30+ messages in thread From: Christopher Faylor @ 2002-07-12 18:46 UTC (permalink / raw) To: cygwin On Fri, Jul 12, 2002 at 11:30:54AM -0400, Charles Wilson wrote: > > >Christopher Faylor wrote: > >>On Fri, Jul 12, 2002 at 01:14:20AM -0400, Charles Wilson wrote: >> >>>>It is in the last two lines of the specs file: >>>> >>>>#define LIBSTDCXX "-lstdc++-2" >>>>#define FORTRAN_LIBRARY "-lg2c-2" >>>> >>> >>>I'll look for it -- it's not in my "normal" sources, so I guess normal >>>sources use a default definition from somewhere else. I'll download >>>your gcc2-src package and use that... >>> >> >>The gcc-2.95.3 that I distribute has a lot of gcc/mingw changes. Many >>of them come from Mumit. So, if you grab "my" package you get something >>that is different from the sources at gcc.gnu.org. >> > > >Well, I guess "normal" wasn't the correct term. I'm using Danny's >gcc-2.95.3 -src package from mingw.org (seemed appropriate since I was >building a mingw-target compiler). > >I'm unsure how large the differences are between your version and >Danny's (of 2.95.3). I guess I'll find out... They should be pretty close except for some cygwin additions, I would think. In the future they should be based on the same code base so they should only differ by release date. >>>>The files themselves get munged by mknetrel's extra/gcc2 script. >>>> >>>Ah. But if you munge the filenames at install time, then don't stage2 >>>and stage3 break? >>> >> >>I copy around stuff by hand for the first stage (building the cross >>compiler). I don't build a native compiler first, so there are only >>two stages. >> >>And, yes, copying stuff around by hand is a real pain... > >As in, "a PITA to maintain". Hopefully, gcc2 will be a "release and >forget" package. That's been my assumption. If I have to do this too often, I'm going to have to find some way of automating it, that's for sure. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-12 0:31 ` Charles Wilson 2002-07-12 1:32 ` Christopher Faylor @ 2002-07-12 7:27 ` Nicholas Wourms 1 sibling, 0 replies; 30+ messages in thread From: Nicholas Wourms @ 2002-07-12 7:27 UTC (permalink / raw) To: Charles Wilson; +Cc: cygwin --- Charles Wilson <cwilson@ece.gatech.edu> wrote: > > gcc2 is supposed to be going away someday (soon). > > > As long as there are (supported) C++ libraries that use the 2.95.3 ABI, > we'll need gcc2. E.g. libncurses6++, and the others that were > mentioned onlist, unless gcc-3.1.1 goes gold before they do. I have to agree with Chuck on this one, we shouldn't be so ready to say gcc2 will go away soon. I don't think people realize how much of a PITA it is to re-port applications that are intertwined with libstc++v2'ism to a ISO/C++ compliant version which will compile against libstc++v3. Let me say that it is *NOT* fun, especially when it requires 100's if not 1000's of lines of changes in code. I'm for keeping it as you currently have it, an optional package, but there for backwards compatibility. I guess all I'm saying is that we should considier gcc2, once it goes gold, to be like perl-5.005, frozen for features but still updatable for major bugs. Cheers, Nicholas __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-11 3:47 ` Charles Wilson 2002-07-11 3:49 ` Charles Wilson 2002-07-11 10:19 ` Christopher Faylor @ 2002-07-15 0:55 ` Charles Wilson 2002-07-15 1:09 ` Christopher Faylor 2 siblings, 1 reply; 30+ messages in thread From: Charles Wilson @ 2002-07-15 0:55 UTC (permalink / raw) Cc: cygwin Question about threading models for -mno-cygwin: Since the cygwin compiler is built using --enable-threads=posix, how does that affect the compiler in -mno-cygwin mode, and the mingw version of the stdc++ library in /usr/lib/mingw ? I would assume that the "normal" mingw compiler uses --enable-threads=win32. Does that mean that code (libraries) built using MINGW's g++ aren't usable by cygwin's g++ in -mno-cygwin mode (and vice versa)? Also, I've seen repeated references that "mingw's compiler will be built with dwarf2 exceptions". I assume that there are only two versions of EH code: dwarf2 and sjlj -- and you only get sjlj if you use --enable-sjlj-exceptions or somesuch? (If so, then the "regular" mingw build -- which is claimed to be use dwarf2 EH, and the cygiwn build will both have dwarf2 EH, since mknetrel/extra/gcc *doesn't* say --enable-sjlj...) Which is good. If I'm right. --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-15 0:55 ` Charles Wilson @ 2002-07-15 1:09 ` Christopher Faylor 2002-07-15 8:02 ` Nicholas Wourms 0 siblings, 1 reply; 30+ messages in thread From: Christopher Faylor @ 2002-07-15 1:09 UTC (permalink / raw) To: cygwin On Mon, Jul 15, 2002 at 12:46:17AM -0400, Charles Wilson wrote: >Question about threading models for -mno-cygwin: Threading should work correctly for either the -mno-cygwin or the -mcygwin cases. >Also, I've seen repeated references that "mingw's compiler will be built >with dwarf2 exceptions". Cygwin and mingw are using the same code base now. So both use dwarf2 exceptions. >(If so, then the "regular" mingw build -- which is claimed to be use >dwarf2 EH, and the cygiwn build will both have dwarf2 EH, since >mknetrel/extra/gcc *doesn't* say --enable-sjlj...) Which is good. If >I'm right. Right. I've actually mentioned this in a previous message and I'm sure I'll be mentioning it again. Maybe we need a GCC FAQ. Or maybe the (currently nonexistent) gcc README should mention this. FWIW, I'm on build #4010 right now. "gcc -mno-cygwin -E" wasn't working right. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-15 1:09 ` Christopher Faylor @ 2002-07-15 8:02 ` Nicholas Wourms 2002-07-15 11:56 ` Charles Wilson 0 siblings, 1 reply; 30+ messages in thread From: Nicholas Wourms @ 2002-07-15 8:02 UTC (permalink / raw) To: cygwin --- Christopher Faylor <cgf@redhat.com> wrote: > On Mon, Jul 15, 2002 at 12:46:17AM -0400, Charles Wilson wrote: > >Question about threading models for -mno-cygwin: > > Threading should work correctly for either the -mno-cygwin or the > -mcygwin > cases. > > >Also, I've seen repeated references that "mingw's compiler will be > built > >with dwarf2 exceptions". > > Cygwin and mingw are using the same code base now. So both use dwarf2 > exceptions. > > >(If so, then the "regular" mingw build -- which is claimed to be use > >dwarf2 EH, and the cygiwn build will both have dwarf2 EH, since > >mknetrel/extra/gcc *doesn't* say --enable-sjlj...) Which is good. If > >I'm right. > > Right. I've actually mentioned this in a previous message and I'm sure > I'll be mentioning it again. > > Maybe we need a GCC FAQ. Or maybe the (currently nonexistent) gcc > README > should mention this. > > FWIW, I'm on build #4010 right now. "gcc -mno-cygwin -E" wasn't working > right. > Not to presume to tell you what to do, but perhaps it might be prudent to go ahead and use the gcc-3.2 branch instead. If I read it correctly, they are planning a gcc-3.2.1 release when the gcc-3.1.2 was supposed to be released (and the webpage says GCC 3.1.2 release [Sep 15 2002]). I suppose it depends on how you look at it, but skipping to gcc-3.2 might save some headaches in regards to YA C++ ABI change. I suppose the mingw people would have to do the same, so I guess if they aren't on board then this can't be done. It may not be the best idea to release a development branch based version, but it may save many headaches in the future, especially given the fickle nature of windows shared libraries. Just my 2c on the situation... Cheers, Nicholas __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-15 8:02 ` Nicholas Wourms @ 2002-07-15 11:56 ` Charles Wilson 2002-07-15 12:36 ` Nicholas Wourms 0 siblings, 1 reply; 30+ messages in thread From: Charles Wilson @ 2002-07-15 11:56 UTC (permalink / raw) To: cygwin Nicholas Wourms wrote: > Not to presume to tell you what to do, but perhaps it might be prudent to > go ahead and use the gcc-3.2 branch instead. If I read it correctly, they > are planning a gcc-3.2.1 release when the gcc-3.1.2 was supposed to be > released (and the webpage says GCC 3.1.2 release [Sep 15 2002]). You're misreading the announement. Now, the "gcc-3.2" release will be coming from 3.1 codebase + the ABI change; nothing more. This is because the 3.2 branch has already finished its "stage 1" development, where destabilizing code is added. Therefore, what is currently known as the "gcc-3.2" branch is *unstable* and can't be released without stage 2 (two months of stabilization and bugfix) and stage 3 (two months of regression testing). So, they are simply going to rename the "gcc-3.2" branch to "gcc-3.3". There may be two sub-branches from the current 3.1 codebase: 1) what will become the new "stable" 3.2 codebase (== today's 3.1.1 + ABI changes) 2) a continuing 3.1 branch WITHOUT the ABI changes (for the poor Mac Jaguar (OS 10.2) people, who have already stabilized on 3.1 with the "bad" ABI) > I > suppose it depends on how you look at it, but skipping to gcc-3.2 might > save some headaches in regards to YA C++ ABI change. That is, we don't want to jump to "3.2" -- as it is known today. After the 3.2-->3.3; 3.1.2 --> 3.2 rename, THEN we'll want to jump to 3.2. But not until then -- because the 3.2-->3.3 codebase will be / is unstable. --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-15 11:56 ` Charles Wilson @ 2002-07-15 12:36 ` Nicholas Wourms 0 siblings, 0 replies; 30+ messages in thread From: Nicholas Wourms @ 2002-07-15 12:36 UTC (permalink / raw) To: Charles Wilson, cygwin --- Charles Wilson <cwilson@ece.gatech.edu> wrote: > Nicholas Wourms wrote: > > > Not to presume to tell you what to do, but perhaps it might be prudent > to > > go ahead and use the gcc-3.2 branch instead. If I read it correctly, > they > > are planning a gcc-3.2.1 release when the gcc-3.1.2 was supposed to be > > released (and the webpage says GCC 3.1.2 release [Sep 15 2002]). > > > You're misreading the announement. Now, the "gcc-3.2" release will be Ahhh... YA reason why you shouldn't read important announcements before the first cup of coffee. ;-) Cheers, Nicholas __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-11 2:19 Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 Christopher Faylor 2002-07-11 3:47 ` Charles Wilson @ 2002-07-11 7:19 ` Nicholas Wourms 2002-07-11 9:05 ` Christopher Faylor 2002-07-11 8:49 ` Pavel Tsekov 2 siblings, 1 reply; 30+ messages in thread From: Nicholas Wourms @ 2002-07-11 7:19 UTC (permalink / raw) To: cygwin --- Christopher Faylor <cgf@redhat.com> wrote: [SNIP] Chris, When I do gcc -v, gcc prints out the following: Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.1.1/specs Configured with: /netrel/src/gcc-3.1.1-2/configure --enable-languages=c,c++,f77,java --enable-libgcj --enable-threads=posix --with-system-zlib --enable-nls --without-included-gettext --disable-shared --enable-interpreter --disable-sjlj-exceptions --disable-version-specific-runtime-libs --build=i686-pc-linux --host=i686-pc-cygwin --target=i686-pc-cygwin --enable-haifa --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --includedir=/nonexistent/include --libexecdir=/usr/sbin : ^^^^^^^^^^^^^^^^^^^^ (reconfigured) Thread model: posix gcc version 3.1.1 20020710 (prerelease) Shouldn't that be /usr/include? The only reason I ask is because I'm quite certain that this could cause troubl in configure scripts. Like I've noticed that if I don't explicitly pass CPPFLAGS="-I/usr/include" to my configure scripts, they'll miss the limits.h in /usr/include and use the one in /usr/lib/gcc-lib/...../include/ instead. This goes for some other header detection as well. I believe it is due to the compiler's internal search paths. Just thought I'd report that observation. Cheers, Nicholas __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-11 7:19 ` Nicholas Wourms @ 2002-07-11 9:05 ` Christopher Faylor 2002-07-11 14:26 ` Nicholas Wourms 0 siblings, 1 reply; 30+ messages in thread From: Christopher Faylor @ 2002-07-11 9:05 UTC (permalink / raw) To: cygwin On Thu, Jul 11, 2002 at 06:17:51AM -0700, Nicholas Wourms wrote: > >--- Christopher Faylor <cgf@redhat.com> wrote: >[SNIP] > >Chris, > >When I do gcc -v, gcc prints out the following: > >Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.1.1/specs >Configured with: /netrel/src/gcc-3.1.1-2/configure >--enable-languages=c,c++,f77,java --enable-libgcj --enable-threads=posix >--with-system-zlib --enable-nls --without-included-gettext >--disable-shared --enable-interpreter --disable-sjlj-exceptions >--disable-version-specific-runtime-libs --build=i686-pc-linux >--host=i686-pc-cygwin --target=i686-pc-cygwin --enable-haifa --prefix=/usr >--exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib >--includedir=/nonexistent/include --libexecdir=/usr/sbin : > ^^^^^^^^^^^^^^^^^^^^ >(reconfigured) >Thread model: posix >gcc version 3.1.1 20020710 (prerelease) > >Shouldn't that be /usr/include? The only reason I ask is because I'm >quite certain that this could cause troubl in configure scripts. Like >I've noticed that if I don't explicitly pass CPPFLAGS="-I/usr/include" to >my configure scripts, they'll miss the limits.h in /usr/include and use >the one in /usr/lib/gcc-lib/...../include/ instead. This goes for some >other header detection as well. I believe it is due to the compiler's >internal search paths. Just thought I'd report that observation. This is basically the same configure script that I have been using for two years, so I doubt that it will cause problems. The limits.h file in /usr/lib/gcc-lib/../include/ *is* the one that is supposed to be used. It includes the /usr/include/limits.h file automatically. Are you saying that when I announced that the limits.h problem was fixed, I was wrong? I specifically checked the -E output from a program and saw that /usr/include/limits.h was pulled in specifically. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-11 9:05 ` Christopher Faylor @ 2002-07-11 14:26 ` Nicholas Wourms 0 siblings, 0 replies; 30+ messages in thread From: Nicholas Wourms @ 2002-07-11 14:26 UTC (permalink / raw) To: cygwin --- Christopher Faylor <cgf@redhat.com> wrote: > On Thu, Jul 11, 2002 at 06:17:51AM -0700, Nicholas Wourms wrote: > > > >--- Christopher Faylor <cgf@redhat.com> wrote: > >[SNIP] > > > >Chris, > > > >When I do gcc -v, gcc prints out the following: > > > >Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.1.1/specs > >Configured with: /netrel/src/gcc-3.1.1-2/configure > >--enable-languages=c,c++,f77,java --enable-libgcj > --enable-threads=posix > >--with-system-zlib --enable-nls --without-included-gettext > >--disable-shared --enable-interpreter --disable-sjlj-exceptions > >--disable-version-specific-runtime-libs --build=i686-pc-linux > >--host=i686-pc-cygwin --target=i686-pc-cygwin --enable-haifa > --prefix=/usr > >--exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib > >--includedir=/nonexistent/include --libexecdir=/usr/sbin : > > ^^^^^^^^^^^^^^^^^^^^ > >(reconfigured) > >Thread model: posix > >gcc version 3.1.1 20020710 (prerelease) > > > >Shouldn't that be /usr/include? The only reason I ask is because I'm > >quite certain that this could cause troubl in configure scripts. Like > >I've noticed that if I don't explicitly pass CPPFLAGS="-I/usr/include" > to > >my configure scripts, they'll miss the limits.h in /usr/include and use > >the one in /usr/lib/gcc-lib/...../include/ instead. This goes for some > >other header detection as well. I believe it is due to the compiler's > >internal search paths. Just thought I'd report that observation. > > This is basically the same configure script that I have been using for > two years, so I doubt that it will cause problems. > > The limits.h file in /usr/lib/gcc-lib/../include/ *is* the one that is > supposed to be used. It includes the /usr/include/limits.h file > automatically. > Are you saying that when I announced that the limits.h problem was > fixed, I was wrong? I specifically checked the -E output from a > program and saw that /usr/include/limits.h was pulled in specifically. Well I just nuked my cygwin directory to get rid of any "leftover" headers. The mingw and w32api include dirs were basically a mess in any event. Better to start fresh, I always say. Anyhow, after doing a fresh install, limits.h is now being picked up. Thank you Chris, and sorry for the "false" positive. Cheers, Nicholas __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-11 2:19 Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 Christopher Faylor 2002-07-11 3:47 ` Charles Wilson 2002-07-11 7:19 ` Nicholas Wourms @ 2002-07-11 8:49 ` Pavel Tsekov 2002-07-12 2:38 ` Christopher Faylor 2 siblings, 1 reply; 30+ messages in thread From: Pavel Tsekov @ 2002-07-11 8:49 UTC (permalink / raw) To: cygwin Hello Christopher, Thursday, July 11, 2002, 6:43:04 AM, you wrote: CF> Fixes in gcc2: CF> -mno-cygwin works with c++ now? I got setup.exe (2.249.2.4) to compile with that version (3.1.1-2) by making the following changes: 1. Create a symlink: lrwxrwxrwx 1 paveltz Nessuno 54 Jul 11 16:15 i686-pc-mingw32 -> /usr/ i686-pc-mingw32/include/g++-v3/mingw32 This is required because it contains the bits/ partf of libstdc++ and g++ seem to look it there. 2. Add /usr/include/mingw/g++-v3 to CXXFLAGS So finally I get this: GNU CPP version 3.1.1 20020710 (prerelease) (cpplib) (80386, BSD syntax) GNU C++ version 3.1.1 20020710 (prerelease) (i686-pc-cygwin) compiled by GNU C version 3.1.1 20020706 (prerelease). ignoring duplicate directory "/usr/i686-pc-mingw32/lib/../../include/w32api" #include "..." search starts here: #include <...> search starts here: /usr/include/mingw/g++-v3 /usr/include/w32api /usr/include/c++/3.1.1 /usr/include/c++/3.1.1/i686-pc-mingw32 /usr/include/c++/3.1.1/backward /usr/local/include /usr/lib/gcc-lib/i686-pc-cygwin/3.1.1/include /usr/i686-pc-mingw32/include /usr/include This changes and some modifications to the sources (using namespace, replacing old headers) make setup.exe build fine. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 2002-07-11 8:49 ` Pavel Tsekov @ 2002-07-12 2:38 ` Christopher Faylor 0 siblings, 0 replies; 30+ messages in thread From: Christopher Faylor @ 2002-07-12 2:38 UTC (permalink / raw) To: cygwin On Thu, Jul 11, 2002 at 05:15:51PM +0200, Pavel Tsekov wrote: >Hello Christopher, > >Thursday, July 11, 2002, 6:43:04 AM, you wrote: > >CF> Fixes in gcc2: > >CF> -mno-cygwin works with c++ now? > > >I got setup.exe (2.249.2.4) to compile with that version (3.1.1-2) by >making the following changes: > >1. Create a symlink: >lrwxrwxrwx 1 paveltz Nessuno 54 Jul 11 16:15 i686-pc-mingw32 -> /usr/ >i686-pc-mingw32/include/g++-v3/mingw32 > >This is required because it contains the bits/ partf of libstdc++ and >g++ seem to look it there. Yes, I noticed this when trying to build setup myself recently. I think something changed in the g++ include file searching between my first implementation of -mno-cygwin and now. I'll make this correction in a new gcc-mingw package. >2. Add /usr/include/mingw/g++-v3 to CXXFLAGS I may nuke g++-v3 in the next release. It looks like mingw and cygwin can share the same /usr/include/c++/3.1.1 directory. >So finally I get this: > >GNU CPP version 3.1.1 20020710 (prerelease) (cpplib) (80386, BSD syntax) >GNU C++ version 3.1.1 20020710 (prerelease) (i686-pc-cygwin) > compiled by GNU C version 3.1.1 20020706 (prerelease). >ignoring duplicate directory "/usr/i686-pc-mingw32/lib/../../include/w32api" >#include "..." search starts here: >#include <...> search starts here: > /usr/include/mingw/g++-v3 > /usr/include/w32api > /usr/include/c++/3.1.1 > /usr/include/c++/3.1.1/i686-pc-mingw32 > /usr/include/c++/3.1.1/backward > /usr/local/include > /usr/lib/gcc-lib/i686-pc-cygwin/3.1.1/include > /usr/i686-pc-mingw32/include > /usr/include > >This changes and some modifications to the sources (using namespace, >replacing old headers) make setup.exe build fine. Would you be willing to send me (in personal email) some source patches for this, so that I can try it myself? I could have sworn that I built setup with an earlier version of gcc 3.1 but it's dying in libgetopt++.a for me now. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2002-07-15 18:21 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-07-11 2:19 Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 Christopher Faylor 2002-07-11 3:47 ` Charles Wilson 2002-07-11 3:49 ` Charles Wilson 2002-07-11 6:47 ` Nicholas Wourms 2002-07-11 8:26 ` Charles Wilson 2002-07-11 20:26 ` Christopher Faylor 2002-07-11 20:50 ` Christopher Faylor 2002-07-11 10:19 ` Christopher Faylor 2002-07-11 11:56 ` Charles Wilson 2002-07-11 21:09 ` Christopher Faylor 2002-07-11 21:33 ` Unscrible--liangalei@CS.SJTU.EDU.CN liangalei 2002-07-11 23:59 ` Available for test: gcc-3.1.1-2 gcc2-2.95.3-8 Charles Wilson 2002-07-12 0:27 ` Christopher Faylor 2002-07-12 0:31 ` Charles Wilson 2002-07-12 1:32 ` Christopher Faylor 2002-07-12 2:54 ` Charles Wilson 2002-07-12 4:40 ` Christopher Faylor 2002-07-12 9:22 ` Charles Wilson 2002-07-12 18:46 ` Christopher Faylor 2002-07-12 7:27 ` Nicholas Wourms 2002-07-15 0:55 ` Charles Wilson 2002-07-15 1:09 ` Christopher Faylor 2002-07-15 8:02 ` Nicholas Wourms 2002-07-15 11:56 ` Charles Wilson 2002-07-15 12:36 ` Nicholas Wourms 2002-07-11 7:19 ` Nicholas Wourms 2002-07-11 9:05 ` Christopher Faylor 2002-07-11 14:26 ` Nicholas Wourms 2002-07-11 8:49 ` Pavel Tsekov 2002-07-12 2:38 ` Christopher Faylor
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).