🚀 go-pugleaf

In article <p5ogjs8dgz.fsf@baynetworks.com>,
Paul D. Smith <psmith@baynetworks.com> wrote:
>
>What we'd like to do is find some kind of linker flag (or other method)
>that forces the entire contents of particular .a's to be linked, even if
>nothing appears to reference any of the symbols in some of the .o's in
>the archive.

GNU ld has the --whole-archive option (--no-whole-archive to turn it
off) that might work for you. Don't see that feature in most other 
linkers however.

Regards,
Mumit

[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]

psmith@baynetworks.com (Paul D. Smith) writes:

>Until now this hasn't been an issue, but now we're trying to introduce
>some dynamic loading using dlopen(), etc.  Yes, we do need to do it this
>way :).

>The problem is that some of the .so's need some particular functions,
>but nothing in the core binary needs those functions.  Since they're in
>archives but nothing references them during the link, they're not pulled
>into the core.  Since they're needed by more than one dynamic object
>(.so), we can't just put them in one.

You need to maek self-contained binaries; this may mean that you need
to make the archive libraries dynamic as well.

>What we'd like to do is find some kind of linker flag (or other method)
>that forces the entire contents of particular .a's to be linked, even if
>nothing appears to reference any of the symbols in some of the .o's in
>the archive.

Newer versions of the Solaris linker support "-z allextract" which
causes complete .a libraries to be loaded.

>I tried the docs for ld(1) but didn't see anything; surely this isn't
>such an unusual requirement?  Anyone have any ideas?

No, hence the new feature.  You may get lucky installing the latest
2.5.1 linker patches.


Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

psmith@baynetworks.com (Paul D. Smith) writes:

> I've seen that I can add -uSYMBOL to the link line and that works for a
> given .o, but it's gross since there will undoubtedly be many more cases
> of this in the future.  Similarly, I'd like to avoid dummy function
> calls, etc.
> 
> What we'd like to do is find some kind of linker flag (or other method)
> that forces the entire contents of particular .a's to be linked, even if
> nothing appears to reference any of the symbols in some of the .o's in
> the archive.
> 
> I tried the docs for ld(1) but didn't see anything; surely this isn't
> such an unusual requirement?  Anyone have any ideas?

I'd approach this problem something like this: as the last step of the
build process, automatically create a small .c file that contains the
references you want, by examining the public symbols contained in each
archive.  Then, compile that, and include it as one of the .o's on the
final link.  This avoids any dependency on special linker flags, plus,
it's fairly easily extensibleif you need finer grained control of what
is linked in and what isn't.

In your makefile, list the libraries that you want to force to be
linked in a specific variable, for example

        FORCE_LIBS = archive1.a archive2.a 

and so on.

Add a make target that looks like:

        librefs.c: $(FORCE_LIBS)

In the commands for this target, use "nm" to extract the public
symbols from the .a's in $(FORCE_LIBS), and from this, create a
librefs.c file that looks something like

        extern int symbol1;
        extern int symbol2;
        ...

        static void *references[] = {
                &symbol1,
                &symbol2, 
                ...
        };

(A file like this is strictly non-conforming C, since the declarations
of the symbols won't match the actual types, but it won't matter to
the linker.)

On my particular system, "nm -t -n" seems the right way to use nm
command for this purpose.  Each line of output looks like

        object|type|symbol

From output like this, a fairly straight-forward awk or perl script
should be able to generate the necessary C program.

Then, add librefs.o to the dependencies of the final build target, and
list it before any other objects on the link line.  The default make
rules will ensure librefs.c is built and up to date, and then compile
it into librefs.o, which will then provide references for each symbol
in your archives.

        program: librefs.o $(OBJECTS)
                $(LD) -o $@ pullin.o $(OBJECTS) ...

Dale.