Hello all,
I am trying to figure the best solution for our problem. We reuse
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?
Jaroslav
-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
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
You'll just have to make sure to export all symbols in 2.5
*grr*
Can you _please_ stop the stupid practice of Cc'ing members-only
lists? Thanks.
On Mon, 9 Jun 2003, 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
>
> You'll just have to make sure to export all symbols in 2.5
But this solution will create a new kernel module. The shared code is
really small and having small codes in separated modules is waste of
memory in my eyes.
Jaroslav
-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
On Mon, Jun 09, 2003 at 04:01:41PM +0200, Jaroslav Kysela wrote:
> But this solution will create a new kernel module. The shared code is
> really small and having small codes in separated modules is waste of
> memory in my eyes.
Well, if you want separate copies of it you have to make sure the
symbols won't clash, e.g. calling all functions in it
MYPREFIX_foo
and then do #define MYPREFIX KBUILD_MODNAME
or something like that
[Christoph Hellwig]
> Well, if you want separate copies of it you have to make sure the
> symbols won't clash, e.g. calling all functions in it
>
> MYPREFIX_foo
>
> and then do #define MYPREFIX KBUILD_MODNAME
...or just move everything into a header file as static functions.
Inline, even, if the code is really trivial enough that you don't want
to make a separate module of it.
Peter
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.
Comments?
[Will there be problems with modules exporting symbols?]
Sam
On Mon, 9 Jun 2003, 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
I basically second this, though you don't even need a new config variable.
snd-ice1712-objs := ice1712.o delta.o hoontech.o ews.o
snd-ice1724-objs := ice1724.o amp.o revo.o aureon.o
# Toplevel Module Dependency
obj-$(CONFIG_SND_ICE1712) += snd-ice1712.o ak4xxx.o
obj-$(CONFIG_SND_ICE1724) += snd-ice1724.o ak4xxx.o
If you think the functions are too trivial to justify a module of their
own, you may want to consider to put them as static inline into a header
file, as someone else suggested.
--Kai