[Openal-devel] FreeALUT dynamicly loading ogg/vorbis

[Sherief N. Farouk]

> -----Original Message-----
> From: openal-devel-bounces at opensource.creative.com [mailto:openal-
> devel-bounces at opensource.creative.com] On Behalf Of Chris Robinson
> Sent: Tuesday, June 10, 2008 10:12 PM
> To: openal-devel at opensource.creative.com
> Subject: [Openal-devel] FreeALUT dynamicly loading ogg/vorbis
> 
> I've got FreeALUT working with Vorbis files properly, now. They can be
> loaded
> into a buffer, or streamed (in fact, anything that can be loaded into a
> buffer can be streamed). There's an ugly amount of code duplication,
> though,
> that I'm going to have to do something about (the existing APIs don't
> work
> well with streaming, and making them work with streaming doesn't work
> well
> with the existing code that uses it).
> 
> Right now, however, I'm tyring to get libogg/libvorbis to dynamicly
> load so
> they're not a load-time dependancy, and there's a problem I'm having
> with
> loading the functions. With copmpile warnings on, it adds -ansi -
> pedantic to
> the compiler command line. Subsequently using dlsym produces a bunch of
> these:
> warning: ISO C forbids assignment between function pointer and ‘void *’
> 
> But, even with proper casting (even if it was feasible to cast every
> function
> load individually), causes a bunch of these:
> warning: ISO C forbids conversion of object pointer to function pointer
> type
> 
> So as far as I can see, there's no way to load functions via dlsym
> since the
> it returns void*. Granted they are only warnings and compilation is
> successful, but they're unsightly and it kinda defeats the purpose of
> using
> the ansi/pedantic flags.
> 
> What would be the best way to handle this?

[Sherief N. Farouk] 
Well, according to the rationale section in this link: http://www.opengroup.org/onlinepubs/009695399/functions/dlsym.html , a void* to function* cast *IS* portable across POSIX systems, so I don't think you'll have a portability problem. Strict ANSI C compatibility though, I'm not sure. Maybe an early solution would've been to have a dlfn() that returns a "void (*) (void)", but I guess that's a bit too late ;).

- Sherief