various sundry things

various sundry things

[Edward Peschko]

hey all,

First of all, I'm looking at my email as/of last night, and although
given the circumstances I pretty much still think what I said is 
accurate (although the pedant in me cringes at the misuse of the word 
'disabuse'), I shouldn't have let my temper get the better of me. 

I have to pat myself on the head sometimes and say 'Ed -- diplomacy 
and tact is a *good* thing'.  Sometimes I forget that.

Second of all, I believe that I've made my point. 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.

And third of all, just to stay slightly on topic here, msys indeed
has to do with mingw and is therefore a valid topic of discussion                         
and a valid place to patch cygwin for a MINGW mode. There's
an obvious example here - uname. 'configure' uses 'uname' to pick up the
system type. If cygwin still thinks it is cygwin on configure, it
will pick up the wrong compile flags, defines, etc, ie: totally futzing
up the build process. Users are either forced to cross-compile - or hack - 
to make it work.

And finally, I'm taking a break from this discussion. You can say stuff,
either in private or in public about it, but I'm giving you fair warning
that I may not respond.

Ed

(ps - forgive if a dup, the other message seems to not have gotten through.)

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

Re: various sundry things

[Christopher Faylor]

On Tue, Oct 14, 2003 at 12:20:12PM -0700, Edward Peschko wrote:
>First of all, I'm looking at my email as/of last night, and although
>given the circumstances I pretty much still think what I said is 
>accurate (although the pedant in me cringes at the misuse of the word 
>'disabuse'),

disabuse:  "To free from a falsehood or misconception"

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

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

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

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

>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 have to pat myself on the head sometimes and say 'Ed -- diplomacy 
>and tact is a *good* thing'.  Sometimes I forget that.

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.

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.

>And third of all, just to stay slightly on topic here, msys indeed
>has to do with mingw and is therefore a valid topic of discussion                         
>and a valid place to patch cygwin for a MINGW mode.

To repeat what I said earlier: discussions of msys are not on-topic in
the cygwin mailing list.  Your opinions on the matter are irrelevant.

>If cygwin still thinks it is cygwin on configure, it will pick up the
>wrong compile flags, defines, etc, ie: totally futzing up the build
>process.  Users are either forced to cross-compile - or hack - to make
>it work.

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.

cgf

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

Re: various sundry things

[Edward Peschko]

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

Re: various sundry things

[Christopher Faylor]

On Tue, Oct 14, 2003 at 05:16:12PM -0700, Edward Peschko wrote:
>> 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.

I never mentioned -mwin32.  I also never mentioned -mno-cygwin since
I was sure that someone on the cygwin list would do so.  I was not
trying to give you a possible solution.  I was trying to redirect
you back to the discussion that you started in the cygwin list.

I had a long response to the rest of this message but, surely people are
bored by this now so I will make a couple of brief points.

- The purpose of much of my email was to point out that you *had*
  misconceptions of which you needed to be "disabused".  It was not to
  say that you were stupid or evil for having the misconceptions.

- Posting private email without permission is always bad.  There is
  no excuse for it.

- I read the mingw-users mailing list regularly and see no indication
  of cygwin resentment.  I communicate regularly with two of the
  main developers and work closely with one of them.  The main mingw CVS
  repository is on sources.redhat.com.  If there is "bad blood" between
  our projects I am very interested in correcting that.  The only bad
  blood that I can think of is my dismay at the msys fork.  Earnie knows
  about my dissatisfaction there but we are still on very cordial terms
  since we are both grown ups.

- The example on http://www.delorie.com/howto/cygwin/mno-cygwin-howto.html
  clearly shows that -mno-cygwin is used to both compile and link programs.

- I, and others, use the 'CC=gcc -mno-cygwin' configure thing all of the time.
  When that doesn't work, I use make 'CC=gcc -mno-cygwin'.  Possibly adding a
  --host=i686-pc-mingw32 --target=i686-pc-mingw32 will also help in some
  circumstances.

- Yes, I know.  "uname."  "Simple environment variable."  Yadda, yadda, yadda.

That's it for me.  I'm glad to say that I will not be responding any further
to this thread.

(a thunderous roar from the list ensues)

cgf

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

Re: various sundry things

[Edward Peschko]

> - Posting private email without permission is always bad.  There is
>   no excuse for it.

... as is blocking people from personal communication, and giving them no
retinue in which to respond ...as is dismissing someone and their ideas out of hand.
no excuse for that, either.

> - Yes, I know.  "uname."  "Simple environment variable."  Yadda, yadda, yadda.

... well good then, we are in agreement. albeit, I doubt you'd phrase it that way.

> That's it for me.  I'm glad to say that I will not be responding any further
> to this thread.

likewise, as well.

Ed

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

Re: various sundry things

[Doug VanLeuven]

Edward Peschko wrote:
> 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.

I have to bite the hook on this one.  I mean I just can't leave that 
hanging out there.

Best is if everyone would always read the manuals - RTFM.

I wish I had an extra 5 bucks for every time I've been called in to fix 
some mess created by someone to arrogant to read the manual. I'd retire.

> 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
             ^^^^^
Freudian slip?
SCNR


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

Re: various sundry things

[Demmer, Thomas]

Edward Peschenko wrote
[...]
>> 
>> 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.
[...]

I think he has a point here. To me it occured natural that you have
to tell gcc already at compile time if you want to have a mingw executable
or DLL at the end. There is /usr/include/mingw after all, which is 
"the" system include directory for mingw and needs to be known at 
compile time. 

To others, this may not be that clear. 

Apart from CGF's hint how to configure for mingw you may also want to
change the install directory. I habitually install static libs into 
/usr/local/lib or /usr/local/lib/mingw. How to do that is left
as anexercise.

Best regards / Mit freundlichen Grüssen,

Thomas Demmer
Kraft Foods R&D Inc.
Tel.: +49 (0)89 62738-6302
Fax: +49 (0)89 62738-86302
mailto:tdemmer@krafteurope.com <mailto:> 

Thought of the day
A real friend isn't someone you use once and then throw away.
A real friend is someone you can use over and over again.


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