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

Bug#172828: mklibs : problem on mips

Alastair McKinstry <mckinstry@computer.org> writes:

> I'm writing to you as the authors of mklibs

Damn. Why does everybody think I know how mklibs works just because I
wrote it? ;) Seriously, I just stole most stuff from existing scripts,
I'm not really an expert on dynamic linking...

> They are found in libc. Now, in i386, for example, they are of type:
> eg. 
>   NOTYPE  WEAK   DEFAULT  UND  _pthread_cleanup_pop_restore
> But on MIPs, they are all:
> mckinstry@repeat:/lib$ readelf -s -W libc.so.6 | grep  WEAK | grep UND |
> grep FUNC
>   2023: 00000000     0 FUNC    WEAK   DEFAULT  UND  _pthread_cleanup_push_defer
> I believe this means they are all weak objects, not "normally"
> marked as such.  They will resolve to zero if not found elsewhere,
> but undefined_symbols() in mklibs treats them simply as undefined.

I am not quite sure about how to handle weak symbols properly. If they
are provided somewhere, we would usually want them to be used. So just
ignoring all weak symbols doesn't seem proper.

The best way seems to be to check whether the set of unresolved
symbols didn't change since the last pass, and if so, whether it
consists of only weak symbols. If so, just leave them undefined and
quit. Otherwise abort (better than looping infinitely). Does that
sound sensible?

I'm a bit short on time currently, I'll see whether I can make a patch
the next few days.


Reply to: