On Mon, Jun 09, 2003 at 01:04:38PM +0100, Christoph Hellwig wrote:
> On Mon, Jun 09, 2003 at 01:56:59PM +0200, Jaroslav Kysela wrote:
> > one object file for more targets. Example:
> > ------
> > snd-ice1712-objs := ice1712.o delta.o hoontech.o ews.o ak4xxx.o
> > snd-ice1724-objs := ice1724.o amp.o revo.o aureon.o ak4xxx.o
> > # Toplevel Module Dependency
> > obj-$(CONFIG_SND_ICE1712) += snd-ice1712.o
> > obj-$(CONFIG_SND_ICE1724) += snd-ice1724.o
> > ------
> > The ak4xxx.o module is shared and has defined a few public functions.
> > Unfortunately, the default build-in.o rule fails when targets are
> > requested to be included into the solid kernel because the public
> > functions are duplicated in snd-ice1712.o and snd-ice17124.o.
> > I can instruct the ld compiler to ignore the multiple definitions using
> > '-z muldefs':
> > EXTRA_LDFLAGS = -z muldefs
> > But it seems like a hack for me.
> > Does anybody have another idea to solve my problem?
> Move ak4xxx.o out of the multi-obj rules. Just declare a new helper-
> config option CONFIG_SND_AK4XXX that gets defined by all drivers
> using it and add
> obj-$(CONFIG_SND_AK4XXX) += ak4xxx.o
Would it be worthwhile to resolve common functions from a library instead?
On request from Linus I made the lib-y change, and it is getting
a lot easier to create libraries.
So ak4xxx.o would be used to create lib.a in that particular directory.
A limitation would be that libaries would only be valid for current
directory - but that is OK for this situation.
On the other hand there should be very good reasons to clutter up the
build-system with this, so more users than sound is required.
[Will there be problems with modules exporting symbols?]
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jun 15 2003 - 22:00:21 EST