gcc -mno-cygwin creates cygwin executables!

gcc -mno-cygwin creates cygwin executables!

[Teun Burgers]

Consider the following 3 line program:

main () {
        pthread_create();
}

This compiles and links with

gcc -mno-cygwin -o zz zz.c -lpthread

It should not link since this is part of a configure test for threads
AC_SEARCH_LIBS(pthread_create, -lpthread) that should
fail with CC='gcc -mno-cygwin'

There are 2 problems here:

1) gcc -mno-cygwin searches for libs in /usr/lib.
   Should it?

2) libpthread.a is link to libcygwin.a. If the
   thread routines were in a separate library the link
   would still fail as it should.

Teun Burgers

--
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: gcc -mno-cygwin creates cygwin executables!

[Christopher Faylor]

On Tue, Dec 11, 2001 at 06:47:09PM +0100, Teun Burgers wrote:
>1) gcc -mno-cygwin searches for libs in /usr/lib.
>   Should it?

It shouldn't, but it does.  Changing this requires a complicated change
to 'ld'.  I don't think that anyone is contemplating such a change.

The only alternative is to use the mingw version of the tools.

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: gcc -mno-cygwin creates cygwin executables!

[Teun Burgers]

David wrote:

> I must say I'm baffled by this whole thread (NPI)
> Why are you using such a lame program.

If you look at a configure script, you will find that
autoconf uses these "lame programs" to check for libraries.

> Just add
>  #include <pthread.h>
> to zz.c and everything should work as intended, no?
> If you don't do that it seems you get what you deserve.
> Am I missing something?

Yes you are :)

Teun

--
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: gcc -mno-cygwin creates cygwin executables!

[Robinow, David]

 I must say I'm baffled by this whole thread (NPI)
Why are you using such a lame program.
 Just add
  #include <pthread.h>
to zz.c and everything should work as intended, no?
 If you don't do that it seems you get what you deserve.
Am I missing something?

-----Original Message-----
From: Teun Burgers [mailto:a.rburgers@freeler.nl]
Sent: Wednesday, December 12, 2001 2:51 PM
To: cygwin@cygwin.com
Cc: Robert Collins
Subject: Re: gcc -mno-cygwin creates cygwin executables!


To sum up this thread:

consider the following program:

main () {
        pthread_create();
}

gcc -mno-cygwin -o zz.exe zz.c -lpthread will compile and build.
A cygcheck on zz.exe reveals that libcygwin.a is linked in. The
problem with this is that a configure script with CC='gcc -mno-cygwin'
will incorrectly find that libpthread.a is available with
AC_SEARCH_LIBS(pthread_create, -lpthread)


--
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: gcc -mno-cygwin creates cygwin executables!

[Robert Collins]

----- Original Message -----
From: "Teun Burgers" <a.rburgers@freeler.nl>
> 1) How about making libpthread.a a dummy library with just one .o file
>    with a dummy (empty) function? This does fix this particular
>    configure problem, but might have side effects since the pthread
> symbols
>    are no longer in libpthread.a

You already know the correct fix to this scenario. Patch ld to be able
to act like gcc with -mno-cygwin. Please don't go look for solutions
that are really just workarounds.

> 2) include the pthread symbols in both libcygwin.a and libpthread.a?

I will not support cygwin pthread functions linked statically. I should
have said that before. Those functions both depend on cygwin and are
depended on by cygwin.

> Robert Collins wrote:
>
> > Hmm. Why not put the win32 api checks in the configure script ahead
of
> > pthread?
>
> What do you mean with that?

Fix the configure script so that it checks for Win32 availability - and
thus win32 thread functions - before pthreads.

Rob


--
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: gcc -mno-cygwin creates cygwin executables!

[Steve Jorgensen]

