This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |