Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 25 Sep 2012 01:11:15 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Compiling musl with pcc...

On Sun, Sep 23, 2012 at 06:19:24PM -0700, Isaac Dunham wrote:
> With the new -print-file-name option for pcc, I've managed to get musl's configure to recognize pcc. (See pcc-configure.diff)
> But I've run into one other problem: when 
> -mtune=generic -march=486
> is passed to pcc in the linking stage, it appears that pcc passes some invalid option to ld (I get "Unrecognized option: tune=generic", as shown at the very end of make.pcc).
> Should the -m... options be omitted from what pcc passes to ld?

Yes, this sounds like a pcc bug. Perhaps we should avoid passing
CFLAGS when linking anyway, tho..? Is there any standard on this?

> Additionally, if I work around that, I get a segfault when running hello world (via .../lib/libc.so a.out):
> (gdb output)
> program received signal SIGSEGV, Segmentation fault.
> 0x755b91d9 in __syscall_cp ()
> (gdb) where
> #0  0x755b91d9 in __syscall_cp ()
> #1  0x7557268a in open64 ()
> #2  0x755779ad in __dynlink ()
> #3  0x7557858d in _start ()
> I'll try rebuilding with -O0 -g3.
> (Rich: in case you're wondering, -Bsymbolic-functions is being properly passed)

Can you look at the disassembly and report where in __syscall_cp the
crash happened?

> +tryccprint () {
> +printf "checking CC -print-file-name for %s... " "$2"
> +CC_FILE="`$CC -print-file-name=$2`"
> +L="-L`dirname $CC_FILE` `basename $CC_FILE .a |sed -e 's/^lib/-l/'`"
> +echo "typedef int x;" > "$tmpc"
> +if "$CC" -nostdlib -shared "$L" -o /dev/null "$tmpc" 2>/dev/null ; then
> +printf "yes\n"
> +eval "$1=\"\${$1} \$L\""
> +eval "$1=\${$1# }"
> +return 0
> +else
> +printf "no\n"
> +return 1
> +fi
> +}

Is there a reason for all of this rather than just trying -lpcc? The
reason we didn't do that before is that the path to libpcc.a was not
in pcc's search path passed to the linker; it was just hard-coding the
whole pathname of libpcc.a and passing that. If -lpcc is in the path
now we can just try it.

Rich

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