RE: arm-elf-gcc binaries

["Yadid Ayzenberg" <yadid dot ayzenberg at passave dot com>]

A big thanks to all fo you.
I think Im begining to understand the pitfalls of distributing a binary tool
chain.

Yadid

-----Original Message-----
From: crossgcc-owner@sources.redhat.com
[mailto:crossgcc-owner@sources.redhat.com]On Behalf Of Duane Ellis
Sent: Thursday, July 03, 2003 6:01 PM
To: crossgcc@sources.redhat.com
Subject: Re: arm-elf-gcc binaries



>> can any body with cygwin (no matter which version ) ... run these?

I am very familure with CYGWIN and it's problems.  I have been
supporting CYGWIN cross targets here for nearly 7 years,

I am the maintainer/developer of our custom 32bit and 24bit CPUs gcc &
gdb tool chains, and some others (our internal wacky GCC-6502, yes GCC
for 6502, don't ask!) and others...

CYGWIN is a mixed bag, there are many aspects of this, the problems
are for the most part the same as linux distributions but on steriods.

I also maintain and ship tool kits to numerous partners world wide.

There are THREE very important things you must understand about cygwin:

1) The CYGWIN DLL version number is only one problem.

   Solution when it occurs: Users must update the basic CYGWIN
   installation, not really a problem - you can have multiple versions
   installed. (ie: b19, etc..)

   Some Linux distributions have different Kernel Versions with
   various patches, so it's kind of the same.

   ie: Debian vrs RedHat vrs Slackware

   Since CYGWIN.DLL is the core of CYGWIN functionality it is
   kind of like the "kernel" version in Linux.

   But - since CYGWIN.DLL is a DLL - it is kind of like
   differing versions of "glibc" on Linux.

   Sadly - the story continues...

2) When somebody says "RH7.3" this defines not only the "kernel"
   version number but also the collection of tools that come with it
   ie: Bash Version X, GCC Version Y, and XFree86 Version Z.

   [See Above]

   It's kind of like a distributuion (mandrake comes with its
   collection and redhat has some other combination)

   RH7.3 comes with what version of GCC?
   What about Debian?
   What about Slackware?

   That is a real problem - The CYGWIN Version does not define a
   collection of packages. Instead, each of these things are defined
   indivisually and choosen indivisually by the end user when they run
   the "cygwin setup" program.

   Each user can, and will choose a very different combination of
   things - depending upon which mirror they choose to install
   from. What fun!

   This is a *REAL* problem if your enduser wants to rebuild the tool
   chain, as it requires many more 'packages' to make work.

   What you should do - is include with your documentation the
   contents of your cygwin: /etc/setup/installed.db file

   Look at your file it's basically ascii text. (YEA!)

   It is not pretty, but a smart person can read this and figure out
   what versions of what packages they need to install. (I wish the
   RPM database was that simple to deal with... YEA TEXT FILES!)

   You the tool chain builder know your tools work if all of those
   packages and versions are installed.

   Remember although: RH7.3 includes solitare game version X.Y -
   surely that does not effect GCC works (you'd hope anyway) - same
   probably applies to the various packages listed in your
   installed.db file

   I would not bother trying to vet the list, your bound to screw up.
   Besides the list is really quite small.

3) You also must tell the user the default "mount" flags used
   for your development configuration.

   Remember: WinDoze has CRLF issues and these will cause a problem
   with CYGWIN builds - in very weird ways.

   Example of how to break something:

   a) Make a CYGWIN mount point and mount it with the "textmode" option
      You'd think that is a good idea right? It is a DOS thing right?

   b) Build and install your Cross tools in that mount point
      [ie: Keep everything in that directory structure]

      Some of the GCC files (ie: specs) ends up with CR/LF in them
      not all -and not all the lines are converted to CR/LF.

   c) Now unmount & remount the same directory structure but this time
      mount it in Binary Mode.

   -- Why? Pretend you built the SDK on your system in text mode
      but the end user who downloaded your package choose the other
      mode when they setup the mount point.

      Why? Because the user thinks CYGWIN is Unix right? And it does
      not have this CR/LF problem so everything is binary right?

      Yes it happened to me, and it was a very tough problem to
      figure out

   d) Now try to run various tools and such, scripts etc. some things
      will work, and somethings will not work.

   -- Repeat above - but with with Text/Bin selections flipped.

   It does not always work -and the most strange things happen
   to each person who uses the system, what a PITA!

   If you can, save the stuff under --prefix and do a DIFF between
   the two sets of files, you'll find a number of PITA files!

   The most common place is burried deep in some ./configure script
   generated thing where CR/LF issues show up and where not expected.
   example: when reading text files with backslashes, what happens
   if in parts of the file it is \<LF> and other parts of the file
   contain \<CR><LF>, the \ eats the <CR> but not the <LF> or does it?
   Answer: It depends on the tool.

   Sometimes i'd like to shoot the M*Fs who don't write code carefully
   and very forgiving. Other times, I understand their delemia.

   Sometimes this only occurs in the middle of a series of piped
   commands {ie: Ever debug a 'configure' problem?}

   It is nearly impossible to track down this wacky type of a problem.

   The entire tool chain needs an option that makes it quietly
   ignore/accept mixed CR/LF files and deal with it manually, and not
   leave it to the rutime libraries.

--------------------------------------------------

bill> I ship everything under --prefix.  Which is why I always set
      --prefix=/opt/billgatliff.

Do something one better then that

   --prefix=/opt/YOURNAME/UNIQUE_VERSION

This lets users have multiple copies (old and new) and switch when
needed. Every have an old project you must maintain and can't change
the tools set cause things break?

--Duane.

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com