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