[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140906161004.GU23797@brightrain.aerifal.cx>
Date: Sat, 6 Sep 2014 12:10:04 -0400
From: Rich Felker <dalias@...c.org>
To: Weldon Goree <weldon@...gurwallah.org>
Cc: musl@...ts.openwall.com
Subject: Re: Packaging: Slackware
On Mon, Jul 21, 2014 at 08:12:58PM +0530, Weldon Goree wrote:
> On 07/21/2014 07:45 PM, Rich Felker wrote:
> >
> > Yes. I'm still not clear though on whether the intent is to provide an
> > environment for musl-[dynamic-]linked programs running on Slackware,
> > or more for a development environment using the musl-gcc wrapper. This
> > might affect the stability requirements. Of course if it's just a
> > development environment using the wrapper, there may not be a lot of
> > point in packaging that since you already need a compiler to use it,
>
> The intent is to provide a build script that builds a musl environment
> that one could then use to build other build scripts in the repository
> (James B's description was good). I'm trying to get some anecdata on
> what the people who mentioned being interested in a musl build script
> want (cross toolchain vs. gcc wrapper with some environment setup vs.
> just the library itself).
>
> The point of making a build script in the trivial case is that it
> integrates it (in a predictable way) with slackware's package
> management/file finding system ("where did I put the cross-x86 version's
> files again?", etc.).
Just ran across the slackbuild from a user asking questions about it,
and found one thing that really should be fixed: it's passing
--syslibdir=/usr/lib${LIBDIRSUFFIX} to the configure script. This will
result in dynamic-linked programs built against musl using your
slackbuild working only on slackware systems with the same slackbuild,
and not being portable to other systems. --syslibdir is where the
dynamic linker is found, and it needs to be an invariant for all
systems, and it should be "/lib". The only reason configure allows you
to change it at all is for doing local installations as a non-root
user, and in this case your dynamic-linked binaries won't be portable.
If you fix this, it would be nice for new versions of the package to
keep a symlink to the dynamic linker in the old location, so that old
binaries continue to work while new ones are built with the standard
dynamic linker location and portable to other systems.
Rich
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.
