Alastair McKinstry <[EMAIL PROTECTED]> 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:
> [EMAIL PROTECTED]:/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.
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
