Dear all,
I am trying to build gcc using cygwin on my new win64 machine.
I have downloaded the latest mingw code
(mingw-w64-trunk-snapshot-20091222.tar.bz2) and followed the instruction
in mingw-w64-howto-build.txt.
However I have the following error:
gengtype-parse.c:952: undefined reference
On Tue, Jan 12, 2010 at 03:22:24PM -, Renaud Meunier wrote:
I am trying to build gcc using cygwin on my new win64 machine.
I have downloaded the latest mingw code
(mingw-w64-trunk-snapshot-20091222.tar.bz2) and followed the instruction
in mingw-w64-howto-build.txt.
However I have the
, so
either do that on your system, too, or change all /c to /cygdrive/c.
I alias 'make' to 'mingw32-make' to hide the Cygwin make. MinGW make
has some Windows/DOS quirks in it that I happen to need. (This is why
they give it a different name, by the way.) I habitually type 'make' so
I can't
Cheers everyone for all you help and comments, it's really appreciated.
All the best
Mark
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:
On Mon, May 05, 2008 at 06:37:35PM -0700, Tim Prince wrote:
Mark Hanlon wrote:
Hello,
I am trying to building Lilypond from source using cygwin (Some parts of
the lilypond source have to be changed so that is why I can't download the
binary :(
I am using the configure script supplied
Hello,
Thanks to both of you for replying.
I had always just thought that mingw was a compiler that I could use in cygwin
environment, and that there would be some wee config trick that I could get it
to pick up flex and guile libraries.
Am I being super thick?
Cheers
Mark
On Tue, May 06, 2008 at 10:55:58PM +, Mark Hanlon wrote:
Hello,
Thanks to both of you for replying.
I had always just thought that mingw was a compiler that I could use in
cygwin environment, and that there would be some wee config trick that
I could get it to pick up flex and guile
Lovely, thanks for that, nice to feel included.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
about modifying your path it usually refers
to programs not libraries.
Your initial assumption that you could just use a mingw compiler to
produce cygwin code or that you could mix and match mingw and cygwin
libraries and objects (it isn't clear which you were assuming) is wrong
and has been
Thanks Christopher,
Sorry I did take it a wee bit personally, cheers for clarifying :)
At the moment I'm out of my depth with the whole cygwin mingw stuff.
I had thought that by modifying my etc/profile to pick up mingw istead of the
GCC bundled in cygwin I would still be able to use
Mark wrote:
At the moment I'm out of my depth with the whole cygwin mingw stuff.
I had thought that by modifying my etc/profile to pick up mingw istead of the
GCC bundled in cygwin I would still be able to use the cygwin environment but
just have mingw do the compiling (doing GCC --version
in this case.
Hi Brian,
I've been wondering about this. Why is it necessary to cross-compile
from cygwin to mingw when the cygwin environment has the native mingw
compiler? To me, it seems like if the mingw compiler is capable of
running in the build environment, it should just be called and work
Bob Rossi wrote:
I've been wondering about this. Why is it necessary to cross-compile
from cygwin to mingw when the cygwin environment has the native mingw
compiler? To me, it seems like if the mingw compiler is capable of
running in the build environment, it should just be called and work
Hello,
I am trying to building Lilypond from source using cygwin (Some parts of the
lilypond source have to be changed so that is why I can't download the binary :(
I am using the configure script supplied with Lilypond.
Unfortunately, Lilypond requires GCC 4.0 and above, so I have downloaded
Mark Hanlon wrote:
Hello,
I am trying to building Lilypond from source using cygwin (Some parts of the
lilypond source have to be changed so that is why I can't download the binary :(
I am using the configure script supplied with Lilypond.
Unfortunately, Lilypond requires GCC 4.0 and above,
Howdy all!
I am trying to build my libtool-based library package on Cygwin, with
the -mno-cygwin option.
However, I am getting the following problem:
libtool: link: cc -shared .libs/attr.o .libs/ncx.o .libs/putget.o
.libs/dim.o .libs/error.o .libs/libvers.o .libs/nc.o .libs/string.o
found by
non-Cygwin apps. A mingw DLL should be named libnetcdf-1.dll. So this
makes me think libtool is confused and thinks you're trying to build a
native package.
Second, dllcrt2.o is a mingw startup file and should be present in
/usr/lib/mingw. If not then you certainly have an installation
Hi.
I am not sure:
- are mingw* packages from cygwin the same as from mingw.org but just
adapted to fit into cygwin environment,
- or are they complete different from mingw.org?
I know that FAQ says:
This is not to be confused with 'MinGW' (Minimalist GNU for Windows),
which is a completely
of the unpacked project
I'd like to be able to build the cdrtools under mingw. Is it possible
for me to just change all references to gcc to gcc -mno-cygwin and
run make (assuming, of course that both the native cygwin and native
mingw libraries exist)?
2. Is there a one-to-one correspondence between
At 11:38 PM 4/2/2004, you wrote:
Folks,
what is the difference between vanilla mingw and the one shipped with
cygwin?
in particular, what is the difference between the gcc compiler flavors?
See http://cygwin.com/ml/cygwin/2004-04/msg00111.html.
--
Larry Hall
Folks,
what is the difference between vanilla mingw and the one shipped with
cygwin?
in particular, what is the difference between the gcc compiler flavors?
thx,
Hans
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
On 13 Oct 2003 at 23:13, Christopher Faylor wrote:
On Mon, Oct 13, 2003 at 05:35:38PM -0700, Paul G. wrote:
Mingw is not included with Msys. Msys can use and is capable of
_recognizing_, Mingw. Msys != Mingw. Msys does not need Mingw to
develop anything.
Mingw and Msys are OT for this
Edward Peschko wrote:
discourtesy expressed in your
attitude pissed me off and it is not at all professional.
CGF is not harsh, he's just trying to apply CygWin's motto WJM, in his
own personal way IDD, as he is the CygWin RCM, after all...
OK, apart from trying to break the ice (or the
On Mon, 13 Oct 2003, Edward Peschko wrote:
On Mon, Oct 13, 2003 at 10:19:08PM -0400, Christopher Faylor wrote:
[snip]
Do not send me personal email about cygwin again.
[snip]
You hold the keys to some sort of power, the power to enter the
developer's list, the power to patch cygwin
the directions. The problem was that he wanted to argue with
me when I mentioned that I didn't consider his plans to be
cygwin-developers worthy. It was pretty obvious that his knowledge base
on cygwin and mingw was missing important bits and would benefit from
some distributed disabusement
Edward Peschko wrote:
As for needing two dev environments, you been instructed how to use
cygwin to compile to both, so I must conclude you are not actually
trying to comprehend the emails, just arguing for the sake of it.
That is exactly my point. if cygwin can do both, and cygwin can create
__VERSION__ 3.2.3 (mingw special 20030504-1)
#define __declspec(x) __attribute__((x))
mingw
cygwin gcc -mno-cygwin -dM -e -xc /dev/null
cygwin
#define __DBL_MIN_EXP__ (-1021)
#define __FLT_MIN__ 1.17549435e-38F
#define _WIN32 1
#define _X86_ 1
#define __CHAR_BIT__ 8
#define
On Mon, 13 Oct 2003, Andrew DeFaria wrote:
The only way I think you can truly accomplish what you want is to
effectively do all the work that Cygwin has already done, by hand,
recoding it so as not to be stealing, and release your runtime license
free or on the Artist license like Perl. You'd
would need this magic dll but
you'd be freed from the licensing requirements.
or, basically take all the patches that mingw32 has done, and reintegrate them
into cygwin under a MINGW or NO_CYGWIN flavor.
Ed
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports
Are you just saying that the version of MingW in Cygwin is old and needs
to be patched to come up to date?
You seem to want something in the middle (which is understandable but which, AFAICT, doesn't exist). You want to be able to use a Unix-like environment and code Unix-like symantics yet produce
, October 13, 2003 3:35 PM
To: Andrew DeFaria
Cc: [EMAIL PROTECTED]
Subject: Re: merging mingw and cygwin
I, like others, think that you are just looking at this sideways. If I
compile a program with MingW it is to produce a Windows only
executable
totally unaware of Cygwin, Posix or anything
would be by merging it.
Maybe the MingW package in Cygwin needs to be updated, however, I fail
to see the need for a MINGW or NO_CYGWIN flavor aside from what
currently exists (i.e. -mno-cygwin).
Because gcc is not the only place that has MINGW-isms in it; msys departs from
the cygwin standard
for gcc and
binutils is not an iceberg.
If the large packages built in mingw are tested via mingw, then mingw is the
only real way to a 'proper' win32 executable. And the only way to truly
emulate mingw32 would be by merging it.
Wrong. I can build binutils for mingw with cygwin gcc -mno
way to truly emulate mingw32 would be by merging it.
We can speculate from now until forever but until and unless you try it
you'll never know for sure. Let us know how you make out...
Maybe the MingW package in Cygwin needs to be updated, however, I fail to see the need for a MINGW
. Coordinate
releases of mingw and cygwin, and the version issues go away.
msys != mingw. mingw doesn't need msys. Cygwin provides a more complete
building and testing environment than does msys.
... and I was told point blank by the mingw mailing list not to use them. In fact,
I did try to use
because
I have a personal bias.
.. so why not bring the nice user friendly experience of cygwin to mingw and let it
piggy back off of cygwin's work?
I guess you replied yourself, in the last paragraph...
I know nothing of MingW except what I read on this mailing list and
their website
building.
rm, ln, etc. They work differently than cygwin tools.
MINGW and/or NO_CYGWIN simply wrap all of this up in a nice user friendly
package.
Let us know how your first implementation of this concept goes...
Is this an OK from the developers of cygwin to do an implementation
On Mon, 13 Oct 2003, Edward Peschko wrote:
And anyways, the version numbers in itself are enough to warrant a
merge. Coordinate releases of mingw and cygwin, and the version issues
go away.
Cygwin itself doesn't coordinate releases. By that I mean Cygwin,
w32api, gcc, mingw gcc, etc
Brian Ford wrote:
Each is updated on its own schedule.
...which can be described as
MAX(upstream release time, next free moment of the volunteer package
mantainer) + RANDOM(-10, +100)
so it cannot be predicted, either.
It worked fairly well insofar, though.
--
Lapo 'Raist' Luchini
[EMAIL
Edward Peschko wrote:
Like I said, I'm not worried about my specific applications. I want cygwin to transparently and with no fuss - and correctly - build third party APIs, so I can properly link with them (and debug them if necessary).
All I can say is what I've heard many others say, which
is the group of tools that comes with mingw32 to facilitate building.
rm, ln, etc. They work differently than cygwin tools.
MINGW and/or NO_CYGWIN simply wrap all of this up in a nice user friendly
package.
Let us know how your first implementation of this concept goes...
Is this an OK from
On Mon, Oct 13, 2003 at 05:48:47PM -0500, Brian Ford wrote:
On Mon, 13 Oct 2003, Edward Peschko wrote:
And anyways, the version numbers in itself are enough to warrant a
merge. Coordinate releases of mingw and cygwin, and the version issues
go away.
Cygwin itself doesn't coordinate
The answer is - the Cygwin team is under no obligation to accept patches
to Cygwin to do anything. Patches are accepted and merged based on merit
of the patch and adherence with Cygwin standards. If your patch passes
these hurdles, it will be accepted. If not, it will be rejected (with
speak from experience on this,
being someone who develops
using Cygwin (with and w/o -mno-cygwin), Mingw and Msys on a very regular basis
(maintaining all of those ports for
two or three, functionally different, APIs).
Paul G.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe
On Mon, 13 Oct 2003, Edward Peschko wrote:
The answer is - the Cygwin team is under no obligation to accept patches
to Cygwin to do anything. Patches are accepted and merged based on merit
of the patch and adherence with Cygwin standards. If your patch passes
these hurdles, it will be
At 07:52 PM 10/13/2003, Edward Peschko you wrote:
The answer is - the Cygwin team is under no obligation to accept patches
to Cygwin to do anything. Patches are accepted and merged based on merit
of the patch and adherence with Cygwin standards. If your patch passes
these hurdles, it will
keeping in mind what someone else said about flame wars...
On 13 Oct 2003 at 15:45, Edward Peschko wrote:
Just because they are available does not mean you need to use them!
Look I asked you if you were able to build Windows only applications
using -mno-cygwin. You failed to answer that
Fair enough, but you *can* 'pre' approve entrance to the developer's list.
Remember, you try to subscribe and you get asked four questions?
You don't need to be on the Cygwin developers list to create patches
for Cygwin or play around with the code. Patches can be submitted either
to
At 08:44 PM 10/13/2003, Edward Peschko you wrote:
Fair enough, but you *can* 'pre' approve entrance to the developer's list.
Remember, you try to subscribe and you get asked four questions?
You don't need to be on the Cygwin developers list to create patches
for Cygwin or play around with
On Mon, Oct 13, 2003 at 05:35:38PM -0700, Paul G. wrote:
Mingw is not included with Msys. Msys can use and is capable of
_recognizing_, Mingw. Msys != Mingw. Msys does not need Mingw to
develop anything.
Mingw and Msys are OT for this list.
Bingo. Paul is right. Also Mingw doesn't need Msys
On Mon, Oct 13, 2003 at 05:48:47PM -0500, Brian Ford wrote:
On Mon, 13 Oct 2003, Edward Peschko wrote:
And anyways, the version numbers in itself are enough to warrant a
merge. Coordinate releases of mingw and cygwin, and the version issues
go away.
Cygwin itself doesn't coordinate releases
On Mon, Oct 13, 2003 at 10:19:08PM -0400, Christopher Faylor wrote:
Apparently you decided to bcc me on this email.
IIRC, I asked not to receive personal email from you on this subject. I
suggested that you continue your discussion in the cygwin mailing list
and it should be obvious to
On 2003-10-11T22:19-0700, Edward Peschko wrote:
) And all of these are done separately, so of course no integration testing is done to
) make sure that these work together well..
If you would like to coordinate such an audit/review of overall
interoperability, I do not believe anyone would
On Sun, Oct 12, 2003 at 03:35:02PM +1000, Robert Collins wrote:
For crying out loud.
Edward, there are plenty of archives and resources that detail how to
achieve your stated goals. Right now you are making suggestions from a
quite apparent position of ignorance. I urge you to research
, or if they require a POSIX sublayer. Ultimately, I'd like to use
whatever executables I get out of cygwin in conjunction with VC++ and third party
win32 APIs. (horrors!)
I'm sorry. Who said this couldn't be done with either Cygwin or Mingw?
You're seeing issues that don't exist. I guess I wasn't
.
Wayne Keen
Right.. all good points, but all minor barriers to overcome. All you would have to do
is put an 'install mingw subset' button on setup.exe, and it would well, install a
mingw
subset and put cygwin in 'mingw mode'.
It sure would beat the install process for mingw right now, which
. No fuss, no muss, relatively lightweight download.
Wayne Keen
Right.. all good points, but all minor barriers to overcome. All you would have to do
is put an 'install mingw subset' button on setup.exe, and it would well, install a
mingw
subset and put cygwin in 'mingw mode'.
Not true. Cygwin
Does the author of this reply have a problem with someone else knowing what they are
talking about?
On 12 Oct 2003 at 0:36, Christopher Faylor wrote:
On Sat, Oct 11, 2003 at 09:16:41PM -0700, Paul G. wrote:
Msys is derived from Cygwin. However, it does not have the overhead
that Cygwin
. No fuss, no muss,
relatively lightweight download.
Wayne Keen
Right.. all good points, but all minor barriers to overcome. All you
would have to do is put an 'install mingw subset' button on setup.exe,
and it would well, install a mingw subset and put cygwin in 'mingw
mode'.
It sure
On Sun, Oct 12, 2003 at 04:47:18PM -0700, Paul G. wrote:
On 12 Oct 2003 at 15:41, Edward Peschko wrote:
It sure would beat the install process for mingw right now, which is a
manual horror right now involving the download and installation of
several, separate packages in different directories.
On 12 Oct 2003 at 20:10, Christopher Faylor wrote:
On Sun, Oct 12, 2003 at 04:47:18PM -0700, Paul G. wrote:
On 12 Oct 2003 at 15:41, Edward Peschko wrote:
It sure would beat the install process for mingw right now, which is
a manual horror right now involving the download and installation
Umm..you might want to mention this on the Mingw users list...though it
appears you haven't looked at the files that are available for download
there (in terms of Mingw), specifically
http://sourceforge.net/project/showfiles.php?group_id=2435.
He already mentioned this in the mingw-users
At 08:56 PM 10/12/2003, Paul G. you wrote:
On 12 Oct 2003 at 20:10, Christopher Faylor wrote:
On Sun, Oct 12, 2003 at 04:47:18PM -0700, Paul G. wrote:
On 12 Oct 2003 at 15:41, Edward Peschko wrote:
It sure would beat the install process for mingw right now, which is
a manual horror right
At 08:16 PM 10/10/2003, Edward Peschko you wrote:
hey,
I've been playing around with mingw and cygwin, and was wondering why these were
separate
projects? I've been trying to get a unix API moved over to windows; I want a Unix
environment, but at the same time want to be able to make Win32
://cygwin.com/acronyms/#PTC if you think there's something
else that could be done to make this better. Cygwin and Mingw are both
open-source projects.
If working well together is 'remembering which of 2 gccs to use,
which of 2 rms to use which of two lns to use, which of two shells
to use, the fact
On Sat, 11 Oct 2003, Edward Peschko wrote:
(pps - 'screen' - as per 4.0.1, just gained cygwin support.
You might want to add that to your list of cygwin packages.)
I don't see any Cygwin support in 4.0.1. Where did you read it
? There's nothing in patchlevel.h (which details the changes),
On 11 Oct 2003 at 19:01, Edward Peschko wrote:
What would be the point?
lack of end-user confusion... elimination of duplicate development
effort... elimination of duplicate maintenance effort... the ability
to compile all unix tools 'native' win32 for those who desire it.
On Sat, Oct 11, 2003 at 08:16:33PM -0700, Paul G. wrote:
On 11 Oct 2003 at 19:01, Edward Peschko wrote:
What would be the point?
lack of end-user confusion... elimination of duplicate development
effort... elimination of duplicate maintenance effort... the ability
to compile all unix tools
yup.
Msys is derived from Cygwin. However, it does not have the overhead that
Cygwin does, nor does Msys
support the posix/unixy stuff that Cygwin does...nor should it.
Paul G.
On 12 Oct 2003 at 0:08, Christopher Faylor wrote:
On Sat, Oct 11, 2003 at 08:16:33PM -0700, Paul
and
rm, for example) so its hard to use one with the other; and its got to be
a maintenance nightmare to support separate patches for mingw and
separate patches for cygwin.
Mingw requires a different runtime than does Cygwin.
Mingw is short for Minimalist-Gnu for Windows. It's
you chose to edit the original context down to nothing. Your
response makes little sense now.
They already work well together. Of course,
http://cygwin.com/acronyms/#PTC if you think there's something
else that could be done to make this better. Cygwin and Mingw are both
open-source
On Sat, Oct 11, 2003 at 09:16:41PM -0700, Paul G. wrote:
Msys is derived from Cygwin. However, it does not have the overhead
that Cygwin does, nor does Msys support the posix/unixy stuff that
Cygwin does...nor should it.
You keep saying overhead as if you know what you're talking about.
Either
At 09:46 AM 11/10/2003, you wrote:
I've been playing around with mingw and cygwin, and was wondering why
these were separate
projects? I've been trying to get a unix API moved over to windows; I want
a Unix
environment,
cygwin is the answer
but at the same time want to be able to make Win32
are *much*
better)
You don't understand what the main difference is between Cygwin and Mingw
do you? Have you checked? OK, I'll tell you. Cygwin provides a POSIX
emulation layer (I assume that means something to you if your stated
yes, I understand all of this.
goal of bringing something
without the IDE then use mingw32. Although it can compile either -mconsole
programs (using printf) or -mwindows programs (using the win32 API) it's
not a *nix environment. *nix programs can't usually be compiled with it
unless they are text-only console programs. But it has many *nix
.
mingw aka the MSVCRT runtime can be cross compiled to from cygwin, from
linux, from BSD etc etc etc.
and both support native compilation (cygwin- cygwin, mingw-mingw).
As for needing two dev environments, you been instructed how to use
cygwin to compile to both, so I must conclude you
hey,
I've been playing around with mingw and cygwin, and was wondering why these were
separate
projects? I've been trying to get a unix API moved over to windows; I want a Unix
environment, but at the same time want to be able to make Win32 native binaries,
*without* the need of the cygwin
Impractical. As I said, almost 100% of people won't want 100% of packages.
It might be interesting to poll in some way, considering how often this
comes up. I suspect more than almost 0% might want a 1-button,
overnight-style install.
Frankly, this odd method only makes the slightest sense in
Richard Campbell [EMAIL PROTECTED] wrote:
Impractical. As I said, almost 100% of people won't want 100% of
packages.
It might be interesting to poll in some way, considering how often
this comes up. I suspect more than almost 0% might want a 1-button,
overnight-style install.
This doesn't
Impractical. As I said, almost 100% of people won't want 100% of
packages.
This doesn't require one big archive. There is nothing stopping anyone with
a slow but flat rate connection from running setup, choosing everything,
and
letting it get on with it.
No argument. I was just addressing the
Richard Campbell said:
It might be interesting to poll in some way, considering how often
this comes up. I suspect more than almost 0% might want a
1-button, overnight-style install.
This is the way I work. I have everything installed except emacs (I
built/installed Xemacs long before
On Thu, Dec 05, 2002 at 06:17:48PM +0100, [EMAIL PROTECTED] wrote:
On 05 Dec 2002, Brian Gallew [EMAIL PROTECTED] wrote:
Disk is cheap. Network bandwidth is cheap.
If its all so cheap then download everything and provide the service
that you want for everyone else that wants it.
I don't recall
On Fri, 2002-12-06 at 01:39, Richard Campbell wrote:
Impractical. As I said, almost 100% of people won't want 100% of packages.
It might be interesting to poll in some way, considering how often this
comes up. I suspect more than almost 0% might want a 1-button,
overnight-style install.
Robert Collins wrote:
Some back-of-a-postcard sums:
monolithic install
577MB install.
1 update to a package a week,
1 new 577MB install file created each week.
longest period without updating - 2 months.
this would mean an average of ~280MB per month downloading updates.
modular install
On Fri, 2002-12-06 at 10:30, Charles Wilson wrote:
Seems pretty clear to me, that for anyone on a slow link, or anyone
charged by volume, that the modular install is much more efficient.
Faulty analogy. Most users would probably only download the monolithic
tarball once, for their
Robert Collins wrote:
I'm not about to actively maintain two forms of setup that are so
different. And until someone offers to do that, I think it is a
reasonable assumption to make that the install form you start with you
continue with.
Errmm...I musta missed something. I wasn't suggesting
On Fri, 2002-12-06 at 11:09, Charles Wilson wrote:
Sortof. I assumed ia priori/i that a 557MB tarball is a bad idea.
Yep. And the original poster, was asserting that such a tarball is a
good idea. Thus my figures to show that it ain't - for the common case.
I was not, in any way,
Igor Gnip [EMAIL PROTECTED] wrote:
Igor Gnip [EMAIL PROTECTED] wrote... and I am replying cc:
[EMAIL PROTECTED]
1) You are highly unlikely to want to download every Cygwin package.
2) What would you do to update one package in a hypothetical
one-big-file arrangement? Download everything
Igor Gnip [EMAIL PROTECTED] wrote to
[EMAIL PROTECTED]:
I know it does not directly concern mingw-users ... but I need to
make some comparisions between mingw32 and cygwin ... and it is very
very painfull to download cygwin using their stupit web install
program.
Q: Does anyone know
I wonder if folks who ask this question fully realize the meaning of
Minimal
im MingW. The binary for MingW is about 12 megabytes at last glance.
Cygwin,
the full package runs many 100's of Megabytes. So a single archive is
plainly
untenable. The nature of Cygwin is flexible, so the setup allows
Peter A. Castro wrote:
No, the example above is from the command line in which *you*
specified -I../../include -I/usr/include -I/usr/include/mingw.
Sorry I misunderstood you.
Didn't really want to have to sign up for yet another account on
another mailing list, yadda, yadda. It seemed to
On Sun, 24 Nov 2002, Max Bowsher wrote:
Peter A. Castro [EMAIL PROTECTED] wrote:
On Sat, 23 Nov 2002, Max Bowsher wrote:
$ gcc -g foo.c -mno-cygwin -mwindows -o foo -liberty -lmingw32
$ ./foo.exe x
Hello World 2
$ cat x
Hello World
How odd. I get the stderr output just fine.
On Sun, 24 Nov 2002, Andrew DeFaria wrote:
Peter A. Castro wrote:
What you show below is only linking. I believe you need to re-compile
all of your source with -mno-cygwin -mwindows as well to make the
_impure_ptr references go away.
But I did re-compile all my sources with
On Mon, Nov 25, 2002 at 01:16:04PM -0800, Andrew DeFaria wrote:
So the question now is: How do I satisfy my need for getopt and still
produce objects without _impure_ptr's?
You find some native windows getopt, of course.
Ah ha!
Yes. Don't include the cygwin headers when you're compiling with
On Mon, 25 Nov 2002, Andrew DeFaria wrote:
Peter A. Castro wrote:
On Sun, 24 Nov 2002, Andrew DeFaria wrote:
Peter A. Castro wrote:
What you show below is only linking. I believe you need to
re-compile all of your source with -mno-cygwin -mwindows as well to
make the _impure_ptr
Peter A. Castro wrote:
On Mon, 25 Nov 2002, Andrew DeFaria wrote:
Peter A. Castro wrote:
On Sun, 24 Nov 2002, Andrew DeFaria wrote:
Peter A. Castro wrote:
What you show below is only linking. I believe you need to
re-compile all of your source with -mno-cygwin -mwindows
[one more for the archives]
On Mon, Nov 25, 2002 at 04:51:38PM -0800, Andrew DeFaria wrote:
If this were really so then why, if I don't specify -I/usr/include I get
getopt.h not found?!? I should be found in /usr/include/getopt.h no?
/usr/include is for cygwin apps. If you add -I/usr/include
Christopher Faylor wrote:
[one more for the archives]
On Mon, Nov 25, 2002 at 04:51:38PM -0800, Andrew DeFaria wrote:
If this were really so then why, if I don't specify -I/usr/include I
get getopt.h not found?!? I should be found in /usr/include/getopt.h no?
/usr/include is for cygwin
On Mon, Nov 25, 2002 at 05:42:43PM -0800, Andrew DeFaria wrote:
Christopher Faylor wrote:
[one more for the archives]
On Mon, Nov 25, 2002 at 04:51:38PM -0800, Andrew DeFaria wrote:
If this were really so then why, if I don't specify -I/usr/include I
get getopt.h not found?!? I should be found
On Mon, 25 Nov 2002, Andrew DeFaria wrote:
Christopher Faylor wrote:
[one more for the archives]
On Mon, Nov 25, 2002 at 04:51:38PM -0800, Andrew DeFaria wrote:
If this were really so then why, if I don't specify -I/usr/include I
get getopt.h not found?!? I should be found in
1 - 100 of 107 matches
Mail list logo
