On Thu, Feb 28, 2008 at 08:25:13AM -0800, Marc Glisse wrote: > > LD_OPTIONS=-Mmapfile1 make app1 > > LD_OPTIONS=-Mmapfile2 make app2 > > ... > > Perhaps we need an LD_OPTIONS_<object name> variable > > Wouldn't it be sufficient to define a magic sequence (say '%t') that, > when it appears in a mapfile name, should be replaced by the target? > This way you could pass -Mmapfile.%t all the time and just write files > mapfile.sqlite3, mapfile.libsqlite3.so, etc.
I want to be able to specify a mapfile for all executables without regard to the object's name since we almost always use the same mapfile for executables (noexecstack; some exceptions exist in ONNV), but different map files for each shared object since shared objects almost always have unique mapfiles (because they almost always refer to symbols in the object, whereas mapfiles for executables almost never do). So something like -Mmapfile.%t:mapfile.noexecstack would do (where the colon separates alternatives and the linker tries one first, then the other until it finds one). > Actually, quite often there is only one target for each directory, so > using the 'mapfile' name and having the appropriate file in each > directory is sufficient, although this does not seem to be the case > with sqlite3. It isn't the case for sqlite3 and I wouldn't assume that sqlite is and exception, rather than the rule. > I am just a bit scared that adding LD_OPTIONS_<target> is a first step > towards reinventing makefiles or even libtool inside the linker... It's a gross workaround for libtool braindedness. But your approach (modified as I suggest) would be too. I don't prefer one or the other. Or maybe I do, since linker options other than -M might have to vary by target too. We should, of course, fix libtool and all the things that consume it. And we should boil the oceans while we're at it :) But until we're done doing that a linker workaround would be great! Nico --
