Re: multiarch proposal

[Goswin von Brederlow <goswin-v-b at web dot de>]

"Matt Rice" <ratmice@gmail.com> writes:

> On Fri, May 2, 2008 at 4:46 AM, Goswin von Brederlow <goswin-v-b@web.de> wrote:
>> "Matt Rice" <ratmice@gmail.com> writes:
>>
>>  >...
>>  > anyhow... it doesn't seem like something which absolutely requires ld support,
>>  > its just rather tedious when doing it at a distribution level having
>>  > to manually specify everythings libdir...
>>
>>  ld is just the one common point in all of this where a trivial change
>>  would solve the problem. And the cost for systems not using it is a
>>  measly stat call.
>
> yes, this is exactly why i've never bothered to build a system using
> the mechanism i described...
>
> maybe something similar to the construct member of struct cpp_dir in
> cpplib.h of gcc
>
>   /* Routine to construct pathname, given the search path name and the
>      HEADER we are trying to find, return a constructed pathname to
>      try and open.  If this is NULL, the constructed pathname is as
>      constructed by append_file_to_dir.  */
>   char *(*construct) (const char *header, cpp_dir *dir);
>
> this sort of mechanism might allow both our library layouts to be possible
>
> e.g. your platforms construct returns "%s/%s/lib%s.so", dir->name,
> arch, lib->name);
> e.g. any my platforms construct returns "%s/%s/%s/lib%s.so",
> dir->name, lib->name, arch, lib->name);
>
> though i'm not sure how to apply this when driven by linker scripts

You have to do this for the search path though. There are multiple
directories to search and the existing default dirs would have to be
in the mix as well for a verry long time.

And, hey look, the ldscript already lists the search paths and they
are generated during build. That's where my patch plugs in the new
dirs. :)

MfG
        Goswin