Hello again,
I have discovered quite disturbing things, when I have played with Allegro build setup.
1. The distributed include files somehow contain platform-dependent stuff. I have read somwhere that the library interface should be platform independent and it sounds as a very smart thing...
2. The allegro library has different names across platforms (for instance alleg42 on w32 and (lib)alleg on Linux). What about making it the same? Symlinks on Linux may ensure the backward compatibility
3. I really suggest renaming ASM files with CPP code from foo.s to foo.S or something like that (gcc needs this to autodetect the right file type)
4. Allegro 4.2 C and ASM versions are not compatible at that moment, what about fixing it?

I can do the work, I would just like to know whether it is OK for you or not...

I would also like an advice from those who understand X11: The autotools-compiled allegro library works, but the resolution of the fullscreen mode is always set to the desktop resolution and although the screen bitmap has the right size, it is not stretched to the physical screen.
What can be the cause of that?

Cheers, Matej

Not quite sure what you mean here. Could you be more specific and provide an example? The library interface is platform independent, and that ability comes from platform dependent headers that get included during the build process. At least that's how I see it.

I didn't know there was any C++ code in Allegro. Which files have it?

Not sure what you mean. Can you explain?

I don't see what advantage there would be to making the Unix library names conform to DOS 8.3 limitations.

AFAIK, .S is for assembly files, so that wouldn't help at all.

No. It would probably mean breaking ABI compatibility with existing 4.2.x versions, which is not allowed. Besides, as we keep saying, asm is dropped from 4.3 onwards.

I assume you mean that bug that some of the config results leak into allegro.h? I thought that was fixed some time ago, but maybe it wasn't.

For A5, the static library names are now like:

liballegro-static-4.9.6.a

Makes sense according to man gcc - however, are any such files still used in 4.3.10? If not, we might as well remove them instead of rename.

Hard to fix, as I believe some parts of the code (I think "bank switchers", whatever that is) are only written in C or ASM or something like that. And again, we mostly dropped asm support as far as I understand.

We use the (by now half deprecated - so you may have to install it first on your system) XVidMode extension to set fullscreen modes. If you compile Allegro without that extension, you cannot get fullscreen modes (instead the window is centered and the rest of the desktop is blacked out).

Thank you all for your replies,

OK, that sounds reasonable. Both Unix and Windows packages distribute all headers though, so I will investigate which ones are disposable.

I don't know what are those DOS limitations, but the reasons for that are following ones:
1. Why not? The 4.2.x library can be named alleg42 on Windows and liballeg42.so.something on unix. Every time you would pass -lalleg42 to link with it...
2. It makes it easy for people to check for it and to cross compile, especially when they use autotools :-)

One question I forgot to ask: Linux version produces also some alleg_unsharable library, what's that?

And why to give different names to static and shared libraries? Why not just liballegro49.a?
Have you took a look on how libtool does this thing? I think it is quite smart..

It really works. However, are you really so sure that there won't be any further 4.2 release? With some bugs fixed and proper autotools support:D?
Anyway, I suggest deleting ASM files from other branches since they are just making things look more complicated...

I am surprised that the fact that functions are implemented in a different way implies that the libraries are not compatible. Interesting, but I don't doubt that.

Thanks, it helped me to correct a bug in the build setup and now it seems to work;), thank you.

Thank you for your replies,

Do you mean that I should use allegro-config and AM_PATH_ALLEGRO? I really don't like those tools and I think that thanks to the fact that Allegro is monolithic library, those tools are an overkill. I wanted to add pkg-config support, but that tool does not support cross compilation out of the box right now and also doesn't integrate well with autotools and it is not going to change in the near future

This should be OK since they have different suffixes. Let the compiler choose(you can pass the -static flag)... Is something wrong with that?

I am really surprised about that, I have never heard of such thing . Is it still neccessarry? I have built the library into just one file and it seems to work fine...

Yes.

As pointed out, no, they're not. Do you prefer to enter the output of allegro-config --libs manually? Also, you may not like allegro-config for some reason, but lots of other people do.
Personally, I hate the fact that there's no equivalent for it on Windows.

Hmm... yes, you're right, they do. Maybe it is indeed overkill.

Usually not I think, but I really haven't looked at this recently. Most libraries you're likely to use probably do not try to hijack your main() function either.
I think there was some other code that had to go in there, but I don't remember the details.

Yes. That makes your binary completely statically linked, instead of just Allegro.

Pretty sure it was because some (all?) hand written asm functions were not relocatable. This wouldn't be a problem in 4.3+.

The AM_PATH_ALLEGRO macro is not trivial as well as the allegro-config script and they are probably a pain to maintain.
I have found out that if you use autotools, you can just add alleg to your LIBS (inside the configure script) and if a libtool Allegro library is installed, it is going to be OK (AM_PATH_ALLEGRO macro is not needed then)
And for people who use IDEs or who don't like libtool, I will provide pkg-config support. (pkg-config allegro --libs instead of allegro-config --libs)
Now I think that this is really smary and it even complies to standards

What is the consequence of this? I have compiled Allegro 4.2 with ASM to one shared library and stuff seem to work fine. Are there any risks assotiated?

It was the calling conventions (as pointed out, in the bank switching funcs) in the asm that were different from the C version. The asm version was in the official 4.2 ABI, so if you made a C only version it made an incompatible DLL.

In 4.3, the ABI uses the C calling convention. The asm has been stripped out for simplicity, but if it goes back in it will have to be wrapped in cdecl stack parameter passing. There is not currently any appetite for this, as the asm would only compile where gcc is available (not from within a VC project. All our attempts to invoke gas as an external tool failed with every version of VC) and would need to be maintained.

I do somewhat regret losing all the asm code. compilers are getting better but it's a fact that many people find the asm faster, especially on older machines where it matters most. I do agree however, with stripping it all out first, as all the build tools treat x86 as the default choice, due to Allegro's DOS only origins. When/if asm is grafted back in, it should be triggered by non-default macros. I'm talking specifically about replacing ALLEGRO_USE_C and ALLEGRO_NO_ASM with an ALLEGRO_USE_686_ASM etc. when required.

Too bad it's license is incompatible with that of allegro

Traditionally we only accepted code which could be licensed under 'giftware' in Allegro, although we have relaxed that for the addons in 4.3.

So I see that the disclamer is +- the same
I consider that BSD license as some protection of the user than some sort of a restriction, maybe it wouldn't be bad to include the rest into the giftware license as well.
However, distributing it as an addon should be OK. Some --with-liboil configure switch combined with some notification should do it. I think that ricers can start their work!