[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: linking SPARC applications

On Sat, 2007-07-21 at 22:38 +1000, Jim Watson wrote:
> Martin wrote:
> > On Sat, 2007-07-21 at 16:53 +1000, Jim Watson wrote:
> >   
> >> Hi,
> >>
> >> I have been building SPARC applications -  I mean the shared libraries 
> >> report SPARC in response to the file command.
> >>
> >> Now I noticed these are linked to various standard libs in /lib/v9 which 
> >> report SPARC32PLUS, instead of linking to the required SPARC libs in /lib
> >>
> >> Is this something that has to be configured when building or is it 
> >> something happens when running ldd? (I only have sun4u here)
> >>     
> >
> > IIRC the output of ldd is something like
> >
> > libraryNameInProgram => /where/it/maps/to/on/this/system
> >
> > if the first is incorrect, you have to change you build system /
> > environment.  If the second is incorrect you have to change how ld is
> > set up on your system.
> >
> > Thus it would sound, to me, like your system was behaving correctly and
> > the binaries should work on sun4m.
> >
> Yes, but I like them to run on sparc (32) systems too.
sun4m are the only 32 bit sparc systems supported by Debian at the
moment as far as I know.  sun4 have been unsupported for a long time,
sun4c where dropped during the development of sarge IIRC and sun4d has
kernel issues and hasn't been supported for a while (and when they do,
they work much as sun4m).

> Previously they always linked to /lib/blah.
> Now something has changed so they now link to /lib/v9/blah
> But I didn't change my build system so I guess it is something changed 
> in debian.
> Thats the bit I don't understand - what has changed?
If the problem definately is with what ld maps the libraries to then it
is likely to be a problem / change in ld.  I would guess that someone
added a hack to the binary or the config file so that on sun4u it
attempts to load /lib/v9/ before /lib/.


 - Martin

Reply to: