Re: Potential problems with Cygwin GCC and -mno-cygwin switch
Hi, By seeing these hot discussions of -mno-cygwin swich I started a canadian cross for building a mingw hosted SH targetted cross compiler on cygwin environment. I am stuck with the following problem. Will be very thankful if anybody guides me on this? Regards, Anita - Original Message - From: anitak [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, January 09, 2002 5:22 PM Subject: libgcc1-test Error for building mingw hosted SH targetted cross compiler on cygwin hi, I am doing a canadian cross for building a mingw hosted SH targetted cross compiler on cygwin environment. I have built a cygwin to mingw and cygwin to SH cross compilers and using that to build mingw to SH cross compiler. I am using MinGW-1.1.tar.gz , mingw-runtime-1.2-1 source, w32api-1.2 source, cygwin-1.2 binutils-2.11.2+patches gcc-3.0.1patches, newlib-1.9.0patches I have built binutils successfully. For building a core compiler i.e. make LANGUAGES=c, c++ all-gcc configured with --build=i686-pc-cygwin --host=i386-pc-mingw and --target=sh-elf I get the following error - Testing libgcc1. Ignore linker warning messages.^M sh-elf-gcc -DCROSS_COMPILE -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-pro totypes -Wmiss ing-prototypes -isystem ./include libgcc1-test.o -o libgcc1-test \^M -nostartfiles -nostdlib `sh-elf-gcc --print-libgcc-file-name`^M make[1]: *** [libgcc1-test] Error 1^M I had commented USE_COLLECT2 in gcc/Makefile as suggested by Mumit Khan for collect2 problem for mingw. What steps I need to do further? Many thanks for any help Regards, Anita Kulkarni -- 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: Potential problems with cygwin GCC and -mno-cygwin switch
Soren, you may find this an interesting read. http://www.tuxedo.org/~esr/faqs/smart-questions.html. It attempts to explain some of the motivations behind a few (not all) of the brusque behaviours exhibited by many hacker communities (and those lead by hackers even if not exclusively composed thereof). (I'm not suggesting you need to read it, just that it (as a humanistic document) may interest you. 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: Potential problems with Cygwin GCC and -mno-cygwin switch
Subject: Re: Potential problems with Cygwin GCC and -mno-cygwin switch Date: Tue, 8 Jan 2002 17:29:14 -0500 From: Soren Andersen [EMAIL PROTECTED] To: [EMAIL PROTECTED] On 26 Dec 2001 at 20:33, Jon Leichter wrote: I have a couple of issues to discuss about Cygwin GCC and it's MinGW support. Before I get started, I'd like to make an observation. The MinGW web site (http://www.mingw.org/mingwfaq.shtml#faq-usingwithcygwin) suggests that: 1) MinGW support in Cygwin GCC is flaky and buggy 2) MinGW support in Cygwin GCC will possibly be deprecated I'll admit that these statements need to be restated. I don't remember if I or someone else made the statements but, these are flamitory and I apologize. Cygwin is a great tool, a lot of work has gone into it and continues to go into it on a daily basis. I certainly use it daily, I'd be lost without it. I've even contributed to Cygwin's GCC -mno-cygwin source so please don't take ill intent at these statements. I have a few observations to make about this myself, on a general note. First off I am not trying to dis anyone involved in minGW. Some readers may realize I have been posting messages regarding minGW for a long while; I use minGW as well as I can. And try to contribute to it although I am not a talented or educated C programmer. All contributions are gratefully reviewed. Historically speaking, minGW is what must be (IMHO of course!) acknowledged as a parasitic offshoot of Cygwin-gnuwin32. That is -- and pls, all readers, try not to react as if I had meant a very perjorative thing ^^^ pejorative -- it was a bit like the life-form known as mistletoe, which grows on a living tree's branches, sinking its tissues into the host plant and drawing sustainance from it, but is also a green plant on its own. Parasitic in a semi-way. As time has passed minGW has tried in various ways to become self-hosting -- very specific meaning to hackers, there, of course, but also works in my metaphor here -- and moved away from complete reliance on Cygwin and its bash environment and UNIX emulation. The way it has done this has been a bit anarchical. Paul Sokolovsky has his PW scheme and Mikey (if I recall right) has his approach, etc etc. In short, minGW has been no where near as disciplined and organized as Cygwin. Lacking a single corporate sponsor such as Cygwin has in RedHat, that shouldn't be too surprising. MinGW's history is documented at www.mingw.org and you've flamed it's originator's. This lack of sponsorship maybe is also part of the noted tendency for minGW priciple persons to manifest some, uhh, let's say testiness. You give no reference to prove what you say or to allow anyone to defend themselves. People who pioneer new areas and sink huge amounts of personal time and effort into tough problem-solving with minimal broad-based outside interest or support sometimes become as a result a bit, uh, proprietary in their feelings about the project to which they've dedicated themselves. This can involve also a certain lack of balanced perspective, inability to grasp the perspectives of newcomers or outsiders, and -- sorry -- arrogance in attitude, sometimes. I've seen all this from certain people involved in minGW. Overall, though, its an amazing thing that minGW even exists, and has accomplished as much as it as. I don't know of whom you speak. One thing that is pretty clear to me is that there is no one person, aside maybe from Mumit Khan, who can legitimately present him/herself as speaking for minGW. I think I just did, and have. I think that needs to be acknowledged if there's been some impression that minGW is criticizing cygwin. minGW is first and foremost a free-for-all, a collaborative exercize that moves forward by fits and starts. In any such assemblage of personalities there are bound to be some outspoken individuals (no sh__:-) who express frustrations they are having in a way that isn't echoed by more silent participants. Criticism, none intentional. Observation of problems mixing the environments is what's trying to be portrayed. Observation about what's been said about -mno-cygwin in the past in this list is what's trying to be portrayed. 3) a better solution for MinGW binaries from a Cygwin environment is to install MinGW GCC over Cygwin I personally keep the two absolutely separate in their own filesystem trees. TTBOMK the win32API files in Cygwin lag a little behind those on minGW -- maybe somebody can correct me on this -- and I prefer, lacking expertise on many things, to try to maximize my good results by not mixing the two to unknown side-effects. I'll correct you on this. I release to both Cygwin and MinGW on the same day from the same set of sources new versions of w32api. There may be a few weeks of differences
Re: Potential problems with cygwin GCC and -mno-cygwin switch
Yeah, and we can kiss that pesky UNIX emulation claim of cygwin's
goodbye, too. Somehow, I don't think that you'll find many library
files in /usr/lib/cygwin on, say, HP/UX, Linux, Tru64, etc.
This method solves a problem for -mno-cygwin at the expense of
impacting many other packages.
I agree that the print-search-dirs should work correctly and even suggested
this in the libtools forum. I agree that --dll-search-prefix=cyg should
not be activated when the user specifies -mno-cygwin.
OK, maybe part of Jon's idea was bad or not correct, but what about
replacing just that
--dll-search-prefix=cyg
with a
%{!mno-cygwin:--dll-search-prefix=cyg}
in the distro?
If I understood it right this whould be a problem solver with no side
effects, right?
--
Lapo 'Raist' Luchini
[EMAIL PROTECTED] (PGP X.509 keys available)
http://www.lapo.it (ICQ UIN: 529796)
--
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: Potential problems with cygwin GCC and -mno-cygwin switch
Lapo Luchini wrote:
Yeah, and we can kiss that pesky UNIX emulation claim of cygwin's
goodbye, too. Somehow, I don't think that you'll find many library
files in /usr/lib/cygwin on, say, HP/UX, Linux, Tru64, etc.
This method solves a problem for -mno-cygwin at the expense of
impacting many other packages.
I agree that the print-search-dirs should work correctly and even suggested
this in the libtools forum. I agree that --dll-search-prefix=cyg should
not be activated when the user specifies -mno-cygwin.
OK, maybe part of Jon's idea was bad or not correct, but what about
replacing just that
--dll-search-prefix=cyg
with a
%{!mno-cygwin:--dll-search-prefix=cyg}
in the distro?
If I understood it right this whould be a problem solver with no side
effects, right?
Except that it doesn't really solve any problems that currently exist --
only potential ones. I'll explain below.
I agree that you SHOULD have %(!mno-cygwin:--dll-search-prefix=cyg). If
the mingw folks would condescend to actually USE the search prefix
feature I laboriously added to binutils -- at thier request -- and name
their DLLs with a prefix other than 'lib' it would truly be nice. And
then you'd also put %(mno-cygwin:--dll-search-prefix=mgw) or something.
And Paul Sokolovsky could use --dll-search-prefix=pw. But I digress.
dll-search-prefix only has effect when you are trying to link directly
to a DLL. Ordinarily, you don't do that -- you link with import libs.
Which are named 'libfoo.dll.a'. Really, to link to a DLL, in practice
you have to:
-L/usr/bin -lfoo
Since there aren't any import libs in /usr/bin, when ld fails to find
libfoo.dll.a THEN it will search for cygfoo.dll. (Actually, I'm
glossing over some other items in the search procedure -- use the
source, luke)
Do you currently add -L/usr/bin when linking? No, I didn't think so --
therefore --dll-search-prefix can't really be causing any problems.
Unless you've got DLLs scattered around elsewhere...
--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: Potential problems with Cygwin GCC and -mno-cygwin switch
On 26 Dec 2001 at 20:33, Jon Leichter wrote: It's been a long time since I was active on this list. I have not used Cygwin for over a year, until recently. I see that Cygwin has been updated quite a bit since I last used it. It's very nice to see these new features. Me too (well that made me popular right off the bat ;-)! Seriously, I too spend longish times away from Cygwin and then i am always surprised at how much has been accomplished when i return. In particular I'd like to acknowledge the recent accomplishment of getting the whole automake/autoconf thing to be a built-in part of Cygwin at last. Whew! I have a couple of issues to discuss about Cygwin GCC and it's MinGW support. Before I get started, I'd like to make an observation. The MinGW web site (http://www.mingw.org/mingwfaq.shtml#faq-usingwithcygwin) suggests that: 1) MinGW support in Cygwin GCC is flaky and buggy 2) MinGW support in Cygwin GCC will possibly be deprecated I have a few observations to make about this myself, on a general note. First off I am not trying to dis anyone involved in minGW. Some readers may realize I have been posting messages regarding minGW for a long while; I use minGW as well as I can. And try to contribute to it although I am not a talented or educated C programmer. Historically speaking, minGW is what must be (IMHO of course!) acknowledged as a parasitic offshoot of Cygwin-gnuwin32. That is -- and pls, all readers, try not to react as if I had meant a very perjorative thing -- it was a bit like the life-form known as mistletoe, which grows on a living tree's branches, sinking its tissues into the host plant and drawing sustainance from it, but is also a green plant on its own. Parasitic in a semi-way. As time has passed minGW has tried in various ways to become self-hosting -- very specific meaning to hackers, there, of course, but also works in my metaphor here -- and moved away from complete reliance on Cygwin and its bash environment and UNIX emulation. The way it has done this has been a bit anarchical. Paul Sokolovsky has his PW scheme and Mikey (if I recall right) has his approach, etc etc. In short, minGW has been no where near as disciplined and organized as Cygwin. Lacking a single corporate sponsor such as Cygwin has in RedHat, that shouldn't be too surprising. This lack of sponsorship maybe is also part of the noted tendency for minGW priciple persons to manifest some, uhh, let's say testiness. People who pioneer new areas and sink huge amounts of personal time and effort into tough problem-solving with minimal broad-based outside interest or support sometimes become as a result a bit, uh, proprietary in their feelings about the project to which they've dedicated themselves. This can involve also a certain lack of balanced perspective, inability to grasp the perspectives of newcomers or outsiders, and -- sorry -- arrogance in attitude, sometimes. I've seen all this from certain people involved in minGW. Overall, though, its an amazing thing that minGW even exists, and has accomplished as much as it as. One thing that is pretty clear to me is that there is no one person, aside maybe from Mumit Khan, who can legitimately present him/herself as speaking for minGW. I think that needs to be acknowledged if there's been some impression that minGW is criticizing cygwin. minGW is first and foremost a free-for-all, a collaborative exercize that moves forward by fits and starts. In any such assemblage of personalities there are bound to be some outspoken individuals (no sh__:-) who express frustrations they are having in a way that isn't echoed by more silent participants. 3) a better solution for MinGW binaries from a Cygwin environment is to install MinGW GCC over Cygwin I personally keep the two absolutely separate in their own filesystem trees. TTBOMK the win32API files in Cygwin lag a little behind those on minGW -- maybe somebody can correct me on this -- and I prefer, lacking expertise on many things, to try to maximize my good results by not mixing the two to unknown side-effects. From what I've seen, it looks like MinGW support in Cygwin GCC is up-to-date and better than ever before. So, I have no idea what the MinGW web site is referring to. Does anyone from Cygwin agree that MinGW support will be deprecated? I hope not. I am going to be studying the responses to this msg for the next several days in an attempt to understand WHAT they are talking about (argh). I gather that it is mostly about linker scripts which i have never understood very well (and to tell the truth, hope i don't have to). I, personally, find it much better to build MinGW binaries with Cygwin GCC. In my work, I often build projects with shell scripts. Using the Cygwin bash shell is the easiest (if not, the only) way to interpret these shell scripts. Many times, shell scripts create symbolic links and specify them to compiler tools as
Re: Potential problems with cygwin GCC and -mno-cygwin switch
On Tue, Jan 08, 2002 at 05:29:14PM -0500, Soren Andersen wrote:
This lack of sponsorship maybe is also part of the noted tendency for
minGW priciple persons to manifest some, uhh, let's say testiness.
I've been reading the mingw mailing lists for a while and I really don't
see anything like this. Most of the replies are very courteous.
They don't seem to have anyone like me, for instance. :-)
I've seen all this from certain people involved in minGW. Overall,
though, its an amazing thing that minGW even exists, and has
accomplished as much as it as.
I really don't see very much of this at all. I'm surprised to see this
observation.
One thing that is pretty clear to me is that there is no one person,
aside maybe from Mumit Khan, who can legitimately present him/herself
as speaking for minGW. I think that needs to be acknowledged if
there's been some impression that minGW is criticizing cygwin. minGW
is first and foremost a free-for-all, a collaborative exercize that
moves forward by fits and starts. In any such assemblage of
personalities there are bound to be some outspoken individuals (no
sh__:-) who express frustrations they are having in a way that isn't
echoed by more silent participants.
There is a group of core MingGW maintainers, or at least that's what I
understand. A couple of the MinGW maintainers have actually indicated
that they still use cygwin for building their compiler tools.
And, as may have been noted, the mingw web page is really not wrong.
MinGW support in cygwin *is* flaky and we *have* talked about
deprecating it.
From what I've seen, it looks like MinGW support in Cygwin GCC is
up-to-date and better than ever before. So, I have no idea what the
MinGW web site is referring to. Does anyone from Cygwin agree that
MinGW support will be deprecated?
I hope not. I am going to be studying the responses to this msg for
the next several days in an attempt to understand WHAT they are talking
about (argh). I gather that it is mostly about linker scripts which i
have never understood very well (and to tell the truth, hope i don't
have to).
Off the top of my head, there are a few issues with mingw support in
cygwin gcc (I think most if not all have already been mentioned):
1) It's supported by me currently. While I have no problem with mingw as
an entity, it's not my project, and maintaining the gcc/ld aspects do
not thrill me. I have a few patches in my tree that are not part of
the standard gcc offering. That's one reason why gcc 3.x built from the
official gcc release will behave differently from the cygwin gcc 2.95.3.
2) While I have gone to some pains to isolate header files in the -mno-cygwin
case, I didn't do the same thing for libraries. That means if you do
'gcc -mno-cygwin foo.c -lncurses' ld will attempt (and fail) to link the
cygwin version of ncurses into your program in some cases.
3) c++ support doesn't work since we don't provide a mingw version of
libstdc++.a. This has been on my tuit list for a while, though.
4) 'gcc -mno-cygwin -print-some-gcc-thing' doesn't work right.
While I do think Cygwin GCC currently does a great job of supporting
MinGW, I do have a few issues with it:
{snip details}
Hopefully this can all get resolved peacefully and harmoniously. The
one thing I hope is that the collective attitudes at minGW never get to
the point where people over there (some of whom are also people over
here) have forgotten the debt of appreciation they owe to cygwin, for
being the historical predecessor and host that allowed them to come
into existence, if for nothing else.
There is no over there. The MinGW maintainers are a friendly bunch.
I scan the MinGW lists for cygwin issues and a number of them read the
cygwin list as well.
So, please don't invent any antipathy between our two groups. I have
never seen anyone badmouth cygwin in the mingw mailing lists. In my
opinion MinGW is a sister project and should be treated as such.
gcc -mno-cygwin isn't going anywhere. I somtimes speculate that we will
be deprecating it but since this switch is required to build some things
in the 'winsup hierarchy' we really can't do that.
I've also speculated that gcc -mno-cygwin should just run a mingw cross
compiler but that is rather infeasible, too. It means that if you
are building the winsup hierarchy from scratch you have to somehow
also build a completely separate compiler and linker. There is no way
that I even want to imagine the Makefile nightmare necessary to accomplish
that.
So, what is needed is someone to fix gcc, ld, and whatever to do the right
thing. Barring that, gcc -mno-cygwin will remain relatively stagnant.
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: Potential problems with cygwin GCC and -mno-cygwin switch
On 8 Jan 2002 at 19:14, Christopher Faylor wrote:
On Tue, Jan 08, 2002 at 05:29:14PM -0500, Soren Andersen wrote:
This lack of sponsorship maybe is also part of the noted tendency for
minGW priciple persons to manifest some, uhh, let's say testiness.
I've been reading the mingw mailing lists for a while and I really don't see
anything like this. Most of the replies are very courteous.
Of course they are. I never meant to suggest otherwise. But sometimes...
They don't seem to have anyone like me, for instance. :-)
I don't know what to make of that, precisely. It doesn't seem to me that
you manifest particularly obnoxious behavior.
I've seen all this from certain people involved in minGW. Overall,
though, its an amazing thing that minGW even exists, and has
accomplished as much as it as.
I really don't see very much of this at all. I'm surprised to see this
observation.
Well, everyone experiences different things. That is a large general truth
about life in all sorts of realms, far beyond just online or just among
hackers on mailing lists.
But specifically in reply, Chris, since I was, I thought, VERY careful to
preface and intersperse all my comments with things like I don't mean to
dis anyone at minGW, I hope that somehow an overly broad and vague and
erronious impression isn't created by this, your response, which seems much
more concerned [as in worried] than I feel would be warranted by a
reading of my message that accurately grasped my intent (which was first of
all to praise cygwin).
One thing that is pretty clear to me is that there is no one person,
aside maybe from Mumit Khan, who can legitimately present him/herself
as speaking for minGW. I think that needs to be acknowledged if
there's been some impression that minGW is criticizing cygwin. minGW is
first and foremost a free-for-all, a collaborative exercize that moves
forward by fits and starts. In any such assemblage of personalities there
are bound to be some outspoken individuals (no sh__:-) who express
frustrations they are having in a way that isn't echoed by more silent
participants.
There is a group of core MingGW maintainers, or at least that's what I
understand.
A couple of the MinGW maintainers have actually indicated
that they still use cygwin for building their compiler tools.
Yes, AFAIK that is true, and is another discussion I'd like to have
sometime.
And, as may have been noted, the mingw web page is really not wrong.
MinGW support in cygwin *is* flaky and we *have* talked about
deprecating it.
I don't know much about that, relative to others here and over there.
Since your involvement in cygwin (and this List) is continuous and daily
and mine is perforce sporadic, I can never authoritatively contest anything
you state regarding past statements and discussions. Nor do I see any need
to.
[note: OP wrote]
From what I've seen, it looks like MinGW support in Cygwin GCC is
up-to-date and better than ever before. So, I have no idea what the
MinGW web site is referring to. Does anyone from Cygwin agree that
MinGW support will be deprecated?
{snip}
[I wrote]
Hopefully this can all get resolved peacefully and harmoniously. The
one thing I hope is that the collective attitudes at minGW never get to the
point where people over there (some of whom are also people over here)
have forgotten the debt of appreciation they owe to cygwin, for being the
historical predecessor and host that allowed them to come into existence,
if for nothing else.
[cgf:]
There is no over there.
Of course there is. If one refrains from placing inferred nuances into my
words, all that my words meant (like the words of the OP) is that there is
a minGW community, vaguely -- as you indicated, a core group of
maintainers, whom I have much respect for -- and that community has its own
Lists and sites (as cited by the OP). And maybe or maybe not (debatably)
its own collective prevailing attitudes.
The MinGW maintainers are a friendly bunch. I scan the MinGW lists for
cygwin issues and a number of them read the cygwin list as well.
As I believe I said?!?
So, please don't invent any antipathy between our two groups.
Perhaps *you* individually saw my words as an attempt to do so, hopefully
that wasn't a widespread impression. I think going back and looking at the
msg of the OP is warrented if one is going to debate my intention any
further after I have made this reply. There is IMO a clear probability that
the OP's msg may be read by some people as evoking the sense that there's
controversy or disharmony between cygwin and minGW.
My message was addressed to that possibility, not to fan any flames but to
provide historical perspective to those who might be catching up -- as
there are always many newcomers to any special-interest discussion in this
large realm, be it GNU or Apache or Mozilla or whatever -- people who
weren't involved from the early inception stages and may
Re: Potential problems with cygwin GCC and -mno-cygwin switch
Christopher Faylor wrote I've been reading the mingw mailing lists for a while and I really don't see anything like this. Most of the replies are very courteous. They don't seem to have anyone like me, for instance. :-) Speaking of single-handedly destroying the open source movement, G, check out the summary of last week's linux-kernel mailing list over here: http://kt.zork.net/kernel-traffic/latest.html (Jan 7) Talk about acrimony -- and that's between the core developers -- Rik van Riel wrote the (old) VM, Al Viro is active in the virtual file system layer, Andre' is the [lone] open source representative on the ATA standards definition committee, and then of course there's Linus. Some juicy quotes: Which, btw, explains why I don't consider you a kernel maintainer, Rik, and I don't tend to apply any patches at all from you. -- Linus [Linus,] please pass your crack pipe arounds so the rest of us idiots can see your vision or lack of .. -- Andre' Hendrick [to Andre']: I've long since noticed that we cannot communicate...If you have patches, please talk to Jens, tell him what the issues are, and I know I can communicate with him. -- Linus And there was lots of complaining about the lack of quality of the posts on lkml. It ain't just cygwin@. And it ain't just cgf. --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: Potential problems with cygwin GCC and -mno-cygwin switch
On Tue, Jan 08, 2002 at 08:55:12PM -0500, Soren Andersen wrote: On 8 Jan 2002 at 19:14, Christopher Faylor wrote: They don't seem to have anyone like me, for instance. :-) I don't know what to make of that, precisely. It doesn't seem to me that you manifest particularly obnoxious behavior. I guess I'll have to try harder. :-) I've seen all this from certain people involved in minGW. Overall, though, its an amazing thing that minGW even exists, and has accomplished as much as it as. I really don't see very much of this at all. I'm surprised to see this observation. Well, everyone experiences different things. That is a large general truth about life in all sorts of realms, far beyond just online or just among hackers on mailing lists. Yup. But specifically in reply, Chris, since I was, I thought, VERY careful to preface and intersperse all my comments with things like I don't mean to dis anyone at minGW, I hope that somehow an overly broad and vague and erronious impression isn't created by this, your response, which seems much more concerned [as in worried] than I feel would be warranted by a reading of my message that accurately grasped my intent (which was first of all to praise cygwin). Sorry, but if you use terms like testiness, I think that people will take it as a criticism. When I was a kid, and first learned about the term no offense I thought I'd had a magic phrase that would insulate me from all rebuke. The first time I told my sister You're stupid. No offense., my parents disabused me of that notion. Similary, you said that you didn't mean to dis anyone and then mentioned testiness, lack of balanced perspective, inability to grasp the perspectives of newcomers, and arrogance with respect to people involved with MinGW. I don't think it is unusual to experience a certain feeling of negativeness when these types of words and phrases are used. And, since you are defending your use of them, let me point out, that I don't think they really added anything to your treatise. In fact, I'm not even sure what the point of your message was. I thought it was some sort of exhortation to MinGW maintainers to play nice with the cygwin guys. Or, maybe it was an attempt to explain MinGW people to cygwin people. I'm not certain that either was really needed. I think this was a simple misunderstanding over some words on a web page. My opinion. [cgf:] There is no over there. Of course there is. If one refrains from placing inferred nuances into my words, all that my words meant (like the words of the OP) is that there is a minGW community, vaguely -- as you indicated, a core group of maintainers, whom I have much respect for -- and that community has its own Lists and sites (as cited by the OP). And maybe or maybe not (debatably) its own collective prevailing attitudes. Ok. I was wrong to infer anything from the term over there. Sorry. The MinGW maintainers are a friendly bunch. I scan the MinGW lists for cygwin issues and a number of them read the cygwin list as well. As I believe I said?!? I don't recall your mentioning the fact that I scanned the mingw lists. I'd be surprised that you would know that. Adding the counterpoint that MinGW maintainers read this list was a repetition but it seemed to add a nice balance to my statement. Hopefully this can all get resolved peacefully and harmoniously. [snip] So, please don't invent any antipathy between our two groups. Perhaps *you* individually saw my words as an attempt to do so, hopefully that wasn't a widespread impression. I think going back and looking at the msg of the OP is warrented if one is going to debate my intention any further after I have made this reply. There is IMO a clear probability that the OP's msg may be read by some people as evoking the sense that there's controversy or disharmony between cygwin and minGW. What I read from the terms peacefully and harmoniously was that there was another potential alternative. In my experience, one doesn't usually use terms like this unless you're anticipating at least the potential for a fight. However, it's not really that big a deal, I guess. You've clarified and if I was in the minority of people who misinterpreted your intent, then I apologize, again. My message was addressed to that possibility, not to fan any flames but to provide historical perspective to those who might be catching up Ah. It was a historical perspective. Hmm. You did say historically speaking at one point. How can you claim to be absent from the list and then feel the need to provide history? Were you only interested in providing ancient history? Or maybe history with gaps in it? How could you provide an accurate history if you haven't actually been paying attention? (which is your right, of course) In any event, your interpretation of mingw and its developers seems to be very different from mine. Reading between the lines, it seems like you have run across
Re: Potential problems with cygwin GCC and -mno-cygwin switch
cgf wrote: Hmm. Have you been reading the mingw mailing lists? That wasn't clear. I don't see any messages from you but I've only been archiving them since August or so. And ... does that (august of 2001) seem like a long time ago, to you? So that you can feel pretty confident about being aware of what things have been like since that community began to nucleate? Hmm. No, Chris, you'd definitely have to access archives back WAY further to find messages posted by me. Years further. I can see you love to scrap. You are pretty good, although I've met better Ur-nitpickers in my time. But pretty darn good! ;-) Best Regards, Soren Andersen -- 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: Potential problems with Cygwin GCC and -mno-cygwin switch
- Original Message -
From: Jon Leichter [EMAIL PROTECTED]
1) MinGW support in Cygwin GCC is flaky and buggy
That pages suggests that is _has been_ f b - and it has. It's better
now than it ever has been, and still has ... quirks.
2) MinGW support in Cygwin GCC will possibly be deprecated
This won't happen unless a realistic way of building Cygwin is found!
(Cygwin cannot link to itself).
3) a better solution for MinGW binaries from a Cygwin environment
is to install MinGW GCC over Cygwin
No way! I've read what they sugegst and it will cripple any cygwin user
from being able to build cygwin linked exe's. A cygwin hosted, mingw
targeted cross compiler however, would be a great tool and would
co-exist without any difficulty.
While I do think Cygwin GCC currently does a great job of supporting
MinGW,
I do have a few issues with it:
1) The --print-search-dirs switch outputs the same information whether
or
not the -mno-cygwin switch is specified. This is a problem
particularly for
GNU libtool. When the command gcc -mno-cygwin --print-search-dirs is
executed, it ought to output the MinGW-specific directories and leave
the
Cygwin-specific directories out. GNU libtool also expects a semi-colon
as
the path separator.
I've not enough gcc innards to suggest a solution here. I suggest that
you do the following:
1) Ask just this question on a gcc specific list (how do a change the
output of print-search-dirs via the .specs, and if I can't do that
today, can anyone give me a pointer as to where I should look in the
code to add that capability). [It doesn't matter if gcc would accept
such a patch or not, cygwin often has things that the upstream don't
want in our releases, for various good reasons].
2) When you've got it working, submit it here, and the cygwin gcc
maintainer will likely pick it up and put it into the cygwin gcc release
(after testing of course)
You can hope that the cygwin gcc maintainer has the time to do 1)
himself, but I don't expect that to happen for a year or so :}.
2) In the specs file, /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/specs,
the
following switch is declared in the *link section:
--dll-search-prefix=cyg
It seems to me that this switch should not be specified when GCC is in
MinGW
mode. A fix would be to alter to the declaration:
%{!mno-cygwin:--dll-search-prefix=cyg}
Indeed, I have done this in my own specs file.
Here you may get luckly and have this (trivial change) picked up by the
maintainer. However the standard way for getting patches submitted is to
provide the output of diff -up against the original source, along with a
changelog.
=
3) There's a problem with Cygwin-specific libraries residing in
/usr/lib.
...
I, of course, updated the specs file to accomodate this. My
environment now
works flawlessly. When OpenLDAP looks for libncurses, it doesn't find
it, as
it shouldn't.
This seems like an interesting approach. I wonder if anything would get
broken by it (other than ALL the existing packages that provide
libraries :}).
I wonder if anyone else thinks it would be a good idea to relocate
Cygwin
I think this may be easier than fixing gcc, but I'm sure that fixing gcc
is a better long term approach. However as I don't have the time nor
inclination to fix gcc myself, my opinion is just that.
Cheers,
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: Potential problems with cygwin GCC and -mno-cygwin switch
On Fri, Dec 28, 2001 at 12:28:22AM +1100, Robert Collins wrote: = 3) There's a problem with Cygwin-specific libraries residing in /usr/lib. ... I, of course, updated the specs file to accomodate this. My environment now works flawlessly. When OpenLDAP looks for libncurses, it doesn't find it, as it shouldn't. This seems like an interesting approach. I wonder if anything would get broken by it (other than ALL the existing packages that provide libraries :}). Yeah, and we can kiss that pesky UNIX emulation claim of cygwin's goodbye, too. Somehow, I don't think that you'll find many library files in /usr/lib/cygwin on, say, HP/UX, Linux, Tru64, etc. This method solves a problem for -mno-cygwin at the expense of impacting many other packages. I agree that the print-search-dirs should work correctly and even suggested this in the libtools forum. I agree that --dll-search-prefix=cyg should not be activated when the user specifies -mno-cygwin. I've made the appropriate change to my version of gcc but I don't think that this warrants a new release. We will not be moving .a files to /usr/lib/cygwin, so please lets not even discuss this. 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: Potential problems with cygwin GCC and -mno-cygwin switch
On Thu, Dec 27, 2001 at 12:02:46PM -0500, Christopher Faylor wrote: On Fri, Dec 28, 2001 at 12:28:22AM +1100, Robert Collins wrote: = 3) There's a problem with Cygwin-specific libraries residing in /usr/lib. ... I, of course, updated the specs file to accomodate this. My environment now works flawlessly. When OpenLDAP looks for libncurses, it doesn't find it, as it shouldn't. This seems like an interesting approach. I wonder if anything would get broken by it (other than ALL the existing packages that provide libraries :}). Yeah, and we can kiss that pesky UNIX emulation claim of cygwin's goodbye, too. Somehow, I don't think that you'll find many library files in /usr/lib/cygwin on, say, HP/UX, Linux, Tru64, etc. This method solves a problem for -mno-cygwin at the expense of impacting many other packages. I agree that the print-search-dirs should work correctly and even suggested this in the libtools forum. I agree that --dll-search-prefix=cyg should not be activated when the user specifies -mno-cygwin. I've made the appropriate change to my version of gcc but I don't think that this warrants a new release. Btw, by appropriate change, I mean that Ive moved the --dll-search-prefix inside of a !mno-cygwin block in the gcc specs file. I haven't made any changes to print-search-dirs and have no plans on doing so. cgf We will not be moving .a files to /usr/lib/cygwin, so please lets not even discuss this. -- 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: Potential problems with Cygwin GCC and -mno-cygwin switch
Ok... you got me... One problem with cyberspace communication is how two (or more) people can be talking about the same topic but are on different pages (metaphorically, of course)... :) What I was talking about is packages that you download and build yourself, e.g. GNU regex, GNU libtool, GDBM, OpenLDAP: all of these packages configure with a default prefix of /usr/local. I was not talking about pre-packaged Cygwin binaries. And I still claim that even after you install Cygwin packages, they will operate if you relocate the libraries in /usr/lib. This is because the Cygwin binaries depend on DLLs accessible via the PATH, which are NOT relocated from /usr/bin. Jon -Original Message- From: Robert Collins [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 27, 2001 6:23 PM To: Jon Leichter Cc: [EMAIL PROTECTED] Subject: Re: Potential problems with Cygwin GCC and -mno-cygwin switch - Original Message - From: Jon Leichter [EMAIL PROTECTED] Most libraries included with packages install in /usr/local/lib (opposed to /usr/lib). As for libraries that it may depend upon, as long as my GCC specs file knows where to find libraries, I don't see a problem. Please check your facts before making assertions. === $ ls -lR /usr/local/lib/ /usr/local/lib/: total 0 drwxrwxrwx2 Administ None0 Dec 27 22:00 pkgconfig /usr/local/lib/pkgconfig: total 0 === I have nearly every package provided by cygwin installed, and as you can see, the libraries are not installed in /usr/local/lib. 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: Potential problems with Cygwin GCC and -mno-cygwin switch
-Original Message- From: Robert Collins [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 27, 2001 6:35 PM To: Jon Leichter Cc: [EMAIL PROTECTED] Subject: Re: Potential problems with Cygwin GCC and -mno-cygwin switch However , once gcc's specs are changedm linking with the libraries they provide will fail - which is what I was talking about. Hmm... I'm not sure why this would be the case. I have relocated my libraries, and I have updated my specs file. Things work just fine for me (or it seems). I wonder if you could elaborate your assertion with an example. (I don't want to upset Chris Faylor - is this something we should discuss off the mailing list?) (Until every package gets repackaged, at a significant time cost to the package maintainers). And as this would be (at best) an interim fix until gcc is corrected, I for one do not support implementing this - the time cost would get gcc fixed many times over. Rob Based on the conversation we've been having, I no longer think this is a general good idea either. I stated this is a previous email. I agree that the right solution is to correct gcc. The relocation that I have done merely serves as an interim solution for me. Jon -- 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: Potential problems with cygwin GCC and -mno-cygwin switch
On Thu, Dec 27, 2001 at 06:46:25PM -0800, Jon Leichter wrote: From: Robert Collins [mailto:[EMAIL PROTECTED]] However , once gcc's specs are changed linking with the libraries they provide will fail - which is what I was talking about. Hmm... I'm not sure why this would be the case. I have relocated my libraries, and I have updated my specs file. Things work just fine for me (or it seems). I wonder if you could elaborate your assertion with an example. (I don't want to upset Chris Faylor - is this something we should discuss off the mailing list?) I'm not a censor. If you are discussing something that deals with cygwin feel free to do it here. 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: Potential problems with Cygwin GCC and -mno-cygwin switch
- Original Message - From: Jon Leichter [EMAIL PROTECTED] However , once gcc's specs are changedm linking with the libraries they provide will fail - which is what I was talking about. Hmm... I'm not sure why this would be the case. I have relocated my libraries, and I have updated my specs file. Things work just fine for me (or it seems). I wonder if you could elaborate your assertion with an example. (I don't want to upset Chris Faylor - is this something we should discuss off the mailing list?) It's an onlist topic. Because the two things have to happen concurrently. Cygwin has over a 100 packages, of which maybe 40 provide libraries that would need to be relocated. The mechanism for relocation is quite simple: every package maintainer repackages their package with the libraries in the new location. I think I understand what you're saying now. The wording in your previous email threw me off. I'm not sure the two things have to happen concurrently. If the GCC specs file were to change first, then GCC would start looking in /usr/lib/cygwin, and it would continue to look in (the hard-coded path) /usr/lib, where old package libraries would still reside. Also, I'm not sure that all packages need to be relocated. Just the ones that place files in /usr/lib. There is no problem with a package that places files in a subdirectory of /usr/lib. At this point, this conversation is purely hypothetical... :) I really don't think 100 packages should should be re-packaged... Jon -- 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/
Potential problems with Cygwin GCC and -mno-cygwin switch
Hello all.
It's been a long time since I was active on this list. I have not used
Cygwin for over a year, until recently. I see that Cygwin has been updated
quite a bit since I last used it. It's very nice to see these new features.
I have a couple of issues to discuss about Cygwin GCC and it's MinGW
support.
Before I get started, I'd like to make an observation. The MinGW web site
(http://www.mingw.org/mingwfaq.shtml#faq-usingwithcygwin) suggests that:
1) MinGW support in Cygwin GCC is flaky and buggy
2) MinGW support in Cygwin GCC will possibly be deprecated
3) a better solution for MinGW binaries from a Cygwin environment
is to install MinGW GCC over Cygwin
From what I've seen, it looks like MinGW support in Cygwin GCC is up-to-date
and better than ever before. So, I have no idea what the MinGW web site is
referring to. Does anyone from Cygwin agree that MinGW support will be
deprecated?
I, personally, find it much better to build MinGW binaries with Cygwin GCC.
In my work, I often build projects with shell scripts. Using the Cygwin bash
shell is the easiest (if not, the only) way to interpret these shell
scripts. Many times, shell scripts create symbolic links and specify them to
compiler tools as parameters. Only a Cygwin binary can interpret these
symbolic links. If a symbolic link were specified as a parameter to a MinGW
compiler tool, it would fail. Thus, I fail to see how MinGW GCC over Cygwin
is a better solution than MinGW support provided by Cygwin GCC.
While I do think Cygwin GCC currently does a great job of supporting MinGW,
I do have a few issues with it:
1) The --print-search-dirs switch outputs the same information whether or
not the -mno-cygwin switch is specified. This is a problem particularly for
GNU libtool. When the command gcc -mno-cygwin --print-search-dirs is
executed, it ought to output the MinGW-specific directories and leave the
Cygwin-specific directories out. GNU libtool also expects a semi-colon as
the path separator.
2) In the specs file, /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/specs, the
following switch is declared in the *link section:
--dll-search-prefix=cyg
It seems to me that this switch should not be specified when GCC is in MinGW
mode. A fix would be to alter to the declaration:
%{!mno-cygwin:--dll-search-prefix=cyg}
Indeed, I have done this in my own specs file.
=
3) There's a problem with Cygwin-specific libraries residing in /usr/lib.
Generic GCC has /usr/lib and /lib hard-coded as default library search
directories. If a library specified on the link line (of a gcc -mno-cygwin
invocation) does not exist in /usr/lib/mingw but does exist in /usr/lib,
that library will get linked into the binary instead of an error being
generated. An example: OpenLDAP's configure script looks for libncurses
support in the build environment. If I'm building MinGW OpenLDAP, it finds
libncurses in /usr/lib. The libncurses import library resolves to
cygncurses6.dll. If I'm building MinGW OpenLDAP, I don't want any Cygwin
binaries linked into it.
What I've done to get around this problem is relocate all Cygwin libraries
and object files from /usr/lib to /usr/lib/cygwin. Here's how I did it:
$ cd /usr/lib
$ mkdir cygwin
$ mv lib* cygwin
$ mv *.dll *.o cygwin
I, of course, updated the specs file to accomodate this. My environment now
works flawlessly. When OpenLDAP looks for libncurses, it doesn't find it, as
it shouldn't.
I wonder if anyone else thinks it would be a good idea to relocate Cygwin
libraries as a standard part of the distribution. Note that I am talking
about relocating link-time libraries and object files, not the actual DLLs
in /usr/bin. Also, I wonder if the headers should be relocated. There is not
a problem with header processing at all. I'm just mentioning it for
symmetry. (I have not relocated my Cygwin headers).
=
I know the motto of OpenSource. If there's something you don't like, fix it
and submit the patch. Unfortunately, I won't be able to do this. I recognize
that no changes may come about. However, I am mentioning these topics to see
what other people think, and I suspect that some of these isses might be
easy fixes that somebody else (who participates in Cygwin development) might
be able to quickly handle.
Jon
--
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/
