Re: [Guidolib-devel] 64 bit platform related bugs

[Dominique F. <fo...@gr...>]

Hi Bart,

Le 16 juin 09 à 11:52, Bart Spaans a écrit :

> Hi there,
>
> I tried to compile guidolib 1.37 on 64bit Linux today, but ran into
> some problems:
>
>
> In src/graphic/GRSingleNote.cpp:
>
> ../src/graphic/GRSingleNote.cpp: In member function ‘virtual char*
> GRSingleNote::getGGSInfo(int) const’:
> ../src/graphic/GRSingleNote.cpp:143: error: cast from ‘const
> GRSpring*’ to ‘int’ loses precision
> ../src/graphic/GRSingleNote.cpp:145: error: cast from ‘const
> GRSpring*’ to ‘int’ loses precision
> ../src/graphic/GRSingleNote.cpp: In member function ‘virtual void
> GRSingleNote::GGSOutput() const’:
> ../src/graphic/GRSingleNote.cpp:180: error: cast from ‘const
> GRSingleNote*’ to ‘int’ loses precision
> ../src/graphic/GRSingleNote.cpp:190: error: cast from ‘const
> GRSingleNote*’ to ‘int’ loses precision
>

these errors are related to GGS (Guido Graphic Stream), a work in  
progress but actually stalled...
it could be safely moved out of the compiled code using conditional  
inclusion (e.g. #define and #ifdef)

> Line 143, 145: prevspring and nextspring should be casted to long int
> instead of int. Furthermore, snprintf's format string should use %ld
> instead of %d.
> Line 180, 190: el->setID should both cast to long int instead of int.
>

fine ! I've made the changes and they are committed to trunk.

>
> In ../src/graphic/GRTempo.cpp:
>
> ../src/graphic/GRTempo.cpp: In member function ‘void
> GRTempo::DrawText(VGDevice&, const char*, float, float, float*)
> const’:
> ../src/graphic/GRTempo.cpp:237: error: ‘strlen’ was not declared in  
> this scope
>
> This file should include string.h
>

that's already fixed, but not yet on trunk.

>
> After fixing this compilation of the static library went fine, but I
> was looking for a dynamic library (to load from within Python).

you're probably using the linux/makefile. It should become obsolete  
soon. The preferred way is now to use cmake to generate the makefiles/ 
porjects for each platform/environment. It generates a dynamic  
library. See the cmake folder.

> Some
> changes in the Makefile gave me one eventually, but when I tried to
> load it, it immediately segfaulted. I'm not sure if this was also a 64
> bit related issue or that I screwed something up, but it did raise
> some questions regarding the cross-platformness of it all. My question
> is basically: is 64 bit supported or should I stop trying to get it to
> run and try to compile it with 32 bit libs?

As far as I know, the library has never been compiled on 64 bits  
architectures.
I've made the changes to compile for Mac OS X 64 bits... and bumped  
into some lack of support from the system libraries and even from some  
system include files that don't support 64 bits arch.
Unfortunately, I miss a 64 bits linux station to test.  Did you tried  
a 32 bits version to see if the segfaul is still there ?

>
> I was recommended to try out this library, because we are looking for
> cross platform functions that can draw music notation in real-time
> (say, for use in applications like music editors) and this library
> could supposedly do it.

yes it does: it is cross-platform, we use it on Mac OS, Windows and  
linux (only QT based graphic rendering is actually supported on linux)  
and it's probably the only C/C++ library that provides graphic music  
score rendering.

> It would be great if it did, but at this point
> I unfortunately can't test this premise. Would this be possible and if
> so are there some docs available regarding GUIDOLib's internals?

see the doc folder, it contains doxyfiles and some papers, including  
the phd these from Kai Renz, the engine designer.

All the best,
--
Dominique