On Wednesday, December 12, 2001 1:10 PM, Christopher Faylor 
[SMTP:cgf@redhat.com] wrote:
> On Wed, Dec 12, 2001 at 09:55:25PM +0100, Teun Burgers wrote:
> >egor duda wrote:
> >
> >> you're fixing specific symptoms instead of the problem itself. this
> >> had been discussed already and the general consensus (at least as i
> >> understand it) is the following: -mno-cygwin is a _hack_. it's
> >> supposed to be used only when absolutely necessary and when you
> >> absolutely know what you're doing.
> >
> >-mno-cygwin certainly is very good hack. I hoped I was contributing
> >to making it an even better hack.
>
> If you want to contribute to it, then contribute to what I described in
> my original message -- fix 'ld' so that it doesn't have to search 
/usr/lib
> by default.
>
> Anything else you've proposed has just been a workaround.  I am really
> not going to subvert the current cygwin DLL layout to accomodate
> -mno-cygwin.  Or, let me amend this in the usual way.  If you think that
> this is a good idea, send a patch which accomplishes your idea.
> Otherwise, I guarantee you that this idea will go nowhere.
>
> Speaking of going nowhere, -mno-cygwin is not going anywhere either.  It
> will always be around.  However, I like to dream that the only thing
> this option will do is to invoke a i686-pc-mingw32-gcc compiler.
>
> Otherwise, I fear that we'll always be suffering from cross-pollution 
from
> the cygwin libraries.
>
> Although, sadly, if cygwin and mingw exist on the same machine, we'll
> *always* be getting "bug reports" from people who complain that
> constructions like:
>
> i686-pc-mingw-gcc -o foo.exe -Ic:/cygwin/usr/include/signal.h foo.c
>
> doesn't work right!!!!
>
> >>*** if you want to build executables for mingw platform you should use
> >>mingw toolchain, either native or cross.  ***
> >
> >setup.exe is a huge success of cause and makes things very easy to
> >install.  I have never looked at the mingw toolchain, but I bet the
> >cygwin stuff is a lot easier to install.
> >
> >And with a bit of attention paid to the configure script a package can
> >build out-of-the box with gcc -mno-cygwin.  This is much better than
> >the often ill maintained mingw specific makefiles, if they are there at
> >all.
>
> That may be, but -mno-cygwin is a decidedly low-priority goal for the 
Cygwin
> project.  The primary reason is that we don't have anyone other than me
> "interested" in supporting it.

Personally, I think the hope of being able to use configure for compiling a 
native w32 executable is a very important capability to have whether it is 
through Cygwin or not.  Is that likely to be possible any other way than 
through Cygwin?  If there's a better answer on the horizon, I'd like to 
know about it.

Eventually, I'm hoping to be able to compile GNOME apps for native Windows, 
and I see anything that takes autotools out of the loop as 
counterproductive.  It would mean that I would always have to play catch-up 
to make newer versions work.

--
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: gcc -mno-cygwin creates cygwin executables!

[Christopher Faylor]

On Wed, Dec 12, 2001 at 09:55:25PM +0100, Teun Burgers wrote:
>egor duda wrote:
>
>> you're fixing specific symptoms instead of the problem itself. this
>> had been discussed already and the general consensus (at least as i
>> understand it) is the following: -mno-cygwin is a _hack_. it's
>> supposed to be used only when absolutely necessary and when you
>> absolutely know what you're doing.
>
>-mno-cygwin certainly is very good hack. I hoped I was contributing
>to making it an even better hack.

If you want to contribute to it, then contribute to what I described in
my original message -- fix 'ld' so that it doesn't have to search /usr/lib
by default.

Anything else you've proposed has just been a workaround.  I am really
not going to subvert the current cygwin DLL layout to accomodate
-mno-cygwin.  Or, let me amend this in the usual way.  If you think that
this is a good idea, send a patch which accomplishes your idea.
Otherwise, I guarantee you that this idea will go nowhere.

Speaking of going nowhere, -mno-cygwin is not going anywhere either.  It
will always be around.  However, I like to dream that the only thing
this option will do is to invoke a i686-pc-mingw32-gcc compiler.

Otherwise, I fear that we'll always be suffering from cross-pollution from
the cygwin libraries.

Although, sadly, if cygwin and mingw exist on the same machine, we'll
*always* be getting "bug reports" from people who complain that
constructions like:

i686-pc-mingw-gcc -o foo.exe -Ic:/cygwin/usr/include/signal.h foo.c

doesn't work right!!!!

>>*** if you want to build executables for mingw platform you should use
>>mingw toolchain, either native or cross.  ***
>
>setup.exe is a huge success of cause and makes things very easy to
>install.  I have never looked at the mingw toolchain, but I bet the
>cygwin stuff is a lot easier to install.
>
>And with a bit of attention paid to the configure script a package can
>build out-of-the box with gcc -mno-cygwin.  This is much better than
>the often ill maintained mingw specific makefiles, if they are there at
>all.

That may be, but -mno-cygwin is a decidedly low-priority goal for the Cygwin
project.  The primary reason is that we don't have anyone other than me
"interested" in supporting 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: gcc -mno-cygwin creates cygwin executables!

[Teun Burgers]

egor duda wrote:

> you're fixing specific symptoms instead of the problem itself. this
> had been discussed already and the general consensus (at least as i
> understand it) is the following: -mno-cygwin is a _hack_. it's
> supposed to be used only when absolutely necessary and when you
> absolutely know what you're doing.

-mno-cygwin certainly is very good hack. I hoped I was contributing
to making it an even better hack.

> *** if you want to build executables for mingw platform you should use
> mingw toolchain, either native or cross. ***

setup.exe is a huge success
of cause and makes things very easy to install. I have never looked at
the mingw toolchain, but I bet the cygwin stuff is a lot easier to
install.

