Mail Archives: cygwin/2007/03/28/02:14:35
wei wrote:
> Sorry,I don't know.When setting up cygwin,there is an option of path format and
> maybe I chose win32 style.
I don't think that would do it. There is no option in setup.exe that
I'm aware of that would cause c:/foo/bar style paths to crop up in a
build.
> I didn't change the configure file included in gcc-core-4.1.2.tar.bz2.I just
> unziped it in fold f:\temp and created a build fold in temp.Then I executed the
> command below:
You should unpack it at the command line e.g. "tar jxvf file.tar.bz2".
Using Winzip or other regular Windows GUI archivers are notorious for
fouling up unix-like source tarballs -- either by not supporting
symlinks or by using DOS line endings. I'm not sure that this tarball
has any symlinks, but it's a good idea to avoid anyway.
> $ cd /cygdrive/f/temp/build
> $/cygdrive/f/temp/gcc-4.1.2/configure --prefix=/lib/gcc/i686-pc-cygwin/4.1.2
> $ make
This looks ok, although your choice for prefix is very strange. If you
are trying to emulate the layout of the existing gcc packages, you want
just --prefix=/usr. This is the base directory onto which the gcc build
system adds all the other components, such as lib/$target/x.y.z (the
latter if you also use --enable-version-specific-runtime-libs). So
under your given prefix, gcc binaries will be installed as
/lib/gcc/i686-pc-cygwin/4.1.2/bin/gcc.exe and support binaries installed
as /lib/gcc/i686-pc-cygwin/4.1.2/libexec/gcc/i686-pc-cygwin/cc1.exe, and
you would have to add /lib/gcc/i686-pc-cygwin/4.1.2/bin/ to PATH, and so
on. Needless to say this looks very strange and wrong.
But I recommend neither of these routes; I suggest you put any
self-compiled gcc in its own completely separate path, such as
--prefix=/opt/gcc412. To use it you can simply add it to the PATH, i.e.
export PATH="/opt/gcc412/bin:$PATH" and then simply invoking "gcc" will
find the self compiled one before the stock one. This also means it
won't interfere with any of the preinstalled gcc files, and removing it
is as easy as "rm -rf /opt/gcc412". If you intermix a self-compiled gcc
and the packaged gcc in the same --prefix, you are liable to end up with
conflicts unless you are very careful. Careful means using
--enable-version-specific-runtime-libs and/or --program-suffix and/or
--program-prefix and/or --program-transform-name, and even then it can
get screwed up. It's a lot easier just to put things in their own
tree.
> Cygcheck output a lot.
Yes, that's kind of the point of it, to tell us what packages you've
installed and what programs are in your PATH. But you didn't attach its
output so we will never know.
> F:\cygwin\bin\make.exe[1]: Entering directory `F:/cygwin/tmp/build'
> F:\cygwin\bin\make.exe[2]: Entering directory `F:/cygwin/tmp/build/libiberty'
> F:\cygwin\bin\make.exe[3]: Entering directory `F:/cygwin/tmp/build/libiberty/tes
> tsuite'
This looks wrong. These are win32 paths, these shouldn't be there at
all. You might expect this if you were using a non-Cygwin version of
make, such as MinGW make. Make sure you're using Cygwin make.
> gcc -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissi
> ng-prototypes -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG
> _H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I./../i
> ntl -I../../gcc/gcc/../libcpp/include \
> -DHOST_MACHINE=\"i686-pc-cygwin\" -DTARGET_MACHINE=\"i686-pc-cygwin\" \
> ../../gcc/gcc/c-pch.c -o c-pch.o
> gcc: no input files
I'm not sure what's going on here but something is obviously wrong as
gcc is saying no input files when they are clearly there on the command
line. It could be you have a MinGW version of a build tool somewhere in
the PATH and it doesn't understand symlinks. I have no idea.
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -