Re: binutils 2.19.92 linker broke with --as-needed flag

[Vincent Wen <wenvincent90 at gmail dot com>]

Alan,

The binutils-2.23.2 MIPS cross build fails. Here is the configuration
process. Please let me know what goes wrong.

Thanks.


[zwen@localhost binutils-2.23.2]$ ./configure --target=mipsel-linux-uclibc

[zwen@localhost binutils-2.23.2]$ make


...
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I. -I. -I../bfd
-I./../include -I./../bfd -W -Wall -Wstrict-prototypes
-Wmissing-prototypes -Werror -g -O2 -MT disassemble.lo -MD -MP -MF
.deps/disassemble.Tpo -c -DARCH_mips ./disassemble.c -o disassemble.o
mv -f .deps/disassemble.Tpo .deps/disassemble.Plo
/bin/sh ./libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.
-I. -I. -I../bfd -I./../include -I./../bfd    -W -Wall
-Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2 -MT
dis-init.lo -MD -MP -MF .deps/dis-init.Tpo -c -o dis-init.lo
dis-init.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I. -I. -I../bfd
-I./../include -I./../bfd -W -Wall -Wstrict-prototypes
-Wmissing-prototypes -Werror -g -O2 -MT dis-init.lo -MD -MP -MF
.deps/dis-init.Tpo -c dis-init.c -o dis-init.o
mv -f .deps/dis-init.Tpo .deps/dis-init.Plo
/bin/sh ./libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.
-I. -I. -I../bfd -I./../include -I./../bfd    -W -Wall
-Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2 -MT
mips-dis.lo -MD -MP -MF .deps/mips-dis.Tpo -c -o mips-dis.lo
mips-dis.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I. -I. -I../bfd
-I./../include -I./../bfd -W -Wall -Wstrict-prototypes
-Wmissing-prototypes -Werror -g -O2 -MT mips-dis.lo -MD -MP -MF
.deps/mips-dis.Tpo -c mips-dis.c -o mips-dis.o
mips-dis.c: In function `print_insn_args':
mips-dis.c:1251: warning: comparison between signed and unsigned
make[4]: *** [mips-dis.lo] Error 1
make[4]: Leaving directory `/home/zwen/workshop/tc/binutils-2.23.2/opcodes'
Making all in po
make[4]: Entering directory `/home/zwen/workshop/tc/binutils-2.23.2/opcodes/po'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/home/zwen/workshop/tc/binutils-2.23.2/opcodes/po'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/zwen/workshop/tc/binutils-2.23.2/opcodes'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/zwen/workshop/tc/binutils-2.23.2/opcodes'
make[1]: *** [all-opcodes] Error 2
make[1]: Leaving directory `/home/zwen/workshop/tc/binutils-2.23.2'
make: *** [all] Error 2
[zwen@localhost binutils-2.23.2]$



On 4/4/13, Vincent Wen <wenvincent90@gmail.com> wrote:
> Alan,
>
> I changed to another VB centOs 4.8 and rebuild the native
> binutils-2.23.2 and did "make check" and the result looks good:
>
>
>                 === ld Summary ===
>
> # of expected passes            743
> # of expected failures          8
> # of untested testcases         1
> /home/zwen/workshop/tc/binutils-2.23.2/ld/ld-new 2.23.2
>
> I'd like to use this as base to apply patch and run make check again.
>
> Regarding the MIPS platform.  For I am building the binutils into a
> cross compiler, with prefix like mipsel-linux-(gcc). Which means the
> tool itself still runs on the x86 Linux PC, but the generated target
> binary is on the MIPS.
> I'd like to know, in this case, if you want me to run dejagnu, do I
> run "make check" on the same x86 host? or runtest on the x86 host, and
> remotely run ld tools. I feel it might be still on the x86 host.
> Please correct me if I am wrong.
>
> Thanks for the help!
>
> Vincent
>
>
>
>
>
> On 4/4/13, Vincent Wen <wenvincent90@gmail.com> wrote:
>> Alan,
>>
>> I tried the following command and it finished with error. So I didn't
>> go further with "make" or "make check":
>>
>> CC="gcc -m64" CXX="g++ -m64" ./configure
>>
>> I checked the config.log and locate possible problem info, thanks.
>>
>>
>> configure:4043: $? = 0
>> configure:4032: gcc -m64 -v >&5
>> Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
>> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
>> --infodir=/usr/share/info --enable-shared --enable-threads=posix
>> --disable-checking --with-system-zlib --enable-__cxa_atexit
>> --disable-libunwind-exceptions --enable-java-awt=gtk
>> --host=i386-redhat-linux
>> Thread model: posix
>> gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)
>> configure:4043: $? = 0
>> configure:4032: gcc -m64 -V >&5
>> gcc: `-V' must come at the start of the command line
>> configure:4043: $? = 1
>> configure:4032: gcc -m64 -qversion >&5
>> gcc: unrecognized option `-qversion'
>> gcc: no input files
>> configure:4043: $? = 1
>> configure:4063: checking for C compiler default output file name
>> configure:4085: gcc -m64    conftest.c  >&5
>> conftest.c:1: sorry, unimplemented: 64-bit mode not compiled in
>> configure:4089: $? = 1
>> configure:4126: result:
>> configure: failed program was:
>> | /* confdefs.h */
>> | #define PACKAGE_NAME ""
>> | #define PACKAGE_TARNAME ""
>> | #define PACKAGE_VERSION ""
>> | #define PACKAGE_STRING ""
>> | #define PACKAGE_BUGREPORT ""
>> | #define PACKAGE_URL ""
>> | /* end confdefs.h.  */
>> |
>> | int
>> | main ()
>> | {
>> |
>> |   ;
>> |   return 0;
>> | }
>> configure:4132: error: in
>> `/projects/bseswev_nonos/vwen/support/swlinux-2378/dejagnu/pc/binutils-2.23.2':
>> configure:4136: error: C compiler cannot create executables
>>
>> On Tue, Apr 2, 2013 at 7:20 PM, Alan Modra <amodra@gmail.com> wrote:
>>> On Tue, Apr 02, 2013 at 06:51:06PM -0700, Vincent Wen wrote:
>>>> Relocatable linking with relocations from format elf32-i386 (ldgram.o)
>>>> to format elf64-x86-64 (tmpdir/ld-partial.o) is not supported
>>>
>>> Your compiler is defaulting to i386 code (-m32) rather than x86_64
>>> code (-m64).  It might be because you built your own gcc wrongly (or
>>> your distro did), or you have CFLAGS/CXXFLAGS or CC/CXX set in your
>>> environment, or "gcc" is a script that provides -m32 before calling
>>> the real gcc, or perhaps some other reason.  Whatever it is, that
>>> needs fixing, or perhaps may be worked around by configuring binutils
>>> with something like
>>>
>>> CC="gcc -m64" CXX="g++ -m64" configure
>>>
>>> --
>>> Alan Modra
>>> Australia Development Lab, IBM
>>
>