recipe for target 'mpih-add1-asm.lo' failed
Closed, InvalidPublic
Actions

Assigned To

None

Authored By

	alexlai
	Dec 28 2015, 1:31 AM

Description

compilation failed at:

libtool: compile: gcc -m32 -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -
D_REENTRANT -g -O2 -MT mpih-add1-asm.lo -MD -MP -MF .deps/mpih-add1-asm.Tpo -c
mpih-add1-asm.S -fPIC -DPIC -o .libs/mpih-add1-asm.o
Assembler:

"/var/tmp//ccshs5el.s", line 25 : Syntax error
Near line: " addl $(Loop-L0-3),%eax"

Makefile:590: recipe for target 'mpih-add1-asm.lo' failed
make[2]: * [mpih-add1-asm.lo] Error 1
make[2]: Leaving directory '/home/alelai/libgcrypt-1.6.4.src/mpi'
Makefile:477: recipe for target 'all-recursive' failed
make[1]: * [all-recursive] Error 1
make[1]: Leaving directory '/home/alelai/libgcrypt-1.6.4.src'
Makefile:408: recipe for target 'all' failed
make: *** [all] Error 2

I think below is the relevant code:

#ifdef PIC
/* Calculate start address in loop for PIC. Due to limitations in some

assemblers, Loop-L0-3 cannot be put into the leal */
     call    L0

L0: leal (%eax,%eax,8),%eax

addl    (%esp),%eax
addl    $(Loop-L0-3),%eax
addl    $4,%esp

#else
/* Calculate start address in loop for non-PIC. */

leal    (Loop - 3)(%eax,%eax,8),%eax

#endif

Details

Version: 1.6.4

Event Timeline

747_config.log102 KBDownload

alexlai added projects: libgcrypt, Bug Report.Dec 28 2015, 1:31 AM

alexlai set Version to 1.6.4.

alexlai raised the priority of this task from Normal to Unbreak Now!.Dec 28 2015, 7:34 PM

According to the posted config log this seems to be about
SunOS 5.10 on i86.

The extra option CC=-m32 is used with configure.

gcc versions is 5.2.
The linker is /usr/ccs/bin/ld, i.e. not GNU ld.

• werner lowered the priority of this task from Unbreak Now! to Normal.Jan 5 2016, 12:50 PM

the OS shows ld is resolved to GNU ld:
$ which ld
/home/alelai/binutils-2.25/bin/ld

not sure why configure script pick up the ccs version.
I tried:
export LD=/home/alelai/binutils-2.25/bin/ld

configure shows:
...
checking if the linker (/home/alelai/binutils-2.25/bin/ld) is GNU ld... yes
...
(please see the attached new config.log.20160107)

But the error occurred:

Assembler:

"/var/tmp//ccFCDwOq.s", line 25 : Syntax error
Near line: " addl $(Loop-L0-3),%eax"

749_config.log.20160107102 KBDownload

According to this, setting LD is not sufficient to make gcc use a different linker.

On Solaris, GCC by default is compiled with the option –with-ld=/usr/ccs/bin/ld, telling it to use the Solaris linker. Unfortunately GCC uses this value above all else, meaning it will ignore LD= environment variables to set an alternative linker, such as /usr/sfw/bin/gld

Although tools like libtool/autoconf will pick up your LD= environment variable, and detect which options the linker supports (and whether its GNU ld or not), libtool unfortunately still calls gcc for the linking stage, which then ignores LD=. This makes it near-impossible to use GNU ld without actually doing a nasty hack, like “mv /usr/ccs/bin/ld /usr/ccs/bin/ld.off ; ln -s /usr/sfw/bin/ld /usr/ccs/bin/ld”. Yuck!

However, today when trying to get lame to compile using nasm (which generates objects that refuse to link with Solaris LD), I found Solaris LD accepts a very useful environment variable. The variable is LD_ALTEXEC.

Solaris LD will actually re-exec the value of LD_ALTEXEC, meaning that if you set LD_ALTEXEC to /usr/sfw/bin/gld, when /usr/ccs/bin/ld gets called, it immediately instead calls /usr/sfw/bin/gld with the arguments passed on. Thus, you can use whatever linker you wish. Hurrah! :-)

Feel free to do more experiments, but for now I am closing here. Reopen if you can reproduce this with GNU ld.