Re: [AD] Compiling errors with Allegro 3.9.29 shared/debug version.

[Shawn Hargreaves <shawn@xxxxxxxxxx>]

Grzegorz Adam Hankiewicz <gradha@xxxxxxxxxx> writes:
> Tested the tar.gz version. Nice :)

I'm cc'ing these problems to the developers list, since I don't know about 
either shared libs 

> However, compiling with
> 
> # ./configure  --enable-shared --enable-dbglib --enable-dbgprog --enable-shareprog
> 
> gave:
> 
> gcc -O3 -ffast-math -fomit-frame-pointer -Wall -L/usr/X11R6/lib  -o
> demo/demo obj/unix/demo.o -Llib/unix -lalld -lm -lXxf86dga -lXxf86vm
> -lXext -lX11 -lesd
> lib/unix/liballd.so.3: undefined reference to `SEQ_PGM_CHANGE'
> make: *** [demo/demo] Error 1

That looks like an OSS MIDI thing: any ideas, Peter?

> Tried the following but also didn't work:
> 
> # make tests/test
> gcc -DHAVE_CONFIG_H -Iinclude -Iinclude/allegro -I./include
> -I./include/allegro -I.  -I/usr/X11R6/include  -O2 -g -Wall -DDEBUGMODE -c
> ./tests/test.c -o obj/unix/test.o
> gcc -O3 -ffast-math -fomit-frame-pointer -Wall -L/usr/X11R6/lib  -o
> tests/test obj/unix/test.o -Llib/unix -lalld -lm -lXxf86dga
> -lXxf86vm -lXext -lX11 -lesd
> ld: warning: type and size of dynamic symbol `apply_matrix_f' are not
> defined
> ld: warning: type and size of dynamic symbol `draw_compiled_sprite' are
> not defined
> lib/unix/liballd.so.3: undefined reference to `SEQ_PGM_CHANGE'
> make: *** [tests/test] Error 1

I don't get this either: both those dynamic symbols come from imisc.s, but 
you can't be missing that completely or it would also be complaining about a 
missing _stub_bank_switch, _do_stretch, and _blender_trans24. I can only 
think that the missing symbol is confusing it here.

We do have a dependency problem to do with shared libs, though: if you 
enable share+debug programs, make clean, and then make tests/test, the 
dependencies create the .so files in lib/unix, but nothing has generated the 
liballd.a which the test program then tries to link with. George? Help! I 
don't understand how any of this stuff works: do I need to learn it, or do 
you have any idea what is going on here?

A few other observations about shared libs:

I installed the RPM version on my machine at work today, and then tried 
building SPEED, which didn't work using -lalleg, although it was ok when I 
changed that to use allegro-lib. I don't have a problem with that: in fact 
it might well be worth phasing out the linker script hackery altogether in 
favour of only using allegro-lib, but if so we can simplify the linker 
scripts a lot, and should remove -lalleg from the docs. If you do want to 
keep -lalleg working, though, there is a problem using it with shared libs 
at the moment, at least in the form that the RPM installs.

I'm still confused about what happens when you install both shared and 
static libs at the same time. If you only install one or the other, 
allegro-lib alone will select the version you installed, right? And if you 
install both, it uses the static ones unless you specify the shared option 
to allegro-lib? If that's how it works, it seems cool to me (although I need 
to update readme.uni to make this more clear), but it's still a mess when 
you try to link directly with the libs. I guess I'm thinking that it would 
be cleaner if we got rid of all that, and used allegro-lib exclusively.

Why is the linker commandline being passed -O3 -ffast-math 
-fomit-frame-pointer, while linking debug programs? Those aren't linker 
switches at all, let alone debug ones :-)

I think the default configure option should be only shared libs and 
programs, with static linking only enabled if you explicitly request it. 
Anyone got a problem with that? Saves a _lot_ of disk space :-) At the 
moment it looks like the RPM versions are installing both shared and static 
libs: is there any reason for that, or couldn't they also always be shared 
unless told otherwise?


--
Shawn Hargreaves - shawn@xxxxxxxxxx - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."