gcc2-2.95.3-7 uploaded

gcc2-2.95.3-7 uploaded

[Christopher Faylor]

This should fix the problem with finding libstdc++.a.  For the record,
libstdc++.a has been renamed to libstdc++-2.a in this package.  I've
used this version to successfully compile Chuck's test case (thanks
again, Chuck).

This release also includes a couple of spec file tweaks (adds
libmingwex.a to the -mno-cygwin case) and it includes g77-2.exe.
g77-2.exe is completely untested, however.  And, it will always be thus.

I'm still working on rebuilding gcc3.  Getting libjava built is turning
out to be quite a challenge.  Of course, once I get it built, it
probably won't work anyway, but one challenge at a time.

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: gcc2-2.95.3-7 uploaded

[Bobby McNulty Junior]

Looking for it.
Great job Christopher.



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

suggestion for compiling libjava [was Re: gcc2-2.95.3-7 uploaded]

[Nicholas Wourms]

--- Christopher Faylor <cgf@redhat.com> wrote:
> This should fix the problem with finding libstdc++.a.  For the record,
> libstdc++.a has been renamed to libstdc++-2.a in this package.  I've
> used this version to successfully compile Chuck's test case (thanks
> again, Chuck).
> 
> This release also includes a couple of spec file tweaks (adds
> libmingwex.a to the -mno-cygwin case) and it includes g77-2.exe.
> g77-2.exe is completely untested, however.  And, it will always be thus.
> 
> I'm still working on rebuilding gcc3.  Getting libjava built is turning
> out to be quite a challenge.  Of course, once I get it built, it
> probably won't work anyway, but one challenge at a time.

Chris,

As I mentioned before, libjava is *NOT* properly detecting header files
and libraries, and is thus not defining half the includes it should define
in the autoheader file.  You *HAVE* to go into libjava/config/ and hand
verifying the contents, line-by-line, of the .h file generated by
configure.  Otherwise you will be getting compile-time errors to no end. 
Also, the install script is not recognizing .exe extentions properly, so
you may have to tweak it.  This is what I had to do to get libjava to
compile on my system, that and the exceptions I mentioned in my previous
email.  Hope this helps.  For the benefit of the archives, if you are
compiling libgcj in cygwin you must use CYGWIN=check_case:strict,
otherwise the java libraries won't get built.

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: gcc2-2.95.3-7 uploaded

[Charles Wilson]

[-- Attachment #1: Type: text/plain, Size: 4232 bytes --]

Christopher Faylor wrote:

> This should fix the problem with finding libstdc++.a.  For the record,
> libstdc++.a has been renamed to libstdc++-2.a in this package.  I've
> used this version to successfully compile Chuck's test case (thanks
> again, Chuck).


All of the small test programs in dllhelpers (0.4.0, but modified 
slightly; new release soon) compile with this release; all you have to 
do is 'export CC=gcc-2; export CXX=g++-2; export FC=g77-2' and you're 
golden.

This includes C, C++, and Fortran tests -- as well as autotool-driven 
tests.  And yes, they do link with the "correct" libstdc++ library.

A few nits: the info files are fouled up.  For some reason, all of the 
internal references are to e.g. 'gcc-2-2.info' instead of 'gcc-2.info' 
Once I ran them all thru a sed script  --- and fixed up the dir file -- 
all was well.


> This release also includes a couple of spec file tweaks (adds
> libmingwex.a to the -mno-cygwin case) and it includes g77-2.exe.
> g77-2.exe is completely untested, however.  And, it will always be thus.


*I* briefly tested g77-2.  It worked for me; YMMV.

I tested a barebones C dll with auto-import and -mno-cygwin.  It worked.

Now for the bad news...

Using the attached example, I set CXX=`pwd`/mg++  and then ran make. 
While the DLL was built correctly, I had problems compiling the usedll.c 
file:

mg++ -c -I.  -g  -o usedll.o usedll.cc
In file included from /usr/include/mingw/g++-3/streambuf.h:36,
                  from /usr/include/mingw/g++-3/iostream.h:31,
                  from /usr/include/mingw/g++-3/iostream:6,
                  from usedll.cc:1:
/usr/include/mingw/g++-3/libio.h:59: sys/cdefs.h: No such file or directory
make: *** [usedll.o] Error 1

Now, the official cygwin packages don't put anything in 
/usr/include/mingw/g++-3/ at all -- that's why we've always in the past 
had to 'cd /usr/include/mingw; ln -s ../g++-3 g++-3'.

However, I've got a "cygwin host, mingw-target" cross compiler that 
actually puts the real deal into /usr/include/mingw/g++-3 -- but, 
perhaps I have a version mismatch.  So, I  moved my custom stuff out of 
the way, created the symlink...

