Re: 2.4.5-ac4 es1371.o unresolved symbols

[Keith Owens <kaos@ocs.com.au>]

On Thu, 31 May 2001 08:08:45 +0200, 
Vojtech Pavlik <vojtech@suse.cz> wrote:
>On Thu, May 31, 2001 at 11:29:06AM +1000, Keith Owens wrote:
>> With your patch, if a user selects CONFIG_INPUT_GAMEPORT=m and
>> CONFIG_SOUND_ES1370=y then the built in es1370 driver has unresolved
>> references to gameport_register_port() which is in a module, vmlinux
>> will not link.  That is why I derived CONFIG_INPUT_GAMEPORT based on
>> the config options in two separate directories.
>
>Have you tried the patch? Because the gameport.h define has:
>
>#if defined(CONFIG_INPUT_GAMEPORT) || (defined(CONFIG_INPUT_GAMEPORT_MODULE) && defined(MODULE))
>void gameport_register_port(struct gameport *gameport);
>void gameport_unregister_port(struct gameport *gameport);
>#else
>void __inline__ gameport_register_port(struct gameport *gameport) { return; }
>void __inline__ gameport_unregister_port(struct gameport *gameport) { return; }
>#endif

When the user has gameport hardware compiled it as a module and they
have es1371 bult into the kernel then es1371 silently ignores the
gameport, even if the gameport modules has been loaded.  This violates
the principle of least surprise, a user configuring both gameport and
es1371 expects to use the gameport, kbuild should support that instead
of silently ignoring the combination.