[kbuild-devel] Re: 2.5 kbuild: use of '-z muldefs' for LD?
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 --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: 2.5 kbuild: use of '-z muldefs' for LD?
*grr* Can you _please_ stop the stupid practice of Cc'ing members-only lists? Thanks. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: 2.5 kbuild: use of '-z muldefs' for LD?
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 MYPREFIXKBUILD_MODNAME or something like that --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: 2.5 kbuild: use of '-z muldefs' for LD?
[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 --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: 2.5 kbuild: use of '-z muldefs' for LD?
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 --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: 2.5 kbuild: use of '-z muldefs' for LD?
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 --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