Unfortunately, that didn't work either.  So there's some problem with 
the C++ headers and 'g++-2 -mno-cygwin'

> I'm still working on rebuilding gcc3. 


Weeelll, using gcc-3.1.1, building the 'C' dllhelper worked fine, but 
once again, the C++ example failed:

g++ -c -I.  -g  -o usedll.o usedll.cc
usedll.cc:1:20: iostream: No such file or directory
usedll.cc: In function `int main()':
usedll.cc:10: `cout' undeclared (first use this function)
usedll.cc:10: (Each undeclared identifier is reported only once for each
    function it appears in.)
usedll.cc:11: `endl' undeclared (first use this function)
make: *** [usedll.o] Error 1

So, after doing 'export CPPFLAGS=-I/usr/include/c++/3.1.1' (*) and 
trying again, all *kinds* of terrible things happened:

g++ -c -I. -I/usr/include/c++/3.1.1 -g  -o usedll.o usedll.cc
In file included from usedll.cc:1:
/usr/include/c++/3.1.1/iostream:44:28: bits/c++config.h: No such file or 
directory
In file included from /usr/include/c++/3.1.1/ios:44,
                  from /usr/include/c++/3.1.1/ostream:45,
                  from /usr/include/c++/3.1.1/iostream:45,
                  from usedll.cc:1:
/usr/include/c++/3.1.1/iosfwd:44:28: bits/c++config.h: No such file or 
directory
In file included from /usr/include/c++/3.1.1/iosfwd:45,
                  from /usr/include/c++/3.1.1/ios:44,
                  from /usr/include/c++/3.1.1/ostream:45,
                  from /usr/include/c++/3.1.1/iostream:45,
                  from usedll.cc:1:
....(much more)....

(*) first off, that *can't* be right, can it?  shouldn't the C++ headers 
be installed in /usr/include/g++-v3/, not /usr/include/c++/3.1.1/ ?

Well, after doing a blind 'cd /usr/include; mv c++/3.1.1 g++-v3' and 
trying again, no joy with -I/usr/include/g++-v3 or without any extra -I's.

I'm stumped.

Summary:
   gcc2-2.95.3-7: gcc-2 g++-2, and g77-2 seem to work in 'cygwin' mode
     gcc-2 works in -mno-cygwin mode
     g++-2 does not  (didn't test g77-2 -mno-cygwin)
     info files scrogged
   gcc-3.1.1
     gcc seems to work
     g++ does not

--Chuck

[-- Attachment #2: cxx-2.tar.bz2 --]
[-- Type: application/octet-stream, Size: 24287 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: gcc2-2.95.3-7 uploaded

[Christopher Faylor]

On Tue, Jul 09, 2002 at 11:22:13PM -0400, Charles Wilson wrote:
>A few nits: the info files are fouled up.  For some reason, all of the 
>internal references are to e.g. 'gcc-2-2.info' instead of 'gcc-2.info' 
>Once I ran them all thru a sed script  --- and fixed up the dir file -- 
>all was well.

Sigh.  Moral of the story:  always wipe out the install directory before
rebuilding.

>Now for the bad news...
>
>Using the attached example, I set CXX=`pwd`/mg++  and then ran make. 
>While the DLL was built correctly, I had problems compiling the usedll.c 
>file:
>
>mg++ -c -I.  -g  -o usedll.o usedll.cc
>In file included from /usr/include/mingw/g++-3/streambuf.h:36,
>                 from /usr/include/mingw/g++-3/iostream.h:31,
>                 from /usr/include/mingw/g++-3/iostream:6,
>                 from usedll.cc:1:
>/usr/include/mingw/g++-3/libio.h:59: sys/cdefs.h: No such file or directory
>make: *** [usedll.o] Error 1
>
>Now, the official cygwin packages don't put anything in 
>/usr/include/mingw/g++-3/ at all -- that's why we've always in the past 
>had to 'cd /usr/include/mingw; ln -s ../g++-3 g++-3'.
>
>However, I've got a "cygwin host, mingw-target" cross compiler that 
>actually puts the real deal into /usr/include/mingw/g++-3 -- but, 
>perhaps I have a version mismatch.  So, I  moved my custom stuff out of 
>the way, created the symlink...
>
>Unfortunately, that didn't work either.  So there's some problem with 
>the C++ headers and 'g++-2 -mno-cygwin'

Ok, looks like I really did need that /usr/include/mingw/_G_config.h file.
The problem is that if I include it here for the gcc-2 compilations, it conflicts
with the version that is used in gcc 3.

This was one of those "Meant to get around to it" problems.  I shouldn't even
have released either gcc package without fixing this one.  Sigh.

>>I'm still working on rebuilding gcc3. 
>
>Weeelll, using gcc-3.1.1, building the 'C' dllhelper worked fine, but 
>once again, the C++ example failed:
>
>g++ -c -I.  -g  -o usedll.o usedll.cc
>usedll.cc:1:20: iostream: No such file or directory
>usedll.cc: In function `int main()':
>usedll.cc:10: `cout' undeclared (first use this function)
>usedll.cc:10: (Each undeclared identifier is reported only once for each
>   function it appears in.)
>usedll.cc:11: `endl' undeclared (first use this function)
>make: *** [usedll.o] Error 1
>
>So, after doing 'export CPPFLAGS=-I/usr/include/c++/3.1.1' (*) and 
>trying again, all *kinds* of terrible things happened:

>g++ -c -I. -I/usr/include/c++/3.1.1 -g  -o usedll.o usedll.cc
>In file included from usedll.cc:1:
>/usr/include/c++/3.1.1/iostream:44:28: bits/c++config.h: No such file or 
>directory
>In file included from /usr/include/c++/3.1.1/ios:44,
>                 from /usr/include/c++/3.1.1/ostream:45,
>                 from /usr/include/c++/3.1.1/iostream:45,
>                 from usedll.cc:1:
>/usr/include/c++/3.1.1/iosfwd:44:28: bits/c++config.h: No such file or 
>directory
>In file included from /usr/include/c++/3.1.1/iosfwd:45,
>                 from /usr/include/c++/3.1.1/ios:44,
>                 from /usr/include/c++/3.1.1/ostream:45,
>                 from /usr/include/c++/3.1.1/iostream:45,
>                 from usedll.cc:1:
>....(much more)....
>
>(*) first off, that *can't* be right, can it?  shouldn't the C++ headers 
>be installed in /usr/include/g++-v3/, not /usr/include/c++/3.1.1/ ?

Right this is the problem that I mentioned on Monday:

*>I don't see exactly the same errors.  I can't even compile your stuff
*>with g++.  :-( It appears to be due to --enable-version-specific-runtime-libs,
*>AFAICT.

I can fix the gcc 3 problem.  I am not sure to fix the gcc-2 problem.

*pause*

No, wait.  I think I can fix this by copying the entire g++-3 directory
into /usr/include/mingw and putting a _G_config.h there.  It isn't
pretty, but it should work ok.

Oh well, powers of two are always lucky.  Here comes gcc2-2.95.3-8.

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: gcc2-2.95.3-7 uploaded

[Charles Wilson]

Christopher Faylor wrote:


>>Unfortunately, that didn't work either.  So there's some problem with 
>>the C++ headers and 'g++-2 -mno-cygwin'
>>
> 
> Ok, looks like I really did need that /usr/include/mingw/_G_config.h file.
> The problem is that if I include it here for the gcc-2 compilations, it conflicts
> with the version that is used in gcc 3.


Ooo.  Not good.

 
> This was one of those "Meant to get around to it" problems.  I shouldn't even
> have released either gcc package without fixing this one.  Sigh.


Hey, this is what *test* releases are FOR.

>>(*) first off, that *can't* be right, can it?  shouldn't the C++ headers 
>>be installed in /usr/include/g++-v3/, not /usr/include/c++/3.1.1/ ?
>>
> 
> Right this is the problem that I mentioned on Monday:
> 
> *>I don't see exactly the same errors.  I can't even compile your stuff
> *>with g++.  :-( It appears to be due to --enable-version-specific-runtime-libs,
> *>AFAICT.


Oh - I saw "version-specific-runtime-LIBS" and didn't make the 
connection to header files.  Duh.

> I can fix the gcc 3 problem.  I am not sure to fix the gcc-2 problem.
> 
> *pause*
> 
> No, wait.  I think I can fix this by copying the entire g++-3 directory
> into /usr/include/mingw and putting a _G_config.h there.  It isn't
> pretty, but it should work ok.
> 
> Oh well, powers of two are always lucky.  Here comes gcc2-2.95.3-8.


Fingers crossed.

BTW, was I correct about the C++ ABI?  Currently, the only DLL with true 
C++ exports(*) is libncurses6++; will that be usable with gcc-3.1.1, or 
will I need to release a new version?

(*) cygwin itself is the only other C++ DLL -- but all of its exports 
are non-mangled...

--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: gcc2-2.95.3-7 uploaded

[Charles Wilson]

Christopher Faylor wrote:


>>Unfortunately, that didn't work either.  So there's some problem with 
>>the C++ headers and 'g++-2 -mno-cygwin'
>>
> 
> Ok, looks like I really did need that /usr/include/mingw/_G_config.h file.
> The problem is that if I include it here for the gcc-2 compilations, it conflicts
> with the version that is used in gcc 3.


Ooo.  Not good.

 
> This was one of those "Meant to get around to it" problems.  I shouldn't even
> have released either gcc package without fixing this one.  Sigh.


Hey, this is what *test* releases are FOR.

>>(*) first off, that *can't* be right, can it?  shouldn't the C++ headers 
>>be installed in /usr/include/g++-v3/, not /usr/include/c++/3.1.1/ ?
>>
> 
> Right this is the problem that I mentioned on Monday:
> 
> *>I don't see exactly the same errors.  I can't even compile your stuff
> *>with g++.  :-( It appears to be due to --enable-version-specific-runtime-libs,
> *>AFAICT.


Oh - I saw "version-specific-runtime-LIBS" and didn't make the 
connection to header files.  Duh.

> I can fix the gcc 3 problem.  I am not sure to fix the gcc-2 problem.
> 
> *pause*
> 
> No, wait.  I think I can fix this by copying the entire g++-3 directory
> into /usr/include/mingw and putting a _G_config.h there.  It isn't
> pretty, but it should work ok.
> 
> Oh well, powers of two are always lucky.  Here comes gcc2-2.95.3-8.


Fingers crossed.

BTW, was I correct about the C++ ABI?  Currently, the only DLL with true 
C++ exports(*) is libncurses6++; will that be usable with gcc-3.1.1, or 
will I need to release a new version?

(*) cygwin itself is the only other C++ DLL -- but all of its exports 
are non-mangled...

--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: gcc2-2.95.3-7 uploaded

[Nicholas Wourms]

--- Charles Wilson <cwilson@ece.gatech.edu> wrote:
> (*) cygwin itself is the only other C++ DLL -- but all of its exports 
> are non-mangled...

Are you forgetting about the db3.x/db4.x c++ api?  I'm revving up to
release v3 next week, but I need to know if this will cause it problems.

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: gcc2-2.95.3-7 uploaded

[Charles Wilson]

Nicholas Wourms wrote:

> --- Charles Wilson <cwilson@ece.gatech.edu> wrote:
> 
>>(*) cygwin itself is the only other C++ DLL -- but all of its exports 
>>are non-mangled...
>>
> 
> Are you forgetting about the db3.x/db4.x c++ api?  I'm revving up to
> release v3 next week, but I need to know if this will cause it problems.


They aren't "out" yet.  So I didn't mention them.  If one or both are 
released before gcc-3.1.1 becomes official, then yes, they should also 
be added to the "Maybe a c++ ABI problem" list.

--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: gcc2-2.95.3-7 uploaded

[Charles Wilson]

Nicholas Wourms wrote:

> --- Charles Wilson <cwilson@ece.gatech.edu> wrote:
> 
>>(*) cygwin itself is the only other C++ DLL -- but all of its exports 
>>are non-mangled...
>>
> 
> Are you forgetting about the db3.x/db4.x c++ api?  I'm revving up to
> release v3 next week, but I need to know if this will cause it problems.


They aren't "out" yet.  So I didn't mention them.  If one or both are 
released before gcc-3.1.1 becomes official, then yes, they should also 
be added to the "Maybe a c++ ABI problem" list.

--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: gcc2-2.95.3-7 uploaded

[Gareth Pearce]

----- Original Message -----
From: "Charles Wilson" <cwilson@ece.gatech.edu>
Newsgroups: gmane.os.cygwin
To: <cygwin@cygwin.com>
Sent: Thursday, July 11, 2002 3:35 AM
Subject: Re: gcc2-2.95.3-7 uploaded


>
>
> Nicholas Wourms wrote:
>
> > --- Charles Wilson <cwilson@ece.gatech.edu> wrote:
> >
> >>(*) cygwin itself is the only other C++ DLL -- but all of its exports
> >>are non-mangled...
> >>
> >
> > Are you forgetting about the db3.x/db4.x c++ api?  I'm revving up to
> > release v3 next week, but I need to know if this will cause it problems.
>
>
> They aren't "out" yet.  So I didn't mention them.  If one or both are
> released before gcc-3.1.1 becomes official, then yes, they should also
> be added to the "Maybe a c++ ABI problem" list.
>

My worthless 2 cents - since the default compiler is going to be 3.1.1, all
nesecery packages should be recompiled for it. If compiler was going to be
named g++-3 or similar, then maybe there would be a question.

Gareth

--
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: gcc2-2.95.3-7 uploaded

[Christopher Faylor]

On Wed, Jul 10, 2002 at 11:00:47AM -0400, Charles Wilson wrote:
>BTW, was I correct about the C++ ABI?  Currently, the only DLL with true 
>C++ exports(*) is libncurses6++; will that be usable with gcc-3.1.1, or 
>will I need to release a new version?

I really don't know.  The ABI is different so I would assume that if you're
exporting C++ functions you'll need a new release.

And, just for fun, it looks like the ABI will change slightly in gcc 3.2,
too.

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/