And with a bit of attention paid to the configure script a package can
build
out-of-the box with gcc -mno-cygwin. This is much better than the often
ill maintained mingw specific makefiles, if they are there at all.

> you don't suppose cygwin gcc to have -msolaris or -mdjgpp options, do
> you? i believe mingw is no different.

-msolaris not, since you can buy a solaris box. djgpp comes with
a bash port and so you can run configure scripts on djgpp natively.
No need for -mdjgpp, though it would be nice to have that :)
I am not aware of a bash port for mingw. So for configure scripts
you need cygwin as host.

> the reason -mno-cygwin still exists in official cygwin gcc is that
> cygwin contains several utilities that should not depend on
> cygwin1.dll (setup, cygcheck, strace). those utilities are built with
> -mno-cygwin and people maintaining them take special care to make sure
> libcygwin.a won't creep in.

I would certainly hope that gcc -mno-cygwin is developed further. For
one
thing it would be nice if mingw libraries (as available at
gnuwin32.sourceforge.net)
could be installed through setup.exe.

Teun Burgers

--
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: gcc -mno-cygwin creates cygwin executables!

[egor duda]

Hi!

Wednesday, 12 December, 2001 Teun Burgers a.rburgers@freeler.nl wrote:

TB> To sum up this thread:
TB> consider the following program:

TB> main () {
TB>         pthread_create();
TB> }

TB> gcc -mno-cygwin -o zz.exe zz.c -lpthread will compile and build.
TB> A cygcheck on zz.exe reveals that libcygwin.a is linked in. The
TB> problem with this is that a configure script with CC='gcc -mno-cygwin'
TB> will incorrectly find that libpthread.a is available with
TB> AC_SEARCH_LIBS(pthread_create, -lpthread)

TB> This comes about since gcc -mno-cygwin searches for libs in /usr/lib
TB> and libpthread.a is a symlink to libcygwin.a

you're fixing specific symptoms instead of the problem itself. this
had been discussed already and the general consensus (at least as i
understand it) is the following: -mno-cygwin is a _hack_. it's
supposed to be used only when absolutely necessary and when you
absolutely know what you're doing.

*** if you want to build executables for mingw platform you should use
mingw toolchain, either native or cross. ***

you don't suppose cygwin gcc to have -msolaris or -mdjgpp options, do
you? i believe mingw is no different.

the reason -mno-cygwin still exists in official cygwin gcc is that
cygwin contains several utilities that should not depend on
cygwin1.dll (setup, cygcheck, strace). those utilities are built with
-mno-cygwin and people maintaining them take special care to make sure
libcygwin.a won't creep in.

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19


--
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: gcc -mno-cygwin creates cygwin executables!

[Teun Burgers]

To sum up this thread:

consider the following program:

main () {
        pthread_create();
}

gcc -mno-cygwin -o zz.exe zz.c -lpthread will compile and build.
A cygcheck on zz.exe reveals that libcygwin.a is linked in. The
problem with this is that a configure script with CC='gcc -mno-cygwin'
will incorrectly find that libpthread.a is available with
AC_SEARCH_LIBS(pthread_create, -lpthread)

This comes about since gcc -mno-cygwin searches for libs in /usr/lib
and libpthread.a is a symlink to libcygwin.a

One way to fix this would be to break out the thread functions of
libcygwin.a into a separate libpthread.a. When you then link with
gcc -mno-cygwin, libcygwin.a is not linked in and the link will fail.
Apparantly for performance and technical reasons this is not
recommendable.
This has to do with libcygwin.a depending on the pthread functions.

Another would be to put the libpthread.a symlink in a directory that gcc
-mno-cygwin
doesn't search, e.g. /usr/lib/cygwin, and add this library to the specs
for cygwin
links.
What would be the problem with this approach?

There are 2 other alternatives that fix the configure problem:

1) How about making libpthread.a a dummy library with just one .o file
   with a dummy (empty) function? This does fix this particular
   configure problem, but might have side effects since the pthread
symbols
   are no longer in libpthread.a

2) include the pthread symbols in both libcygwin.a and libpthread.a?

Robert Collins wrote:

> Hmm. Why not put the win32 api checks in the configure script ahead of
> pthread?

What do you mean with that?

Teun

--
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: gcc -mno-cygwin creates cygwin executables!

[Robert Collins]

----- Original Message -----
From: "a.rburgers" <a.rburgers@freeler.nl>
> > If you want a mingw pthread library see the pthread-win32 project.
>
> I don't want to force the user to install pthread-win32.
> I want this configure script (for fltk btw) to detect correctly
whether
> threads
> are available or not.

Hmm. Why not put the win32 api checks in the configure script ahead of
pthread?

> > > 2) Put some cygwin specific libraries as libpthread.a in
> > /usr/cygwin/lib
> > > and add /usr/cygwin/lib to the specs?
>
> > This _might_ do it. Still it requires breaking out the pthread
> > functions, for little benefit and greater overhead.
>
> I don't see the problem with this. We are not adding libraries as
libpng
> and libjpeg to libcygwin either are we?

cygwin doesn't depend on jpeg or png, it does on pthreads.

> > Why not add the
> > win32-pthread functions somewhere and add that to the -mno-cygwin
specs?
>
> You mean adding the win32-pthread functions to the standard cygwin
mingw
> distribution?
> That would be perfect of cause!

See http://www.cygwin.com/setup.html. You're more than welcome to
contribute such a package, and I'd support it's inclusion - as long as
it is done carefully so as not to confuse folk who are not
using -mno-cygwin.

Rob


--
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: gcc -mno-cygwin creates cygwin executables!

[a.rburgers]

Rob Collins wrote:

> > 1) Move the pthread functions from libcygwin.a to a separate library
> > libpthread.a instead of libpthread.a being a symlink to libcygwin.a.
> > That
> > would fix this particular configure problem I think. This already
> > works this way I found for libpng.a and libjpeg.a.

> No, as the pthread functions use cygwin calls that will still link to
> cygwin.

Yes! Since if you use gcc without -mno-cygwin, libcygwin.a is linked in 
anyway,
as is the case now with for instance libpng.a and libjpeg.a.

I only want the link to fail when you use gcc -mno-cygwin. It doesn't now
since linking with -lpthread links in all of libcygwin.a

> If you want a mingw pthread library see the pthread-win32 project.

I don't want to force the user to install pthread-win32.
I want this configure script (for fltk btw) to detect correctly whether 
threads
are available or not.

> > 2) Put some cygwin specific libraries as libpthread.a in
> /usr/cygwin/lib
> > and add /usr/cygwin/lib to the specs?

> This _might_ do it. Still it requires breaking out the pthread
> functions, for little benefit and greater overhead.

I don't see the problem with this. We are not adding libraries as libpng
and libjpeg to libcygwin either are we?

> Why not add the
> win32-pthread functions somewhere and add that to the -mno-cygwin specs?

You mean adding the win32-pthread functions to the standard cygwin mingw 
distribution?
That would be perfect of cause!

Teun


--
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: gcc -mno-cygwin creates cygwin executables!

[Robert Collins]

===
----- Original Message -----
From: "Teun Burgers" <a.rburgers@freeler.nl>
To: <cygwin@cygwin.com>
Sent: Wednesday, December 12, 2001 8:02 AM
Subject: Re: gcc -mno-cygwin creates cygwin executables!


> Christopher Faylor wrote:
>
> >  On Tue, Dec 11, 2001 at 06:47:09PM +0100, Teun Burgers wrote:
> > >1) gcc -mno-cygwin searches for libs in /usr/lib.
> > >   Should it?
>
> > It shouldn't, but it does.  Changing this requires a complicated
change
> > to 'ld'.  I don't think that anyone is contemplating such a change.
> >
> > The only alternative is to use the mingw version of the tools.
>
> I can think of a few other perhaps simpler alternatives.
>
> 1) Move the pthread functions from libcygwin.a to a separate library
> libpthread.a instead of libpthread.a being a symlink to libcygwin.a.
> That
> would fix this particular configure problem I think. This already
> works this way I found for libpng.a and libjpeg.a.

No, as the pthread functions use cygwin calls that will still link to
cygwin. If you wnat a mingw pthread library see the pthread-win32
project.

> 2) Put some cygwin specific libraries as libpthread.a in
/usr/cygwin/lib
> and add /usr/cygwin/lib to the specs?

This _might_ do it. Still it requires breaking out the pthread
functions, for little benefit and greater overhead. Why not add the
win32-pthread functions somewhere and add that to the -mno-cygwin specs?

Rob


--
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: gcc -mno-cygwin creates cygwin executables!

[Teun Burgers]

Christopher Faylor wrote:

>  On Tue, Dec 11, 2001 at 06:47:09PM +0100, Teun Burgers wrote:
> >1) gcc -mno-cygwin searches for libs in /usr/lib.
> >   Should it?

> It shouldn't, but it does.  Changing this requires a complicated change
> to 'ld'.  I don't think that anyone is contemplating such a change.
>
> The only alternative is to use the mingw version of the tools.

I can think of a few other perhaps simpler alternatives.

1) Move the pthread functions from libcygwin.a to a separate library
libpthread.a instead of libpthread.a being a symlink to libcygwin.a.
That
would fix this particular configure problem I think. This already
works this way I found for libpng.a and libjpeg.a.

2) Put some cygwin specific libraries as libpthread.a in /usr/cygwin/lib
and add /usr/cygwin/lib to the specs?

Teun Burgers

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