Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Tue, 14 Oct 2003 17:16:12 -0700
From: Edward Peschko <esp5 AT pge DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: various sundry things
Message-ID: <20031015001612.GA4875@mdssirds.comp.pge.com>
References: <20031014192012 DOT GA3735 AT mdssirds DOT comp DOT pge DOT com> <20031014210929 DOT GA28611 AT redhat DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031014210929.GA28611@redhat.com>
User-Agent: Mutt/1.4.1i

> Misconception: In your private email to me that the -mwin32 was a
> "use-win32 mode" flag.

no, you mentioned -mwin32, I was wondering what the hell 
you were talking about, and repeated it. I thought you were 
discussing a possible solution.

> 
> Misconception: You thought that -mno-cygwin was a flag that needed
> to only be passed to the linker.

true, but that is a conception that any user - especially newbies - could make.

You've got to understand something. When I come across a project and 
evaluate it for usability, I take about a half an hour with the manual 
and FAQ to see if I can get it off the bat. Best is if I don't have to
spend *any* time with the manual.

Now, here's what the faq has to say about -mno-cygwin:

"The -mno-cygwin flag to gcc makes gcc link against standard 
Microsoft DLLs instead of Cygwin. This is desirable for native 
Windows applications that don't need a UNIX emulation layer.".

it goes on to mention that cygwin + -mno-cygwin 'is not to be confused
with mingw32 which is a totally separate effort'.

that's it. nothing about link time, run time, or what-have-you. In fact it
*implies* use at link time.

So, I download the cygwin pdf. No instances in it about no-cygwin at all!
Odd, so I troll the web for resources. I get DJ Delorie's page, and
it goes over a simple example, again not anything remotely complicated, and 
even then it uses it at the linking stage.

All this totally begs the question of why the end user needs to know a flag,
an environmental hack using configure which does not work consistantly and
is based on the architecture of configure, and needs to link the two projects
via -I and -L directives to get the latest/greatest mingw32 to make the stuff
work.

Again, why the static over something that makes end users lives easier?

> 
> Misconception: You assumed in private email that the cygwin and
> mingw group "can't get along".

whatever you say.  I've talked to people on the mingw2 list that say different.

> Misconception: You think that the '"CC=gcc -mno-cygwin" configure'
> option requires adding lots of extra flags on the command line for
> proper operation.

no.. I didn't say that - I said that -mno-cygwin is not enough to make
cygwin think that it is mingw. extra flags is just one thing; directory
names are another. supporting programs are another.

> >I shouldn't have let my temper get the better of me. 
> 
> Now, wait.  I thought this was all my fault! I was "unprofessional" and
> said something in private email which made you lash out.  Being a
> professional, I'm sure you understand the need for a good scapegoat.

I never said it was all your fault. Hence the last email and this email.
Fights happen because of incivilities. Someone saying to me 'something is
not going to happen' before I even explain what that something is to me like
waving a red flag in front of a bull. I admit it, I went off a little half
cocked, but I imagine you'd feel the same way if I treated you this way. But
I could have been more even in my temper, I grant.

> You might want to pat yourself on the head and say "Ed -- I know better
> than to post private email to a public forum", as long as you're at it.

you explicitly said 'no private email'. like I said, I chose to 
obey the letter of your law, if not the spirit. An email that says 
"never email me in private again about cygwin" - even though you 
control the access to a developer's list - is an unfair message. 
It is out of bounds.  It abuses your power. Power abuse is a 
public issue, and a topic for public conversation.

However, it does lack tact, what I did. But then again, so does sending 
such a message to me in the first place w/out trying to understand my point. 

BTW - I BCC'd you on the first message - one out of twenty that I posted
on the list - as a *favor*. It contained a message that was said by you
(the original blanket no) and I never talk about what someone said behind their
backs without giving them a proper chance to respond. And hence, the BCC. 
If I was being less tactful, I would have made it a CC - therefore 
letting people know who gave the blanket no in the first place.

> By the way, that is strike 1.  I meant to mention that.
> 
> >I know pretty much where to go, what to do, and who to talk to in order
> >to make an effective MINGW mode for cygwin.  Cultural matters are a
> >different matter altogether, which I suspect is the cause of the split
> >between mingw and cygwin in the first place.
> 
> Just to be clear: there is no animosity between the two groups.  Someone
> decided that they didn't want the cygwin DLL in the way for performance
> and GPL reasons.  That is a perfectly valid reason for doing native
> tools ports.

That may be the public position. When I talk to mingw people in private about
such things, there's a different story.

> configure won't pick up the wrong compile flags if you use the technique
> I mentioned.  configure is smart enough not to make any assumptions
> about things like header file locations, despite your assertions to the
> contrary.  Your misconception here is puzzling given that you've been
> told that people have used this technique with success.

My 'misconception' is based upon things that I've seen with my own eyes. Trying
to compile berkelydb, trying to compile perl, trying to compile perl modules.
Yes, I retried berkelydb the way you suggested, and no, it still did not work.

setenv GCC 'gcc -mno-cygwin' 

./configure...
make
objdump -p db_recover | grep "DLL"

DLL Name:  cygwin1.dll
DLL Name:  KERNEL32.dll

so..
remove everything... try command line version

env GCC='gcc -mno-cygwin' configure ...

...
checking for gcc... gcc
...

Hmm. it looks like this isn't working:

grep no-cygwin *.
.. nothing there.

well, you probably meant CC='gcc -mno-cygwin' anyways.

so

env CC='gcc -mno-cygwin ' ./configure
make

.. hmm. died on DB_WIN32. you said stuff about this so I'll ignore it.

on link for db_archive.exe though, I get:

'gcc -mno-cygwin -o db_archive.exe db_archive.o util_sig.o ./.libs/libdb-4.1.a
./.libs/libdb-4.1.a (os_sleep.o(.text+0xbe): os_sleep.c : undefined reference to _select
./.libs/libdb-4.1.a (os_sleep.o(.text+0x86): os_sleep.c : undefined reference to _fsync

Again, its closer, but then again still out of sync.. For most users, it would be so
far out of sync that they'd have as much chance of getting this to work as reaching
out and touching the moon. Let alone getting this far. 

Since this builds 'clean' with mingw, 'cygwin + -mno-cygwin' != mingw32.

Ed

(
   ps - here's a perfect example of where uname is important. When you compile perl,
   perl handily puts all of its libraries and headers into a directory based on the
   architecture. so, invoke cygwin with or without -mno-cygwin, and you get headers in 
   i686-pc-cygwin. If you are working for a native Win32 perl, it makes much more
   sense to put them in a different directory, say i686-pc-mingw32. 

   -mno-cygwin has no way of making this distinction.
)

(pps - if you want to continue this in private, I'm perfectly welcome to. But this is
*it* for me and public explanation.)

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