This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Gcc 4.x crosscompiler running on cygwin


Thanks for your answer!

I'm afraid that it took so long for a reply - but I've only access to this account on fridays.
I tried to read about the --with-sysroot flag and even tried to figure out how configure uses it... But I didn't see how this flag can help me. If this flag should be able solve my problem, there must be some kind of environment variable (e.g. $SYSROOT ?) that tells my gcc.exe at runtime (not at build time!) on the customers machine where it has to search for its includes, libs, ... This may be at "c:\program files\indel\compilers\gcc4.0.2", at "x:\supergcc", or whatever. But I couldn't see that such an environment variable is evaluated in gcc source code (if I remember correctly the sysroot-flag was handled in gcc.c or something similar - and there I tried to understand what is done in case of the --with-sysroot flag - but I wasn't successful).


Maybe I have to pinpoint what the main reason for this is:
1. We (want to) provide different compiler version, e.g. 2.95, 4.0.2, 4.1.0, ...
2. The user must be able to switch between those compiler versions without changing filesystem layout (e.g. by setting a new env variable)
3. our gcc should never have conflicts with cygwin - whether the customer has cygwin installed (which is seldom the case) or not (likely). I write this point because I've noticed that "my" gcc did use cygwins includes/libs if it couldn't find it elsewhere...


Is --with-sysroot really what I need? If yes, how to use it (concrete: how to define the "sysroot" location at runtime?)

Thanks a lot!
Raphael

Marco Trudel wrote:

Hello Raphael

Give --with-sysroot and with-build-sysroot a try. This way, you will have a fully independend relocatable gcc.

For more informations:
- http://rmathew.com/articles/gcj/bldgcj.html
- $GCC_SRC_DIR/configure --help


regards Marco


Raphael Zulliger wrote:


Hi!

What I need:
A gcc 4.x powerpc-eabi crosscompiler running natively under windows (with the use of cygwin) that will be distributed to our customers. The binaries (gcc, as,ar, ...), libraries and headers must reside in one directory structure on the windows file system. For example:
c:\crosscomp_gcc_4\bin\gcc.exe
c:\crosscomp_gcc_4\include\...
...
It is important to note, that some of our
customers may like to install the files below c:\crosscomp_gcc_4 to somewhere
else, say to:
c:\program files\crosscomp_gcc_4 (note that the path may even include spaces in its name!).
Furthermore we are using newlib (the latest and gratest version) and the target
OS is a self made realtime os. Also important: The customer may or may not have
the cygwin environment installed (in fact: most do not have it installed - but some
may and in both situations, everything should work fine (e.g. the crosscompiler should really not use any headers of the cygwin installation)!)


Now I describe how I did understand the situation, how the best way to achieve could look like - then I hope to get some inputs from you, whether my understanding
is wrong or could be improved. I would also suggest to put the results of my email and
all your answers into a wiki page - as I was not able to find a site for this specific
problem (gcc crosscompiler @ cygwin & redistribution to customers/other computers with/without
an installed cygwin environment).


Building a crosscompiler should be done as described in the different docs/wikis/howtos. Let's assume we used:
--prefix=/opt/mycompany/gcc4.0.2 (and thus are compiling gcc 4.0.2)
so after compiling everything (1. binutils, 2. bootstrap gcc, 3. newlib, 4. gcc), a make install does copy all the files into /opt/mycompany/gcc-4.0.2/...
The perfect way to distribute this system to our customer is now to take over the
given file structure by performing a cp -r /opt/mycompany/gcc-4.0.2 /cygdrive/c/crosscomp_gcc_4
Now the first "problem" arieses: gcc & Co. did store the path defined by --prefix somewhere
in the binaries - therefore powerpc-eabi-gcc.exe is aware of the system include and other pathes - and therefore the compiler will automatically search for the system/stl/... header
in /opt/mycompany/gcc-4.0.2 - a path that most probably doesn't exist on the customers
computer...
To solve this situation, I thought that it may be a clever idea to just create a cygwin mount
point (by editing the windows registry). The mount point will look like this:
mount c:\program files\customer dir\crosscomp_gcc_4 /opt/mycompany/gcc-4.0.2
I think this is a good way to solve the problem - but I'm not sure whether there exist
a better way - or asking differently: How was it thought to solve this kind of problem
(I'm sure that I'm not the only person on the planet that has exactly a situation like
this)?



Again, in short, everything important:
please tell me if my statements are correct and inform me if there exist better ways to achieve the same


- create the crosscompiler as described in third party doucments (assuming gcc 4.0.2, newlib an c/c++ languages activated)
- choose a prefix that will not interfere with other pathes, so probably its best to include the company name within the path
- after execution of "make install" of all the packages (binutil, gcc, newlib), everything needed is in the path defined by prefix
- copy the content of this path to somewhere else on the windows filesystem. From now on refered to as [1]
- distribute cygwin1.dll together with the whole directory structure [1] to the customers.
- during the company-made setup procedure, modify the windows registry so that cygwin has a mountpoint with the name defined by prefix that points to [1] on the customers computer
- now you should be able to compile c/c++ applications as usual


Thanks in advance!
Raphael







Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]