unable to build binutils-2.10 solaris->i386-pc-mingw32

unable to build binutils-2.10 solaris->i386-pc-mingw32

[Frank van den Beuken]

Hi all,
I have problems building binutils-2.10 for use in a solaris->i386-pc-mingw32
cross compiler. I really need 2.10 because of the "reloc overflow" fix which
should make it possible to do 32-bit relocs. I need this because we use a
parser
generator which generates a huge .c file for our LALR parser.

This is how I configured:
/home/vdbeuken/tools/binutils-2.10/configure --host=sparc-sun-solaris2.6 --t
arget=i386-pc-mingw32 --prefix=/home/vdbeuken/tools/install-binutils -v --no
recursion

I get the following error:

rm -f tofiles
f=""; \
for i in pe-i386.lo peigen.lo cofflink.lo pei-i386.lo elf32-i386.lo elf32.lo
elf.lo elflink.lo dwarf2.lo dwarf1.lo elf32-gen.lo cpu-i386.lo  ; do \
  case " $f " in \
    *" $i "*) ;; \
    *) f="$f $i" ;; \
  esac ; \
done ; \
echo $f > tofiles
/bin/sh /home/vdbeuken/tools/binutils-2.10/bfd/../move-if-change tofiles
ofiles
touch stamp-ofiles
/bin/sh ./libtool --mode=link gcc  -g -O2 -W -Wall  -o libbfd.la -rpath
/home/vdbeuken/tools/install-binutils/lib -release 2.10  archive.lo
archures.lo bfd.lo cache.lo coffgen.lo corefile.lo format.lo init.lo
libbfd.lo opncls.lo reloc.lo section.lo syms.lo targets.lo hash.lo linker.lo
srec.lo binary.lo tekhex.lo ihex.lo stabs.lo stab-syms.lo `cat ofiles`
./libtool: cygpath: not found
libtool: link: warning: undefined symbols not allowed in i386-pc-mingw32
shared libraries
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 linker.o srec.o binary.o tekhex.o ihex.o stabs.o
stab-syms.o pe-i386.o peigen.o cofflink.o pei-i386.o elf32-i386.o elf32.o
elf.o elflink.o dwarf2.o dwarf1.o elf32-gen.o cpu-i386.o
./libtool: lib: not found
gmake[3]: *** [libbfd.la] Error 1
gmake[3]: Leaving directory
`/home/scratch/vdbeuken/tools/build-binutils-2.10-i386-pc-mingw32/bfd'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory
`/home/scratch/vdbeuken/tools/build-binutils-2.10-i386-pc-mingw32/bfd'
gmake[1]: *** [all-recursive-am] Error 2
gmake[1]: Leaving directory
`/home/scratch/vdbeuken/tools/build-binutils-2.10-i386-pc-mingw32/bfd'
gmake: *** [all-bfd] Error 2

It looks as if a native i386-pc-mingw32 build is performed;
lib /OUT: certainly looks like dos to me and cygpath is part of cygwin.
Can anyone help me completing this build, or alternatively tell me
how to apply the "reloc overflow" fix to binutils-2.9.1, which built just
fine.

Thanks in advance,
Frank


--
dr Frank van den Beuken
QASystems R&D Labs, Raiffeisenstraat 32, 5611 CH Eindhoven
The Netherlands, phone: +31 40 2963713, fax: +31 40 2963194
mailto:Frank.van.den.Beuken@rdlabs.qasystems.nl

Re: unable to build binutils-2.10 solaris->i386-pc-mingw32

[Alexandre Oliva]

On Jul  4, 2000, "Frank van den Beuken" <Frank.van.den.Beuken@rdlabs.qasystems.nl> wrote:

> It looks as if a native i386-pc-mingw32 build is performed;

Yup.  It's a bug in libtool.  libtoolize binutils with the current CVS
tree of libtool and it should work.  You may also --disable-shared, to
avoid the trouble.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

RE: unable to build binutils-2.10 solaris->i386-pc-mingw32

[Frank van den Beuken]

> On Jul  4, 2000, "Frank van den Beuken" 
> <Frank.van.den.Beuken@rdlabs.qasystems.nl> wrote:
> 
> > It looks as if a native i386-pc-mingw32 build is performed;
> 
> Yup.  It's a bug in libtool.  libtoolize binutils with the current CVS
> tree of libtool and it should work.  You may also --disable-shared, to
> avoid the trouble.

Hi Alexandre,
Thanks for your reply.
Unfortunately, the --disable-shared does not change anything
and our cvs version does not have the -z option for some reason.
Can you point me to a snapshot site for libtool and can you
be a bit more specific about how I libtoolize binutils.
When I run configure several libtool scripts are generated
in the build directory, but I do not know where they come from
and how I can influence their generation.

Greetings,
Frank  

Re: unable to build binutils-2.10 solaris->i386-pc-mingw32

[Alexandre Oliva]

On Jul  4, 2000, "Frank van den Beuken" <Frank.van.den.Beuken@rdlabs.qasystems.nl> wrote:

> Can you point me to a snapshot site for libtool

I don't think there is one :-(

> and can you be a bit more specific about how I libtoolize binutils.

If you can't download the CVS tree of libtool, you may just edit
configure scripts and, wherever you find:

case "$target" in
NONE) lt_target="$host" ;;
*) lt_target="$target" ;;
esac

replace it with:

lt_target="$host"

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

still reloc overflow?

[Frank van den Beuken]

This works. Thanks!
However, I still have the "reloc overflow" that I hoped would be solved:
/cadappl/gcc/2.95.2/i386-pc-mingw32/bin/as: transLALRParser.o: reloc
overflow: 0x17681 > 0xffff
transLALRParser.o: File truncated

I thought this was fixed, or is this not the same problem
as mentioned in
http://sourceware.cygnus.com/ml/binutils/2000-04/msg00223.html

Greetings,
Frank

> If you can't download the CVS tree of libtool, you may just edit
> configure scripts and, wherever you find:
>
> case "$target" in
> NONE) lt_target="$host" ;;
> *) lt_target="$target" ;;
> esac
>
> replace it with:
>
> lt_target="$host"

Re: still reloc overflow?

[Alan Modra]

On Tue, 4 Jul 2000, Frank van den Beuken wrote:

> However, I still have the "reloc overflow" that I hoped would be solved:
> /cadappl/gcc/2.95.2/i386-pc-mingw32/bin/as: transLALRParser.o: reloc
> overflow: 0x17681 > 0xffff
> transLALRParser.o: File truncated
> 
> I thought this was fixed, or is this not the same problem
> as mentioned in
> http://sourceware.cygnus.com/ml/binutils/2000-04/msg00223.html

No, that was an entirely different problem.  Your error message is
generated when the number of relocs is greater than the 16-bit field in 
the header can count.  It would probably be better if gas complained with
"too many relocs" in this case rather than "reloc overflow"

This bit of information doesn't help you with your problem, I'm afraid :-(

Alan Modra
-- 
Linuxcare.  Support for the Revolution.

RE: still reloc overflow?

[Frank van den Beuken]

I found that the problem I'd like to be solved is
http://sourceware.cygnus.com/ml/binutils/2000-03/msg00203.html
What is the status of this problem?
I really would like this to be fixed so that I can replace
MSVC++ in our build procedure with the solaris->mingw32
crossgcc.

Greetings,
Frank
 
> This works. Thanks!
> However, I still have the "reloc overflow" that I hoped would 
> be solved:
> /cadappl/gcc/2.95.2/i386-pc-mingw32/bin/as: 
> transLALRParser.o: reloc overflow: 0x17681 > 0xffff
> transLALRParser.o: File truncated
> 
> I thought this was fixed, or is this not the same problem
> as mentioned in 
> http://sourceware.cygnus.com/ml/binutils/2000-04/msg00223.html
> 
> Greetings,
> Frank
> 
> > If you can't download the CVS tree of libtool, you may just edit
> > configure scripts and, wherever you find:
> > 
> > case "$target" in
> > NONE) lt_target="$host" ;;
> > *) lt_target="$target" ;;
> > esac
> > 
> > replace it with:
> > 
> > lt_target="$host"
>  
> 

RE: still reloc overflow?

[Frank van den Beuken]

 
> I found that the problem I'd like to be solved is
> http://sourceware.cygnus.com/ml/binutils/2000-03/msg00203.html
This is wrong.
The problem that I have is:
http://sourceware.cygnus.com/ml/binutils/2000-01/msg00113.html
I'm still interested in knowing what the status is.

Sorry for the confusion,
Frank

> What is the status of this problem?
> I really would like this to be fixed so that I can replace
> MSVC++ in our build procedure with the solaris->mingw32
> crossgcc.
> 
> Greetings,
> Frank