building unix-hosted cross compiler (targeting cygwin)

[Jeffrey Juliano <juliano at cs dot unc dot edu>]

Hi,

I'm having trouble building a cross compiler that is
  
 o built on an irix machine
 o hosted on an irix machine
 o targets cygwin (makes cygwin executables)

For the search engine's sake, I'll describe here where I've found info
before describing my problem.  My problem comes after the line of dashes.


I've looked at both Mumit's page 
http://www.xraylith.wisc.edu/~khan/software/gnu-win32/cygwin-cross-howto.txt

and the gcc cross-compiler faq
http://www.objsw.com/CrossGCC/FAQ-4.html

The most recent relevant info I found in the archive is Mo DeJong's
thread titled "Building linux cross cygwin with net release source" and
can be found here:
http://sources.redhat.com/ml/cygwin/2000-04/msg00217.html.  It seems that
everything before that speaks to b20.1.


Unfortunately, Mumit's page is written to B20.1.  In the thread above,
Mumit replies that he will eventually update his tutorial.  But that
hasn't happened yet, and Mo never followed up on his thread with a
solution.

So, I'd like to figure this out and write a howto.


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


On my irix machine I'm using gcc-2.95 and GNU make.

Mumit starts off by saying to unpack the b20.1 dev source tree, then
doing a configure and a make.  With the current sources, I'm not sure
what files to get and how to arrange them after unpacking.  I think the
ones I need are (from latest):

  o binutils-x-xrc.tar.gz
  o cygwin-1.x.x-src.tar.gz  (for newlib)
  o gcc-x-src.tar.gz

I noticed common-src.tar.gz.  But I have a feeling that it's already in
the other tarballs based on inspection of the CVS modules file on the
anon cvs server.


As these tarballs don't directly unpack into a common directory (the
files in them are all prefixed with package-version), I decided to look
at the gcc cross compiler faq.  Section 4.1 says that you can first build
binutils, then gcc, then newlib.  So, I gave that a try.

$ mkdir src
# unpack the three tar.gz files into src
$ mkdir obj
$ cd obj
$ prefix=somedir
$ target=i586-pc-cygwin
$ ../src/binutils-20000625/configure --prefix=$prefix \
                                     --target=$target -v
$ make


But make fails as follows:


/bin/sh ./libtool --mode=link gcc -W -Wall -g -O2  -o libbfd.la -rpath
/afs/unc/
proj/playpen/p5/juliano/cygwin/pkg/lib -release 2.10.90  archive.lo
archures.lo 
bfd.lo cache.lo coffgen.lo corefile.lo format.lo init.lo libbfd.lo
opncls.lo rel
oc.lo section.lo syms.lo targets.lo hash.lo linker.lo srec.lo binary.lo
tekhex.l
o ihex.lo stabs.lo stab-syms.lo `cat ofiles`  
./libtool[245]: cygpath:  not found
libtool: link: warning: undefined symbols not allowed in i586-pc-cygwin
shared l
ibraries
mkdir .libs
lib /OUT:.libs/libbfd.lib  archive.o archures.o bfd.o cache.o coffgen.o
corefile
.o format.o init.o libbfd.o opncls.o reloc.o section.o syms.o targets.o
hash.o l
inker.o srec.o binary.o tekhex.o ihex.o stabs.o stab-syms.o pe-i386.o
peigen.o c
offlink.o pei-i386.o elf32-i386.o elf32.o elf.o elflink.o dwarf2.o
dwarf1.o elf3
2-gen.o cpu-i386.o 
./libtool[3333]: lib:  not found
make[3]: *** [libbfd.la] Error 127
make[3]: Leaving directory
`/afs/cs.unc.edu/playpen/p5/juliano/cygwin/obj/bfd'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/afs/cs.unc.edu/playpen/p5/juliano/cygwin/obj/bfd'
make[1]: *** [all-recursive-am] Error 2
make[1]: Leaving directory
`/afs/cs.unc.edu/playpen/p5/juliano/cygwin/obj/bfd'
make: *** [all-bfd] Error 2


So, I next tried the one-tree script from the cross gcc faq.  I had to
fool it into making the links:

  # unpack the three .tar.gz files above
  $ ln -s binutils-20000625 binutils-2.9
  $ ln -s cygwin-1.1.2/newlib newlib-1.8.2
  $ one-tree-1.6
  $ mv src one-tree
  $ mkdir build-one-tree
  $ cd build-one-tree
  $ ../one-tree/configure --prefix=$prefix --target=$target -v
  $ make 2>&1 | tee make.log


But it still fails in the same place with the same error.  I briefly
looked at libtool, but quickly got lost.  I suspect the problem is
elsewhere, anyway.

aside:
I don't understand that error.  Is it saying that libtool can't find
something called `lib'?  But the two spaces after the colon seem to
indicate that something called `lib' and invoked by `libtool' can't find
something with a name of the empty string.

So now I'm asking for help before continuing on trial-and-error.  I know
there's a way to do this and I know there are people who do it (at least,
hosted on linux).

thanks,

-jeff

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com