This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: Gcc 3.2 -mno-cygwin
- From: "Paul G." <pgarceau at attbi dot com>
- To: <cygwin-apps at cygwin dot com>, <nasm-devel at lists dot sourceforge dot net>
- Date: Sun, 15 Dec 2002 15:18:00 -0800
- Subject: Re: Gcc 3.2 -mno-cygwin
- Organization: Paul G.
- Reply-to: pgarceau at attbi dot com
Hmm...
Well,
if your Win32 system doesn't support links (NT4 shortcuts), this isn't really
surprising.
NT4
has a shortcut/link capabilities that Me/Win9x do not. The same capability is built-in
to Win2k and WinXP (ie. Pro -- can't speak for Home version -- indications, however, are
that XP Home also does not support the shortcut/link capabilities that XP Pro does).
It sounds
like you have come up with a work around, but it is not recommended to hack
cygwin like that as it tends to make it unreliable.
Solution?
Upgrade OS or download and install Msys (Cygwin-like, actually a fork of
Cygwin, which does not depend on the cygwin .dll). Caveat, Mingw does not support a great
deal of posix, niether does Msys...yet.
So,
if you need posix support (if your program/app will not work without posix calls) you
might be better off not using the -mno-cygwin switch. If you're just trying to build a
non-
cygwin .dll dependant app, then you may be better off going with Msys
(http://www.mingw.org) as it does provide a minimal posix support (Msys == Minimal System
-- a "fork" of Cygwin which has absolutely no dependency on Cygwin .dll).
Paul
G.
> ----- Original
Message -----
> From: "Jim"
<jbuckeyne@greater.net>
> To: <cygwin-apps@cygwin.com>
> Sent: Sunday,
December 15, 2002 11:15 AM
> Subject: Gcc
3.2 -mno-cygwin
>
>
> > Someone
broke GCC somewhere....
> >
> > echo 'int
main( void ) { return 1; }' >test.c
> > gcc -mno-cygwin
-c test.c
> >
> > results:
> > gcc: installation
problem, cannot exec `cc1': No such file or
> > directory
> >
> > there is
definatly no cc1 with gcc 3.2 (not sure where it went,
> > but...)
> >
> > - off to
roll back to 2.95.3 or whatever...
> >
> > Jim
>
>
> Okay well this
fixes not having cc1....
>
> export PATH=$PATH:/usr/lib/gcc-lib/i686-pc-cygwin/3.2
>
> then when it
got to linking the executable...
>
> gcc -mno-cygwin
-o test test.o
>
> ld: cannot open
crt2.o: No such file or directory
>
> I certainly didn't
specify crt2.o anywhere....
>
> (for the following
assume export
> GCL=/usr/lib/gcc-lib/i686-pc-cygwin/3.2
) Hmm - patching
> /usr/lib/gcc-lib/i686-pc-cygwin/3.2/specs
...
> added
-L$GCL -L/usr/lib/mingw -L/usr/local/lib/mingw to *link:
> mno-cygwin
> rule
> modified
crt%O%s to /lib/mingw/crt2%O%s in *startfile
>
added $GCL/ before crtbegin$O$s and crtend$O$s
>
> so now it can
find all the libraries (-lgcc in $GCL) crtbegin, end
>
> and now...
> /usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a(unwind-dw2-fde.o)(.text+0
> x22c): und efined
reference to `pthread_mutex_lock' (4 times, and
> pthread_mutex_unlock
5 times)
>
> Hmm - well if
I used pthreads I guess I'd worry... but as it happens
> this test program
uses none of these.... so lets get rid of -lgcc
> (which is auspiciously
sittong out in the middle of nowhere)
>
> /usr/lib/gcc-lib/i686-pc-cygwin/3.2/crtbegin.o(.text+0x7):
undefined
> reference to
`__w32_sharedptr_initialize'
>
> The fun just
doesn't end does it? remove crtbegin.o if !mno-cygwin,
> and crtend has
missing symbols, removed that...
>
> test.o(.text+0x15):test.c:
undefined reference to `_alloca'
>
> Well heck - I
didn't even use that... but I understand - let's see -
> add -lc ?
>
> /usr/lib/gcc-lib/i686-pc-mingw32/3.2/../../../libc.a(ds00426.o)(.text+
> 0x0): multiple
definition of `atexit'
> /lib/mingw/crt2.o(.text+0x40):crt1.c:
first defined here
>
> Okay - I'm done
- this is much too twisted for my pea brain to
> comprehend...
>
>
>
> and a somewhat
off topic thread,
>
gcc -c output/whatever.c
>
> should the default
of that be output/whatever.o ? cause it's not...
>
>