[Scummvm-devel] Problem with linking

[Max Horn]

Am 27.01.2006 um 18:19 schrieb Eugene Sandulenko:

> Hi,
>
> while working on Nokia770 port, I faced one interesting linker  
> problem.
>
> Nokia770 does not have any MIDI output, so only driver which gets
> compiled is null.cpp. But here we face following problem:
>
>   class MidiDriver_NULL : public MidiDriver_MPU401 {
>    ...
>   }
>
> and it does not implement many virtual methods which should go from
> MidiDriver_MPU401 superclass. It is located in sound/ directory.

I don't quite understand the second last sentence. What is wrong with  
the (virtual) methods of that class, precisely? As far as I can see,  
MidiDriver_NULL implements all pure virtual methods, so it's a  
concrete class.


> But in our Makefile.common we have this:
>
>   MODULES += ... sound backends ...
>
> And this successfully leads to unresolved symbols and broken vtables.
> We had similiar issue with MacOS X build.

Which were unfounded, IIRC. But yes, our builds are sensitive to the  
order of the MODULES, mostly due to the odd semantics of many SysV  
compatible Unix linkers (including GNU ld). Any change to the MODULE  
is potentially going to cause breakage somewhere under some conditions.

> So to resolve this issue I propose to move null.cpp file from
> backends/midi/ to sound/ directory and swap those modules (sound and
> backend) in Module.common file.

I know that the current order is "wrong", but this order is "wrong",  
too. There are things in sound that depend on backends, too. The real  
and only proper fix is to untangle backends and sound (and other  
stuff, for that matter further). I have planned to do this for a long  
time, but refrained doing it until we would have move to Subversion,  
because it involves moving lots of files around.

>
> What do you think?

I wouldn't want to move that file before we have Subversion. In fact,  
I have a ton of other files I want to move, and I simply always add  
them to a list in the TODO file...


Cheers,
Max