This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: multiarch proposal


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]