Nicolas Williams wrote:
> BACKGROUND
>
> I'm working on integrating SQLite3.x into the SFW consolidation.
>
> You can find the webrev here:
>
> http://cr.opensolaris.org/~nico/webrev-sqlite3-sfw-2nd/
>
> The files relevant to this post are:
>
> http://cr.opensolaris.org/~nico/webrev-sqlite3-sfw-2nd/usr/src/lib/sqlite3/install-sfw.html
> http://cr.opensolaris.org/~nico/webrev-sqlite3-sfw-2nd/usr/src/lib/sqlite3/Makefile.sfw.html
>
>
> PROBLEM
>
> ld: warning: global symbol `sqlite3StrAccumFinish' has non-global binding:
> (file /usr/lib/libsqlite3.so value=LOCL);
>
> results from my use of elfedit(1) (instead of a mapfile) to reduce
> symbol scope of internal interfaces of libsqlite3. You can see this in
> $SRC/lib/sqlite3/install-sfw (URL is above).
>
> I used elfedit(1) instead of a mapfile because libtool is a pain but
> that's what sqlite3's build uses. Perhaps there's a way to easily patch
> SQLite3's Makefile.in to specify a mapfile when building libsqlite3, but
> if not then by far the simplest thing to do is to use elfedit(1), or
> else not reduce symbol scope at all.
>
>
> QUESTIONS
>
> - What's the best way to reduce symbol scope of internal interfaces in
> libsqlite3?
>
> - If through a patch to its Makefile.in, how does one tell libtool to
> use a mapfile?
>
> - If there's no easy way to get libtool to use a mapfile, what's the
> next best option?
>
> Using LD_OPTIONS from $SRC/lib/sqlite3/Makefile turned out to be
> painful. I'd have to have many targets in that makefile that reflect
> knowledge of internal details of the SQLite3 build.
>
> - Should I give up on symbol scope reduction?
>
> Or should ld(1) just not bother with these particular warnings?
>
>
> Thanks,
>
> Nico
Well, first off, thank you for using elfedit!
I don't know about using it for scope reduction though. The problem is that the
linker created a global symbol, and as a result:
- Puts it in the global part of the symbol table
- Puts it in the hash table (making it eligible for
global access from outside.
Going in with elfedit and marking it as local doesn't change the fact that
it is in the wrong part of the symbol table, and that it is still visible
from the hash table. So I don't think this is going to be a good answer.
It's probably good that ld complains.
Which leaves using a mapfile somehow, or punting on scope reduction.
- Ali
