Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Christopher Faylor]

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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Charles Wilson]

[-- 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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Charles Wilson]

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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Nicholas Wourms]

--- 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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Charles Wilson]

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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Christopher Faylor]

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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Christopher Faylor]

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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Christopher Faylor]

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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Charles Wilson]

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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Christopher Faylor]

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/

Unscrible--liangalei@CS.SJTU.EDU.CN

[liangalei]

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/
> 

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Charles Wilson]

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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Christopher Faylor]

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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Charles Wilson]

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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Christopher Faylor]

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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Charles Wilson]

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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Christopher Faylor]

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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Charles Wilson]

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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Christopher Faylor]

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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Nicholas Wourms]

--- 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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Charles Wilson]

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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Christopher Faylor]

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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Nicholas Wourms]

--- 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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Charles Wilson]

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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Nicholas Wourms]

--- 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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Nicholas Wourms]

--- 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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Christopher Faylor]

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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Nicholas Wourms]

--- 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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Pavel Tsekov]

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/

Re: Available for test: gcc-3.1.1-2 gcc2-2.95.3-8

[Christopher Faylor]

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/