Guy Harris wrote:
You meant "three tiny patches." :-)
Yoshihiro Oyama wrote:
* fix: link error of plugins/irda/packet-irda.o with
--enable-static
Checked in.
That fix reveals an ugly problem - the top-level Makefile.am not only
has to know all the plugins, to put them into the plugin_ldadd list for
non-static builds, it has to know the names of all the object files for
those plugins, to put them into the plugin_ldadd list for static builds.
That means that if a new plugin is added, *all* the object names need to
be listed there - you can't just put, for the "xyzzy" plugin,
"packet-xyzzy.o", if that plugin has more than one object file.
It also means that if a new object file is added to a plugin, the
top-level Makefile.am has to be updated.
Is there a better way to do this? For example, could a static build
construct a ".a" file (on UN*X; I don't know whether a ".lib" file or a
".a" file or what would be built on Windows+Cygwin or any other Windows
build environment that would use autoconf and other UN*Xy tools) in the
plugin directory, with all the ".o" files added to it, and link have the
".a" file be in the plugin_ldadd list? At least that way only the
plugin's Makefile.am file would have to know what object files are in
the plugin.
From a *nix'ish perspective, if the objects are compiled so as to be
shareable, putting them in a "libxxx.a" doesn't break that. Then when
you come to link, whether it be for a shared lib or not, you can include
them as -L/whereever/ -lxxx
Why shouldn't that work just as well on Windows?
You might even come up with a command line that works with Solaris'
default sed :-)
--
There's no point in being grown up if you can't be childish sometimes.
-- Dr. Who
