Hi, I was considering to file this as a bug report, but I thought I'd first check on the list first. Sorry if this was already brought up (there's also a bug report which is somewhat similar to my problem - automake PR number 55).
So, my problem is that for some reason in our projects some libraries *have* to be linked in using a --whole-archive/--no-whole-archive wrap around them. I also use --start-group/--end-group when I have to add a long list of libraries (dozens) and I don't want to waste time trying to put them in the right order. Now, how would we add those libraries to the linker options in my Makefile.am files? Option 1: add the directories to <binary>_LDFLAGS (-L<dir1> ...) and then the libraries with -l<lib1> ..., wrapped around with --whole-archive in <binary_LDADD>. However, this doesn't work, since you can't add linker options in <binary_LDADD>: linker flags such as `-Wl,--whole-archive' belong in `<binary>_LDFLAGS is the error message printed by automake when you try to do that. The same happens with --start-group/--end-group. This is also documented in the automake manual I have. Option 2: OK, so what if we try to add the libraries in <binary>_LDFLAGS? Well, that one doesn't work either. Why? Well, the linker command generated is like this: $(CXXLINK) $(binary_LDFLAGS) $(binary_OBJECTS) $(binary_LDADD) $(LIBS) Can you spot the problem? Yes, _LDFLAGS comes *before* _OBJECTS; due to the way the GNU linker (and other UNIX linkers, by tradition) works, the order of libraries and objects matters. So any symbols referenced in <binary>_OBJECTS, but not in <binary_LIBRARIES> will show up as unresolved. Oops. It won't work if you try to change <binary>_LINK, unless you have no objects to link to the binary (which is true for some of the targets we use - they just link libraries into a binary, as funny as that may seem). Because <binary>_LINK is the command that gets passed the list of objects for the binary, so the objects still end up at the end of the command. Oops again. So the only option is to write your own <binary> target that does exactly what you want. But then why use automake in the first place? Am I missing something, or is this setup as bad as it seems? I think in most cases it's likely that <binary>_OBJECTS will use an object in one of the linked in libraries that wasn't used in libraries linked before. If you don't need any linker options, then _LDADD comes to the rescue. But otherwise? How would that be solved? Wouldn't it make sense to just raise the limitation on _LDADD? That would fix my problem. I think the LDADD limitation (documented in the automake manual here: http://www.gnu.org/software/automake/manual/html_node/Linking.html#Linking) is simply overlooking sane linker options like --start-group, which make sense to be used in Makefile.ams. I'm using automake 1.9.5, and GNU make 3.80. Stefan.
