As stated, the mno-cygwin flag was depreciated in gcc 4. This was what
you used to link to the windows c runtime instead of the cygwin dll. In
other words, it let you compile with cygwin gcc and then run on a
windows box that didn't have cygwin installed (very useful). Since some
of your issue seemed to be with the cygwin environment, it seemed like
detaching yourself from it at link time might be a good idea. Windows
doesn't' know or care whether the app was compiled under gcc or visual
studio if you used the no-cygwin flag, so I didn't see why it would
matter how or where you called the app, from perl, bash, cmd, etc.
I have never elevated to gcc 4 and have cygwin configured to only
install gcc 3. I am sure you could have both installed and point to one
or the other in your make file depending on what you want. If I remember
right, the no-cygwin flag was depreciated before the "ming compatible
cross compiler" was available, so I stayed with 3 at the time. I also
had issues with 4.1 under linux. I had an app would give different
floating point answers compiled wiht 4.1 compared to 3.4. This seems to
have been fixed by 4.3 and the app compiled under 4.3 gives me the same
answer as 3.4. I don't know if there was a bug in the early 4 versions,
or what. This may have been an issue with gfortran and not gcc since
it's a hybrid app.
I also like the fact that 3 is closed and they aren't constantly
changing the header files and such. It's very annoying to get code that
compiled under an older version and won't compile any more because they
changed 10 different header files and no I have to add 56 ifdef
statements to compile under the new version. Version 3.4 does everything
I need, so I have stuck with it, especially since I know how to cross
compile with it. I suppose I will get around to getting version 4
working, but I have other fish in the pan for now.
It seems like a cross compiled c app to launch your child process would
be more portable, but I will look at the perl more closely later. I'm
off to the dentist for now, fun, fun, fun.
LMH
Ted Byers wrote:
Larry Hall (Cygwin<reply-to-list-only-lh<at> cygwin.com> writes:
On 9/15/2011 1:28 PM, Ted Byers wrote:
LMH<lmh_users-groups<at> molconn.com> writes:
<snip>
What, exactly, does '-mno-cygwin' do?
BTW: With gcc v 4.5.3, using 'G++ -mno-cygwin' followed by the other
commandline arguements needed to compile something results in an error
where
it complains '-mno-cygwin' is no longer valid (I forget the exact wording,
but
that is the gist of the error message I got).
Right. '-mno-cygwin' is not a supported flag for gcc with version 4. It was
there to allow a kind of cross compiler that targets Win32 instead of
Cygwin. This is obviously not what you want anyway so it's of no
consequence to you that the flag has been removed. There are now
actual cross compilers available in Cygwin for gcc 4 that serve the purpose
of the old '-mno-cygwin' flag.
Hi Larry,
Thanks
I installed only the gcc4 compilers (all of them, v4.5.3), but I didn't even
look for cross compilers.
What is the name of the cross compilers (would they be those that
include 'mingw' in the name? Not having installed, them, perhaps this is a
naive question, but will they live alongside the gcc4 compilers without the
names of the compilers clashing? I recalled something about mingw, but
thought that was a completely different approach to having gcc on Windows, and
in the versions included with RTools, the names of the programs there would
definitely collide with those for gcc4
Thanks again
Ted
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
