musl path

musl path

[nicolas]

Hi all, 

I managed to compile and to install musl on a test system.
However, i have some questions...

First, is it possible to add to the config.mak file the possibility to
change the includedir path ?
For example, i want to install the libraries on /lib and the headers on
/usr/include, and i had to add manually this entry to the config.mak
file...

Secondly, is it possible to remove properly the musl-gcc wrapper ?
I don't need it ;)

Cheers,
Nick

Re: musl path

[Szabolcs Nagy]

* nicolas@atelier-web.com <nicolas@atelier-web.com> [2011-08-06 17:44:52 +0200]:
> First, is it possible to add to the config.mak file the possibility to
> change the includedir path ?
> For example, i want to install the libraries on /lib and the headers on
> /usr/include, and i had to add manually this entry to the config.mak
> file...
> 
> Secondly, is it possible to remove properly the musl-gcc wrapper ?
> I don't need it ;)

config.mak is included after all  variable declarations in the Makefile
so you can freely change those variables in config.mak

eg:

prefix=we_dont_use_prefix_at_all
includedir=/usr/include
libdir=/lib
ALL_TOOLS=

Re: musl path

[nicolas]

On Sat, 6 Aug 2011 18:28:03 +0200, Szabolcs Nagy <nsz@port70.net> wrote:
> * nicolas@atelier-web.com <nicolas@atelier-web.com> [2011-08-06 17:44:52
> +0200]:
>> First, is it possible to add to the config.mak file the possibility to
>> change the includedir path ?
>> For example, i want to install the libraries on /lib and the headers on
>> /usr/include, and i had to add manually this entry to the config.mak
>> file...
>> 
>> Secondly, is it possible to remove properly the musl-gcc wrapper ?
>> I don't need it ;)
> 
> config.mak is included after all  variable declarations in the Makefile
> so you can freely change those variables in config.mak
> 
> eg:
> 
> prefix=we_dont_use_prefix_at_all
> includedir=/usr/include
> libdir=/lib
> ALL_TOOLS=

Thanks :)
And is there a way to remove the gcc wrapper ?

Re: musl path

[Rich Felker]

On Sat, Aug 06, 2011 at 10:14:33PM +0200, nicolas@atelier-web.com wrote:
> > prefix=we_dont_use_prefix_at_all
> > includedir=/usr/include
> > libdir=/lib
> > ALL_TOOLS=
> 
> Thanks :)
> And is there a way to remove the gcc wrapper ?

Setting ALL_TOOLS blank will prevent it from being installed.

By the way, I'm thinking of moving the gcc wrapper to a separate
repository/tarball along with improving it, at some point in the near
future. I don't really like the clutter of having it
distributed/installed with musl, and as a separate standalone tool I
could make it work with uclibc and other libcs as well..

I'd welcome comments from users who like or dislike this idea.

Rich

Re: musl path

[nicolas]

Ah... Okay :)

I think that to have a separate tarball for the wrapper is the better
way...
Do you plan to generate wrapper for the others C Compiler (PCC /
TinyCC...) ?

Cheers,
Nick

On Sat, 6 Aug 2011 16:27:36 -0400, Rich Felker <dalias@aerifal.cx> wrote:
> On Sat, Aug 06, 2011 at 10:14:33PM +0200, nicolas@atelier-web.com wrote:
>> > prefix=we_dont_use_prefix_at_all
>> > includedir=/usr/include
>> > libdir=/lib
>> > ALL_TOOLS=
>> 
>> Thanks :)
>> And is there a way to remove the gcc wrapper ?
> 
> Setting ALL_TOOLS blank will prevent it from being installed.
> 
> By the way, I'm thinking of moving the gcc wrapper to a separate
> repository/tarball along with improving it, at some point in the near
> future. I don't really like the clutter of having it
> distributed/installed with musl, and as a separate standalone tool I
> could make it work with uclibc and other libcs as well..
> 
> I'd welcome comments from users who like or dislike this idea.
> 
> Rich

Re: musl path

[Jens Staal]

I would definitely like the idea of the wrapper being a general tool
for various libc's.

Especially nice in order to play with the libc benchmarks (I tried
making AURs for them but could not figure out how to get the different
builds to use the different libcs installed on the system).

If the wrappers also could include a number of different compilers,
that would be great :)

2011/8/6 Rich Felker <dalias@aerifal.cx>:
> On Sat, Aug 06, 2011 at 10:14:33PM +0200, nicolas@atelier-web.com wrote:
>> > prefix=we_dont_use_prefix_at_all
>> > includedir=/usr/include
>> > libdir=/lib
>> > ALL_TOOLS=
>>
>> Thanks :)
>> And is there a way to remove the gcc wrapper ?
>
> Setting ALL_TOOLS blank will prevent it from being installed.
>
> By the way, I'm thinking of moving the gcc wrapper to a separate
> repository/tarball along with improving it, at some point in the near
> future. I don't really like the clutter of having it
> distributed/installed with musl, and as a separate standalone tool I
> could make it work with uclibc and other libcs as well..
>
> I'd welcome comments from users who like or dislike this idea.
>
> Rich
>

Re: musl path

[Rich Felker]

On Sun, Aug 07, 2011 at 12:46:47PM +0200, Jens Staal wrote:
> I would definitely like the idea of the wrapper being a general tool
> for various libc's.
> 
> Especially nice in order to play with the libc benchmarks (I tried
> making AURs for them but could not figure out how to get the different
> builds to use the different libcs installed on the system).
> 
> If the wrappers also could include a number of different compilers,
> that would be great :)

I think for most compilers it's trivial. As far as I know, gcc is the
only one I know that insists on still passing all the unwanted -L
paths to the linker even when you told it -nostdlib...

Rich

Re: musl path

[gs]

> By the way, I'm thinking of moving the gcc wrapper to a separate
> repository/tarball along with improving it, at some point in the near
> future. I don't really like the clutter of having it
> distributed/installed with musl, and as a separate standalone tool I
> could make it work with uclibc and other libcs as well..
>
> I'd welcome comments from users who like or dislike this idea.
improving the wrapper and supporting additional libc's sounds like a 
good thing.
tho having the wrapper automatically installed with the right paths set 
is also good.
i'd continue providing the wrapper with musl for now, since a newer 
version of the wrapper may not be compatible with an older musl version. 
also new users would have to configure two things instead of one.