Re: [Mingw-msys] Re: Newbie Question

[Earnie B. <ear...@ya...>]

"Steve D. Perkins" wrote:
> 
> > Pentium == i686.  The value is returned from a Win32 API.  See
> > winsup/cygwin/uname.cc for the source.
> ...
> > Uname would return i386 on an i386, i486 on an i486, i586 on an i586,
> > etc.
> 
>     Ehh, I don't want to venture too far off on a tangent here... but
> shouldn't a first-generation Pentium processor like mine show up as an
> "i586"?  I mean, it's only one generation up from the 486... the "Pentium"
> brand-name itself comes from the Latin for "5".  I would expect that the
> BIOS or Win32 API would return "i686" if I had a Pentium Pro or Pentium II.
> 

Shrug, like I said it comes from a w32api call.  It's actually returns a
struct whose values are then conditionalized to return the i686.

>     Okay, I'm going to be the idiot who just comes out and asks this... what
> is the purpose of the "i686" version of MSYS?  

The i686 version was compiled with the -march=i686 switch set which
instructs GCC to use i686 optimizations not found in prior versions of
the CPU.  The i386 version was compiled with the -march=i386 switch set.

> I'VE been reading mentions in
> the mailing lists about next-generation 64-bit processesors, and I'M still
> confused... 

It'll require GCC and binutils to come out with a version that supports
those optimizations.  To further complicate the matter, the current
configurations use the build platform for platform specific naming. 
Therefore when I build and distribute say a GCC compiler the guessed or
supplied build system is used as a directory name.  This has nothing at
all to do with optimizations used by the compiler for a particular CPU. 
So, a directory of /usr/i686-pc-msys only means that the binaries were
created by an i686-pc-msys system, not optimized for it.

> I imagine that newbies will be completely thrown for a loop.  If
> the "i686" release is a 64-bit build, where does this name come from?  

AFAIK, all ix86 systems thus far are 32 bit beginning with i386.

> If my
> assumptions are totally off-base, and it's instead a 32-bit build targeted
> for Pentium processors and up, why doesn't it work on my system... since
> uname -a is returning the "i686" string?
> 

Perhaps we need to debug uname.cc.  I'll work with you on this when I
get back to the office.

> > Ok, that makes sense.  I wondered why you hadn't caught it in the
> > archives.  Since you're reading old archives have you noticed the 1.0.3
> > snapshot dll?  You'll want to replace your 1.0.2 dll with it since it
> > takes care of some scenarios I hadn't thought of originally.
> 
>     Done that.
> 
> > A package is on the round tuit list.  I wasn't aware that Geocrawler
> > didn't store attachments.  That'll be a PITA.
> 
>     You know Earnie, speaking from the perspective of one with a tendency to
> be long-winded... I admire your efforts towards efficiency in communication!
> However, since I've started working with you there have been a few occasions
> where I'm torn between the dilema of admitting that I don't understand some
> shorthand you've used, or just knowingly nodding in approval and pretending
> to be on the same page.  In this case I'll just confess my ignorance...
> what's a PITA?  :)
> 

Pain In The Ass.  It's taken me years to get some of the jargon down
to.  So don't be afraid to ask or do a google.com search.

> > I'll have to move this
> > package up on the priority.
> 
>     It's not a big deal to me personally (as I have my own tools to fix the
> problem), but it certainly will be one of those things that is asked about a
> hundred times.  Out of curiosity, why DOES Bourne barf all over DOS-style
> line-returns?  I don't believe that Cygwin suffers from the same problem.
> I'm not saying that it's a huge priority for the short-term, but that will
> probably need to be addressed eventually.
> 

Well Cygwin does too.  Bourne and POSIX (IIRC) use the \ for character
quoting.  It requires two \\ to get one \.  A \t is a tab, a \n is a
newline, others have other meanings and those that don't have a special
meaning just translate back to themselves.

> > Perhaps I can steal a moment or two from
> > family life during the next couple of weeks. ;).
> 
>     Oh man, go enjoy your holiday!  However, MY family does it's thing on
> Thanksgiving rather than Christmas... so it's mostly idle time for me from
> now until after New Year's.  If there's anything specific I can do to help
> while time is so plentiful, just let me know.
> 

Just continue to learn and document your difficulties so that others can
benefit from what you've learned./

>     Actually, if you REALLY want to steal a moment from your folks over the
> next few days... you can respond to the questions I'm posing below.  That
> will give me the raw material and insight I need to go off and do my own
> thing with documentation over the next couple weeks...
> 

I'll at least read the mail once a day.

> > P.S.: What's your first impressions of MSYS.
> 
>     Earnie, there will be a special place reserved for you in heaven for
> what you've done here!  This is something that I've been desperately wanting
> to see for the past couple of years (since first discovering Cygwin), and
> it's thrilling to finally see it come together.  I'm also very excited to
> learn that such minimal code changes were required to make it happen, as
> this indicates ease (and likelihood) of maintenance in the long-term.
> 

I was surprised at the lack of coding that was needed also.  There was
more removing of code, actually preprocessor wrapping than there was
actual coding.

>     However, in addition to the issues I've mentioned above ("i686"
> confusion and line-return problems)... there are a few questions I'm
> struggling to get my arms around before I put serious effort into
> documentation for this thing.  I've pondered over whether this is more
> appropriate for the [MinGW-editor] list or [MinGW-MSYS], but since I've "got
> you on the phone" right here anyway...
> 

This is tough to get.  It took me a while to understand the differences
between the build system created directory names and the optimization
switches used by GCC.  The two aren't equal but can be perceived to be.

>    I'm completely lost regarding the directory structure of MSYS, and how
> it's supposed to integrate with MinGW.  Over the past year I've read dozens
> of different testimonials for integrating MinGW with Cygwin... the Mumit
> Khan documents, and other arcane and obsolete descriptions for using
> "-mno-cygwin" with outdated versions of Cygwin.  I suspect that the total
> number of people who have successfully configured such an environment could
> be counted on one's digits, without taking off the shoes!
> 

I for one have never really mastered the mix of Cygwin and MinGW
binaries.  Those that have, have to modify the paths within the
Makefiles using cygpath.  I hope to have removed the need for the
modifications to the Makefile for cygpath.  However, libtool appears
like it'll be a challenge to overcome due to some assumptions made. :(

For the MSYS and MinGW interoperatibility, if you have MinGW already
installed in say c:\mingw and you install MSYS in c:\msys\1.0.  Now,
just make sure that c:\mingw\bin is in PATH before you start msys.bat. 
If you want to refer to the c:\mingw directories from within MSYS then
just usr /c/mingw/bin or c:/mingw/bin.  The c:/mingw version IIRC
doesn't autocomplete from withing bash, a todo.  If you wish to refer to
the c:\mingw path as /mingw then add a line to /etc/fstab like so
`c:\mingw /mingw' and the next time the dll initializes you'll be able
to `ls /mingw', etc.

>     When I wrote about this in the website's FAQ... I recommended installing
> Cygwin and MinGW in separate locations, and putting the MinGW "/bin" before
> Cygwin's in the PATH.  I assume that this is universally considered best
> practices, as my suggestions have yet to be challenged or improved upon in
> the months they've been online.
> 

Shouldn't need to do this with MSYS as MSYS isn't going to distribute a
gcc.  The thing to consider about MSYS is that you can't place binaires
in c:\msys\1.0\bin unless they depend on the msys-1.0.dll and that isn't
likely to happen except for my distribution and someone else ambitious
enough to do a GCC build for msys, but they'll need to figure out what
to change.

>     Now, is the same style of configuration best for integrating MinGW with
> MSYS... or are the two packages to be more tightly integrated than this?

No, it shouldn't be unless you have the msys version of GCC.

> I'm confused by the fact that the msys-tools package contains a "gcc"
> executable for the MSYS "/bin".  Why is that there?  

Only version 1.0.1 has gcc.  I was over ambitious in what I was
distributing and in version 1.0.1, that was everything under the Cygwin
practically at least from a developer's POV (point of view).  In version
1.0.2 I narrowed the distribution to only what a typical configure
script needed to execute to the point of hand selecting individual
binaries from the packages.  I.E., not all of the binaires from any one
package are included in the distribution.

> If it's supposed to be
> there, why is there no accompanying "g++"?  If it's supposed to be there,
> why are there no headers and libs bundled with the MSYS package?
> 

It's not supposed to be there in version 1.0.2.  If it is that's a
mistake.

>     Running "gcc -print-search-dirs" (using the gcc from msys-tools)
> displays a search path including several directories within the MSYS system
> that aren't even there (i.e. "/lib/msys/...").  Is the intended means of
> using MinGW within MSYS to create these directories and copy headers and
> libs over?  

Ok, I just looked again.  I don't see anything other than msys\1.0\bin,
msys\1.0\doc, msys\1.0\etc, msys\1.0\home (empty) and msys\1.0\mingw
(empty) in the binary distribution.  I also don't see a gcc in the
distribution.  Perhaps you've mixed 1.0.1 and 1.0.2.

> Are things currently setup this way to accommodate future plans,
> bundling the MinGW compiler with the MSYS environment as a single download?

No, I don't think that would be wise.

> Out of curiosity, why wasn't MSYS packaged without a built-in MinGW in the
> first place?
> 

I supplied an empty /mingw directory only as a suggestion of where MinGW
might go.  Do you think I should remove it for the 1.0.3 distribution?

>     I'm sorry for throwing these questions out in rapid-fire fashion.  

Please, don't be sorry.  It needs ironed out be before the masses grab
it.

> If it would be better to wait until after the holidays, that's fine.  

My family knows that I'm happiest `putin` so this is fine.

> If it would
> be better for me to split them up into several small and more specific
> mailing list postings, that's fine.  

Not necessary as long as we can manage to keep them toward the goal of
understanding MSYS.

> If it would be easier or faster to go
> over this in real-time via phone or IM/IRC, I can arrange a time during
> business hours or otherwise.
> 

Hopefully won't be necessary.  But if further down the road we still
think it necessary, then I'm open.  I don't have an IRC account, is
there a good freebie?

>     I just remember the long hours of frustration I once endured because
> there wasn't any good source of documentation for using MinGW with Cygwin,
> and I'd like to help out in making MSYS a more accessible system for
> newbies.  

I'm wanting to make it as simple as install MSYS, install MinGW,
configure and make.

> I realize that I'm not the most MinGW-experienced guy on the
> planet, but I'm pretty much the only person outside the core development
> team whose ever FOLLOWED THROUGH on offers to assist with documentation.  

I'm not that "MinGW-experienced" either, just been with it for some
length of time and I do notice those that do and those that have good
intentions to do.  There is a big difference.  Without you and Danny I'd
be a one man show about now.

> I
> have the time, others have the knowledge, it would be great to put these two
> resources together and create something that can help people and promote the
> system.
> 

Perhaps it's time to be more direct.  Those that have/had good
intentions sometimes just need more hand holding or at least a
kick-start in the right direction.

Earnie.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com