[Bug binutils/4334] MAKE FAILED: cpu-powerpc.o isn't added to libbfd.a ?

[freakoftheindustry at gmail dot com]

------- Additional Comments From freakoftheindustry at gmail dot com  
2007-04-19 19:40 -------
Short version:  it's nothing to do with cpu-powerpc.c.  That file simply happens
to be the last file in a list of filenames, which is then being dropped due to
Cygwin line ending problems.

Long version:
The cpu-powerpc.* entry is being added to everything correctly.  But it happens
to be the final filename in the generated 'ofiles' file.  Because it's Cygwin,
ofiles (which only contains a single line) ends with a CR-LF sequences.

Libtool is invoked with:

/bin/sh ./libtool --mode=link ....  simple.lo archive64.lo `cat ofiles`

and in --debug mode, is correctly seeing the file, but is still carrying the
filename around as "cpu-powerpc.lo^M".  Then libtool does this bit:

# Transform .lo files to .o files.
oldobjs="$objs "`$echo "X$libobjs" | $SP2NL | $Xsed -e '/\.'${libext}'$/d' -e
"$lo2o" | $NL2SP`

and $oldobjs does *not* contain cpu-powerpc.o at the end of its list.  From
there on, the file is just missing, so that when libtool generates the actual
link command, the list of object files ends one entry too soon at cpu-rs6000.o.

There's probably some way of working around this by messing with cygwin's
binary/text mount options.  I'm using a brand new installation of cygwin from
four days ago, so the defaults are apparently not right for building a toolchain
(admittedly not something that cygwin users are apt to try).  I'm not sure what
I'm going to do next... maybe convince the developers to start using the linux
boxes instead.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4334

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.