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
