Re: [CFT] libtool on nix->cygwin cross, with wine
On Tue, Feb 24, 2009 at 07:40:31PM -0800, rhubbell wrote: >On Tue, 24 Feb 2009 22:32:23 -0500 >Christopher Faylor wrote: >> Please stop this off-topic discussion. Warning #1. >I'll stop if you do. Warning #1. Ok, so long then. 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: [OT] Re: [CFT] libtool on nix->cygwin cross, with wine
On Tue, 24 Feb 2009 22:22:05 -0500 Dave Korn wrote: > How frequently you notice it may be different from how frequently other > people notice it, hopefully in proportion to whether you are more or less of a > jerk than whichever other people you choose to compare yourself against. You seemed to have taken note. You have a delete button, right? > > > And also what hypocrites there are too. Look at your .sig, a > > lot of useless information, but you send it every time. > > It's a fraction of the useless information that you send every time by > always duplicating the entire previous post. Just how many times do you need > to see that list of URLs anyway? > > It certainly creates the impression that you believe that your wit and > wisdom is of such great value that your every trivial and inconsequential > thought must be broadcast to the world at large the moment it pours forth from > your imagination, a matter of such earth-shattering import that we would not > want to wait the three seconds it would take you to trim the spam from your > post. This is why you're getting the treatment: you come across to have an > overly-high opinion of your own worth. You're certainly happy with yourself, don't believe everything you think. > > FTR, I'd be happy to wait that extra 3 seconds. An exemplary hypocrite. Hall-o-famer. If only you could practice what you spew. -- 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: [CFT] libtool on nix->cygwin cross, with wine
On Tue, 24 Feb 2009 22:32:23 -0500 Christopher Faylor wrote: > Please stop this off-topic discussion. Warning #1. I'll stop if you do. Warning #1. -- 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: [CFT] libtool on nix->cygwin cross, with wine
On Tue, Feb 24, 2009 at 07:05:05PM -0800, rhubbell wrote: >On Tue, 24 Feb 2009 17:33:53 -0500 >Greg Freemyer wrote: >>A lot of Linux mailing lists have that policy. Especially if it is >>high volume or has a large subscriber base. The idea is that someone >>can read a single email and understand it without having to bounce all >>over the place. > >I was mostly noticing how frequent the "list policing" is here. And >also what hypocrites there are too. Look at your .sig, a lot of >useless information, but you send it every time. What you notice is not of any interest here. Please stop this off-topic discussion. Warning #1. -- 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/
[OT] Re: [CFT] libtool on nix->cygwin cross, with wine
rhubbell wrote: > I was mostly noticing how frequent the "list policing" is here. How frequently you notice it may be different from how frequently other people notice it, hopefully in proportion to whether you are more or less of a jerk than whichever other people you choose to compare yourself against. > And also what hypocrites there are too. Look at your .sig, a > lot of useless information, but you send it every time. It's a fraction of the useless information that you send every time by always duplicating the entire previous post. Just how many times do you need to see that list of URLs anyway? It certainly creates the impression that you believe that your wit and wisdom is of such great value that your every trivial and inconsequential thought must be broadcast to the world at large the moment it pours forth from your imagination, a matter of such earth-shattering import that we would not want to wait the three seconds it would take you to trim the spam from your post. This is why you're getting the treatment: you come across to have an overly-high opinion of your own worth. FTR, I'd be happy to wait that extra 3 seconds. DaveK. -- 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: [CFT] libtool on nix->cygwin cross, with wine
On Tue, 24 Feb 2009 17:33:53 -0500 Greg Freemyer wrote: > A lot of Linux mailing lists have that policy. Especially if it is > high volume or has a large subscriber base. The idea is that someone > can read a single email and understand it without having to bounce all > over the place. I was mostly noticing how frequent the "list policing" is here. And also what hypocrites there are too. Look at your .sig, a lot of useless information, but you send it every time. > > > Greg > -- > Greg Freemyer > Litigation Triage Solutions Specialist > http://www.linkedin.com/in/gregfreemyer > First 99 Days Litigation White Paper - > http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf > > The Norcross Group > The Intersection of Evidence & Technology > http://www.norcrossgroup.com > > -- > 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/ > -- 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: [CFT] libtool on nix->cygwin cross, with wine
On Tue, Feb 24, 2009 at 04:44:58PM -0600, Ben Kamen wrote: > Greg Freemyer wrote: >> On Tue, Feb 24, 2009 at 4:35 PM, rhubbell wrote: >>> On Tue, 24 Feb 2009 16:15:33 -0500 >>> Greg Chicares wrote: By the way, this list discourages full quoting: http://www.cygwin.com/acronyms/#TOFU >>> Ok, this is one neurotic list. >> A lot of Linux mailing lists have that policy. Especially if it is >> high volume or has a large subscriber base. The idea is that someone >> can read a single email and understand it without having to bounce all >> over the place. > >What still always makes me laugh is the people who are so emphatic >about top vs. bottom posting. > >(someone even had a clever .sig showing the flow of top posting and how >"backwards" it is) > >But honestly, we humans have remarkable brains that let us put back >together the conversation in either order. Is it really *that* hard? >Maybe for some. > >But what made me laugh about the .sig was that it missed something. > >it said something along the idea of: > >Because it just does. Why. Yes. So, does that make it evil? because >it reverses the flow of discussion. why is top posting evil? > >But what makes me laugh is that people on a list have now just received >a sequence of messages in the correct flow with the most current >information at the top without the need for scrolling through redundant >previous message info just to "get to the goods" at the bottom. > >Personally (and this is the important part), I don't let it bother *me* >because I realize everyone's brain works a little differently. > >Speaking of which.. >http://mailformat.dan.info/quoting/top-posting.html > >Sorry for my ramble. I'll go hide now. Thanks. Your notion that you have anything new to say on this subject is very wrong. And, since your ramble has nothing to do with Cygwin, you're also off-topic. If people want a forum to demonstrate their ability to laugh at odd things or to express sentiments about the culture of this list then maybe the cygwin-talk mailing list would be more to their liking. -- 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: [CFT] libtool on nix->cygwin cross, with wine
On Tue, 24 Feb 2009 17:45:21 -0500 Ben Kamen wrote: > What still always makes me laugh is the people who are so emphatic about top > vs. bottom posting. If born sooner they would be shouting "Get of my lawn!". -- 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: [CFT] libtool on nix->cygwin cross, with wine
On Tue, 24 Feb 2009 18:12:00 -0500 Larry Hall (Cygwin) wrote: > > Thanks for sharing. Well, of course, if this bothers you to some great > extent, you need not stay. We won't follow you home. Promise! :-) Thank you too for sharing. (^: -- 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: [CFT] libtool on nix->cygwin cross, with wine
rhubbell wrote: On Tue, 24 Feb 2009 16:15:33 -0500 Greg Chicares wrote: By the way, this list discourages full quoting: http://www.cygwin.com/acronyms/#TOFU Ok, this is one neurotic list. Thanks for sharing. Well, of course, if this bothers you to some great extent, you need not stay. We won't follow you home. Promise! :-) -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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: [CFT] libtool on nix->cygwin cross, with wine
Ben Kamen wrote: But what made me laugh about the .sig was that it missed something. it said something along the idea of: Because it just does. Why. Yes. So, does that make it evil? because it reverses the flow of discussion. why is top posting evil? I had to laugh when I saw this! In any case, since you felt it important to call out my sig, I figured I'd respond to get the actual text as part of this (hopefully very short-lived) thread. See it below. And in case anyone is wondering, I am not the author of the sig, I just use it. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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: [CFT] libtool on nix->cygwin cross, with wine
Greg Freemyer wrote: On Tue, Feb 24, 2009 at 4:35 PM, rhubbell wrote: On Tue, 24 Feb 2009 16:15:33 -0500 Greg Chicares wrote: By the way, this list discourages full quoting: http://www.cygwin.com/acronyms/#TOFU Ok, this is one neurotic list. A lot of Linux mailing lists have that policy. Especially if it is high volume or has a large subscriber base. The idea is that someone can read a single email and understand it without having to bounce all over the place. What still always makes me laugh is the people who are so emphatic about top vs. bottom posting. (someone even had a clever .sig showing the flow of top posting and how "backwards" it is) But honestly, we humans have remarkable brains that let us put back together the conversation in either order. Is it really *that* hard? Maybe for some. But what made me laugh about the .sig was that it missed something. it said something along the idea of: Because it just does. Why. Yes. So, does that make it evil? because it reverses the flow of discussion. why is top posting evil? But what makes me laugh is that people on a list have now just received a sequence of messages in the correct flow with the most current information at the top without the need for scrolling through redundant previous message info just to "get to the goods" at the bottom. Personally (and this is the important part), I don't let it bother *me* because I realize everyone's brain works a little differently. Speaking of which.. http://mailformat.dan.info/quoting/top-posting.html Sorry for my ramble. I'll go hide now. -Ben -- Ben Kamen - O.D.T., S.P. = Email: bkamen AT benjammin DOT net Web: http://www.benjammin.net As seen somewhere on the net: My other computer is your Windows Server. -- 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: [CFT] libtool on nix->cygwin cross, with wine
On Tue, Feb 24, 2009 at 4:35 PM, rhubbell wrote: > On Tue, 24 Feb 2009 16:15:33 -0500 > Greg Chicares wrote: >> By the way, this list discourages full quoting: >> http://www.cygwin.com/acronyms/#TOFU > > Ok, this is one neurotic list. A lot of Linux mailing lists have that policy. Especially if it is high volume or has a large subscriber base. The idea is that someone can read a single email and understand it without having to bounce all over the place. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- 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: [CFT] libtool on nix->cygwin cross, with wine
On Tue, 24 Feb 2009 16:15:33 -0500 Greg Chicares wrote: > By the way, this list discourages full quoting: > http://www.cygwin.com/acronyms/#TOFU Ok, this is one neurotic list. -- 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: [CFT] libtool on nix->cygwin cross, with wine
On 2009-02-24 20:36Z, rhubbell wrote: > What's the [CFT] stand for? > Call For Test? Yes. He spelled it out: >> CALL FOR TEST By the way, this list discourages full quoting: http://www.cygwin.com/acronyms/#TOFU -- 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: [CFT] libtool on nix->cygwin cross, with wine
What's the [CFT] stand for?
Call For Test?
Are you requesting test volunteers?
On Tue, 24 Feb 2009 00:01:19 -0500
Charles Wilson wrote:
> The most recent release of libtool (2.2.7a-1 for cygwin-1.5, and
> 2.2.7a-10 for cygwin-1.7) ought to support cross builds at least as well
> as libtool-1.5 did. Note that in *ordinary* cross builds (SomeBUILD ->
> SomeHOST) you can't run the $host executables on the $build machine --
> but you can still *build* them. That kind of thing has (hopefully)
> always worked, and still works, for ->cygwin crosses. However, under
> certain conditions, it USED to be possible to run the $host (cygwin)
> executables on the $build machine, provided $build's CPU was x86, and
> $build had wine installed, and $build was running linux with the
> 'binfmt' kernel extension, and there was a cygwin "installation" in the
> wine "arena", etc, etc.
>
> /That/ has been broken for about a year, due to a change in how
> "wrapper" executables are handled by libtool in libtool-2.2.2 and above.
>
> 1 ==
> See, in the ANCIENT days, there was a wrapper script. When you built an
> executable for $host=cygwin, libtool would create
>
>myprog (a wrapper script)
>.libs/myprog.exe (the actual exe)
>
> The wrapper script would set $PATH and various other environment
> variables so that the EXE would be able to "find" its (as yet
> uninstalled) DLLs, and then it would launch the EXE. Obviously, scripts
> are not bound to any specific platform, so $build has no problem running
> the script. So as long as $build could execute EXE (via wine, etc), the
> the wrapper/EXE combo worked fine.
>
> Why'd we change it? Well, there IS one little problem with that scheme:
> the Makefile rule for building the EXE looks like this:
>
> ./my_prog$EXEEXT: my_prog.o
> ... some libtool commands ...
>
> But libtool doesn't create ./my_prog$EXEEXT -- it creates a wrapper
> named ./my_prog with NO $EXEEXT. So make always believes that the
> executable must be rebuilt. 'make' -> go link the exe. 'make check' ->
> 'go link the exe again'. 'make install' -> go link the exe. Very annoying.
>
> 2 ==
> So, in the OLD days, we had a wrapper executable AND a wrapper script:
>
> my_prog.exe (not the real exe; just a wrapper exe)
> my_prog (the wrapper script)
> .libs/my_prog.exe (the real exe)
>
> The way this scheme worked was: (a) the wrapper exe would launch the
> wrapper script, (b) the wrapper script would set $PATH and such, and
> then (c) launch the real exe. This worked pretty well -- and was fairly
> transparent to cross builders: they'd try to run 'my_prog' (not
> my_prog.exe, because who types "blahblah.EXE" on unix?). But, my_prog is
> a shell script, and it Just Works(tm) like it did in the ANCIENT days.
> So cross-builders were happy -- they just ignored that wrapper exe (and,
> incidentally, never tested it...)
>
> So, what was wrong with this? Did we "fix" something that wasn't broken?
>
> Well, not exactly. About three years ago, cygwin added a new feature:
> you could set the 'transparent_exe' option in the CYGWIN variable. Then,
> you could pretend you were even more "unixy": files which end in .exe to
> be used by appropriate functions when an input filename is specified
> with no extension. That is, you say spawn("foo") and if foo.exe exists,
> then cygwin will turn that in to spawn("foo.exe").
>
> So...what if I have foo.exe AND foo, and a really really want to
> spawn("foo") -- NOT spawn("foo.exe"). Say, for instance:
>
>my_foo.exe
>my_foo
>
> Uh...don't do that.
>
> See, transparent_exe caused all KINDS of pain for libtool -- cygwin (and
> libtool) got really confused by the situation. However, as long as
> transparent_exe was just an option, we were ok though: you just had to
> follow some rules:
> 1) if transparent_exe, then do not put files that differ only in
> .exe-extension in the same directory
> 2) since libtool does this, do not use libtool and transparent_exe
> together.
> Not the greatest situation, but we lived with it.
>
> Backgrounders:
> http://cygwin.com/ml/cygwin/2006-03/msg00148.html
> http://cygwin.com/ml/cygwin-apps/2006-03/msg00028.html
> http://cygwin.com/ml/cygwin/2007-04/msg00543.html
>
>
> But then, along comes cygwin-1.7...in which 'transparent_exe' will be
> the default behavior. Oops.
>
> "Don't use libtool and cygwin-1.7" is not a rule we can live with.
>
> So, (and this is the part that broke the cross-builders), we changed
> libtool's behavior...
>
> 3 ==
> About two years ago, for $host cygwin/mingw, libtool was modified to no
> longer put a wrapper *script* in the build dir. Instead, it put an
> uglify-named version of it in .libs:
>
> my_prog.exe (not the real exe; just a wrapper exe)
> .libs/my_prog_ltshwrapper(the wrapper script #1)
> .libs/my_prog_ltshwrapperTMP (the wrapper script #2)
> .libs/my_prog.exe (the real exe)
[CFT] libtool on nix->cygwin cross, with wine
The most recent release of libtool (2.2.7a-1 for cygwin-1.5, and
2.2.7a-10 for cygwin-1.7) ought to support cross builds at least as well
as libtool-1.5 did. Note that in *ordinary* cross builds (SomeBUILD ->
SomeHOST) you can't run the $host executables on the $build machine --
but you can still *build* them. That kind of thing has (hopefully)
always worked, and still works, for ->cygwin crosses. However, under
certain conditions, it USED to be possible to run the $host (cygwin)
executables on the $build machine, provided $build's CPU was x86, and
$build had wine installed, and $build was running linux with the
'binfmt' kernel extension, and there was a cygwin "installation" in the
wine "arena", etc, etc.
/That/ has been broken for about a year, due to a change in how
"wrapper" executables are handled by libtool in libtool-2.2.2 and above.
1 ==
See, in the ANCIENT days, there was a wrapper script. When you built an
executable for $host=cygwin, libtool would create
myprog (a wrapper script)
.libs/myprog.exe (the actual exe)
The wrapper script would set $PATH and various other environment
variables so that the EXE would be able to "find" its (as yet
uninstalled) DLLs, and then it would launch the EXE. Obviously, scripts
are not bound to any specific platform, so $build has no problem running
the script. So as long as $build could execute EXE (via wine, etc), the
the wrapper/EXE combo worked fine.
Why'd we change it? Well, there IS one little problem with that scheme:
the Makefile rule for building the EXE looks like this:
./my_prog$EXEEXT: my_prog.o
... some libtool commands ...
But libtool doesn't create ./my_prog$EXEEXT -- it creates a wrapper
named ./my_prog with NO $EXEEXT. So make always believes that the
executable must be rebuilt. 'make' -> go link the exe. 'make check' ->
'go link the exe again'. 'make install' -> go link the exe. Very annoying.
2 ==
So, in the OLD days, we had a wrapper executable AND a wrapper script:
my_prog.exe (not the real exe; just a wrapper exe)
my_prog (the wrapper script)
.libs/my_prog.exe (the real exe)
The way this scheme worked was: (a) the wrapper exe would launch the
wrapper script, (b) the wrapper script would set $PATH and such, and
then (c) launch the real exe. This worked pretty well -- and was fairly
transparent to cross builders: they'd try to run 'my_prog' (not
my_prog.exe, because who types "blahblah.EXE" on unix?). But, my_prog is
a shell script, and it Just Works(tm) like it did in the ANCIENT days.
So cross-builders were happy -- they just ignored that wrapper exe (and,
incidentally, never tested it...)
So, what was wrong with this? Did we "fix" something that wasn't broken?
Well, not exactly. About three years ago, cygwin added a new feature:
you could set the 'transparent_exe' option in the CYGWIN variable. Then,
you could pretend you were even more "unixy": files which end in .exe to
be used by appropriate functions when an input filename is specified
with no extension. That is, you say spawn("foo") and if foo.exe exists,
then cygwin will turn that in to spawn("foo.exe").
So...what if I have foo.exe AND foo, and a really really want to
spawn("foo") -- NOT spawn("foo.exe"). Say, for instance:
my_foo.exe
my_foo
Uh...don't do that.
See, transparent_exe caused all KINDS of pain for libtool -- cygwin (and
libtool) got really confused by the situation. However, as long as
transparent_exe was just an option, we were ok though: you just had to
follow some rules:
1) if transparent_exe, then do not put files that differ only in
.exe-extension in the same directory
2) since libtool does this, do not use libtool and transparent_exe
together.
Not the greatest situation, but we lived with it.
Backgrounders:
http://cygwin.com/ml/cygwin/2006-03/msg00148.html
http://cygwin.com/ml/cygwin-apps/2006-03/msg00028.html
http://cygwin.com/ml/cygwin/2007-04/msg00543.html
But then, along comes cygwin-1.7...in which 'transparent_exe' will be
the default behavior. Oops.
"Don't use libtool and cygwin-1.7" is not a rule we can live with.
So, (and this is the part that broke the cross-builders), we changed
libtool's behavior...
3 ==
About two years ago, for $host cygwin/mingw, libtool was modified to no
longer put a wrapper *script* in the build dir. Instead, it put an
uglify-named version of it in .libs:
my_prog.exe (not the real exe; just a wrapper exe)
.libs/my_prog_ltshwrapper(the wrapper script #1)
.libs/my_prog_ltshwrapperTMP (the wrapper script #2)
.libs/my_prog.exe (the real exe)
That way, no more 'transparent_exe' clashes. BUT, now the poor
cross-builders have no wrapper script to execute. They have to find the
uglified version in .libs, OR run the wrapper executable (which was
borked anyway in cross-build situations. See below).
Now, why two copies of the wrapper script? Well, libtool actually uses
the wrapper script fo
