Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1369503.9MkYmHAvz4@linuix>
Date: Sun, 17 Jun 2012 19:33:26 +0200
From: Bruno Haible <bruno@...sp.org>
To: Rich Felker <dalias@...ifal.cx>, musl@...ts.openwall.com
Subject: installation without root privileges

Hi,

When installing musl-0.9.1 according to the recipe of INSTALL, Option 1,

CC="gcc-32" \
  ./configure --prefix=/arch/x86-linux/inst-musl \
              --exec-prefix=/arch/x86-linux/inst-musl \
              --target=i686-unknown-linux-gnu \
              CC="gcc-32"

the "make install" ends like this:

...
install -D -m 644 include/wctype.h /arch/x86-linux/inst-musl/include/wctype.h
install -D -m 644 include/wordexp.h /arch/x86-linux/inst-musl/include/wordexp.h
install -D tools/musl-gcc /arch/x86-linux/inst-musl/bin/musl-gcc
ln -sf /arch/x86-linux/inst-musl/lib/libc.so /lib/ld-musl-i386.so.1 || true
ln: could not create symbolic link „/lib/ld-musl-i386.so.1“: Permission denied

But the /arch/x86-linux/inst-musl/lib/musl-gcc.specs, section *link,
contains a reference to the file /lib/ld-musl-i386.so.1 that could not be
installed. My solution was to change this to read:

*link:
%(old_link) -dynamic-linker /arch/x86-linux/inst-musl/lib/libc.so -nostdlib

Suggestion: When --disable-gcc-wrapper is not passed to configure (this is
what distinguishes "Option 1" from "Option 2", right?), don't even attempt
to put a symlink into /lib. Simply always put the libc.so's real filename
into the *link section of musl-gcc.specs. The drawback is that executables
built with musl can typically not be transferred to a different machine
(because that machine will likely use a different installation directory
for musl).

Bruno

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.