2

Let's say I have a dynamic library (.so). What happens if I link to it using --start-group --end-group?
Is it treated as an archive, so that all necessary symbols are "physically" included in my output library?
Or is it treated still as dynamic library (equivalent to use -l option)?

Reading the documentation one could think it will be treated as archive, but in fact it is also said that it is not possible to statically link to a shared library.

Community
  • 1
  • 1
Antonio
  • 19,451
  • 13
  • 99
  • 197
  • 1
    The documentation you cite starts with "The *archives* should be a list of archive files", where "archives" designates the arguments between `--start-group` and `--end-group`. A shared library, or an `-l` argument corresponding to one, is not an archive file in this sense. The docs do not say that the files so designated will be treated as archive files; they say that it is *your responsibility* to specify (only) archive files there. – John Bollinger Sep 27 '16 at 17:25
  • @JohnBollinger It remains untold what will happen if there one puts a dynamic library. – Antonio Sep 27 '16 at 17:33
  • 1
    Yes, because there is no documented or expected behavior for that case, so there is no reliable answer, except possibly "try it and see". Under no circumstance can a shared library usefully be treated as an archive file, however. – John Bollinger Sep 27 '16 at 18:02

1 Answers1

1

The -group options only affect in which libraries/archives (and how many times) the linker will look for symbols to satisfy unresolved references. There's no equivalent of --whole-archive for dynamic libs, e.g. .so objects. What you can do is specify --no-as-needed prior to referencing the library which will force it to be added to the list of needed DSOs for the dynamic linker (see below for an example that uses this technique).

To explain what these are intended for, continuing the linker tradition in which ordering linker flags is of the utmost importance, the --start-group and --end-group options establish a bounded range of objects and libraries that will be repeatedly scanned through in order of appearance until none of them contribute any further symbols (or unresolved references, which would necessitate further scanning).

It's commonly used for linking objects which have conplex interdependencies, and/or circular references. An alternative is specifying each object/lib potentially many times, like GCC does when linking to libgcc on this *nix system:

-lgcc --as-needed -lgcc_s --no-as-needed -lc 
   -lgcc --as-needed -lgcc_s --no-as-needed crtend.o crtn.o

(-lgcc_s referring to shared-library GCC support routines, e.g., libgcc_s.so.1, on which libc (-lc) and libgcc(-lgcc, a static lib) depend; this creates a cycle requiring another inclusion of -lgcc_s) to resolve new unresolved refs that each object brings with it.

Note that GNU LD (-fuse-ld=bfd) can handle nested groups, while GNU Gold (-fuse-ld=gold) cannot. Not sure about LLVM's linker.

greyblue9
  • 31
  • 1
  • 4