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

[Shawn Hargreaves <shawn@xxxxxxxxxx>]

George Foot <george.foot@xxxxxxxxxx> writes:
> > 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.
> 
> I don't think you meant `liballd.a' though -- if you're working entirely 
> with shared libraries, there shouldn't be a liballd.a at all.

True. What happens is that the linker is being told -Llib/unix -lalld, but 
the test program only depends on $(LIBALLEG), which is set to 
lib/unix/liballd.so, so it never bothered to build liballd_nonshared.a along 
with it.

> Maybe all we need to do is mark its dependencies properly, so that it 
> actually does force the static library to be compiled. The change is 
> simple, patch attached -- it seems to work.

That seems to fix it, although I think it would be just as easy to simply 
change the definition for $(LIBALLEG), which only ever seems to be used in 
the dependencies for each executable.

> I have two suggestions -- two different directions we can go in, apart 
> from using the old linker script system (which is less portable). Either 
> (a) `allegro-lib' just outputs the dependency linking directives, and 
> people have to write "-lalleg `allegro-lib`". 

I can see why this is an appealing idea, but I tend to agree with Peter's 
comment that we should do this the same as how gtk etc. arrange it, which is 
more of a (b), except with different name and switches for the script.

> Or (b) `allegro-lib' takes care of everything.
> 
> (b) is what you were talking about, and it works fine but gets
> awkward when both shared and static libraries are installed.  If
> we go with this system, I think in that case allegro-lib should
> default to linking shared, and have a `static' option which
> should be specified if `-static' is on the linker command line.

I agree. We can make the script stick pretty close to the way others do it, 
but will need a couple of extra options: --static to enable static libs when 
the shared versions are also installed, and --release, --debug and --profile 
to select library versions (gtk doesn't seem to have such options, so I 
think we should just default to the release version unless told otherwise, 
or unless only debug libs are installed).

This does considerably increase the complexity of generating the script, but 
I'm happy to do that part of it if you can sort out the rest of how Allegro 
itself is built. And it would allow us to get rid of all linker scripts, 
which will make the whole thing more portable. Am I right in thinking that 
we basically have three library files? .a for static libs, .so for shared, 
and another .a for the static parts of the shared libs? That doesn't seem 
_too_ painful. And as long as we avoid using the same basename for the .a 
and .so versions, it should be easy enough to make the wrapper script select 
which versions it wants to include...

> Facing another day in the office, this time without any chance of being 
> paid -- already been paid for this, six months ago... Is it a general fact 
> that when you've already been paid for something you totally lose interest 
> in it? :)

I think it is more to do with the sort of things that people want to pay you 
for not being all that interesting in the first place. This is Access 
database stuff, isn't it? You poor man :-)

> I forgot to do this too before posting the last email -- here's a patch 
> for it, which also adds %preun scripts to make the RPMs remove more 
> cleanly. 

Thanks.

> This does not work for the end-user one though because we don't have a 
> build tree to run `make uninstall' in any more. I considered doing `make 
> --dry-run uninstall' while the tree's still there and saving the resulting 
> script as /usr/local/src/allegro-uninstall.sh or something, and calling 
> that from the %preun script of the RPM, but I haven't implemented it.

That's not a bad idea. I did something similar for the MSVC binary 
distribution (it runs make -n to find out how to build the support progs, 
and then converts the output into a batch file), and it struck me as being 
both effective and very satisfying :-)

I do feel a bit guilty about how we are abusing the RPM system here: this 
certainly isn't how it was intended to work! But hey, as long as it does 
actually work, that's the important bit.

> Hmm, come to think of it, I don't remember whether I included this other 
> patch either.

You didn't before, but you did now :-)


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