Re: [AD] MacOS X dynamic linking and enduser package

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


> There are many ways to link Allegro to a program:
>
> [...]
>
> Now that's messy, isn't it? But that's due to the OSX way of handling
> dynamic libs... Allegro just supports all linking options.

Ouch!  I thought MacOS X was supposed to be user-friendly.  On second 
thoughts, this has probably nothing to do with developer-friendliness :-)

> Now it would be nice if allegro-config could work also when Allegro is
> installed as a framework, system wide or embedded. This would require
> modifications to allegro-config.in though, as under OSX allegro-config
> is generated on the fly from it, by using sed to change parameters. Any
> idea on how to deal with this? It'd be nice if allegro-config could
> support an additional --framework parameter, outputing "-framework
> Cocoa -framework Allegro"...

Why not simply fork allegro-config.in, like QNX?

> An important issue to discuss here is what allegro-config should report
> when called. Currently it outputs (among other linked libs)
> -lalleg-$(shared_version).dylib. Wouldn't be wiser for it to output
> just -lalleg.dylib or -lalleg-4.1.dylib? These would be links to the
> currently installed WIP... This way linked app will only search for
> liballeg.dylib or liballeg-4.1.dylib, so if an enduser has another WIP
> installed, it'll still work as he'll have links pointing to it
> (providing it's ABI compatible)

This is already the case under Unix because the soname is specified at link 
time via the -h option:

[eric@xxxxxxxxxx allegro]$ allegro-config --libs
-L/usr/local/lib -L/usr/X11R6/lib -Wl,-export-dynamic -lalleg-4.1.14 
-lalleg_unsharable

$(CC) -shared -o $@ $(LIBALLEG_SHARED_OBJECTS) -s $(LDFLAGS) 
-Wl,-h,liballeg.so.$(shared_major_minor) $(LIBS)

[eric@xxxxxxxxxx allegro]$ ldd demo/demo
        liballeg.so.4.1 => /usr/local/lib/liballeg.so.4.1 (0x40022000)

> I'm also really considering to add symbolic links creation of
> liballeg.dylib, liballeg-4.dylib and liballeg-4.1.dylib, all pointing
> to the installed version, to the OSX enduser package, as currently the
> only link it creates is for the WIP version itself into /usr/local/lib
> (so it assumes the enduser to install the same WIP the coder used).

That's what is done on Unix:

[eric@xxxxxxxxxx allegro]$ ls -al /usr/local/lib/liballeg.so.4.1
lrwxrwxrwx    1 root     root           18 Mar  3 22:32 
/usr/local/lib/liballeg.so.4.1 -> liballeg-4.1.14.so

-- 
Eric Botcazou




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/