Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Allegro 5 DLL compatibility etc.

This thread is locked; no one can reply to it. rss feed Print
Allegro 5 DLL compatibility etc.
torhu
Member #2,727
September 2002
avatar

Continued from here.

IIRC, the .lib files for dlls only contain a list of symbols, no thunks. Those symbols are then resolved at startup of the executable (unless you enable delay-loading, that is).

Loads of info here:
http://www.securityfocus.com/infocus/1872
http://www.securityfocus.com/infocus/1873

Matthew Leverton
Supreme Loser
January 1999
avatar

For what it's worth, static linking works fine. That's what I tend to do for releases anyway. I've gotten all of the third party libraries I need for SH compiled as static.

The only one that looks problematic so far is sndfile. But thankfully the native wav loading has been sufficient. (Jakub and I had problems during SH, but it seems to work now.) Hopefully, we can refrain from utilizing such libraries that have little to no Windows / MSVC support.

Peter Wang
Member #23
April 2000

We could either remove the sndfile support or split it out of multiple addons. Or we might split acodec up completely.

Thomas Fjellstrom
Member #476
June 2000
avatar

Or we might split acodec up completely.

Might be the simplest route to take at this point. It will make people who complain that there's too many libs, complain more though :o

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Kibiz0r
Member #6,203
September 2005
avatar

Picking up on a thread from the mailing list...

I am all for any solution that involves getting rid of the def files. The point of using CMake is to be platform-agnostic, but the scripts to generate the def files require gcc and sed. It introduces dependencies that prevent Allegro from being built from just one toolchain.

In my personal experience, I've had a hard time automating my builds because of this.

It will make people who complain that there's too many libs, complain more though

That's because there are too many libs.
rabble rabble rabble

Elias
Member #358
May 2000

Once we got rid of the .def files, we could add a cmake-option ONE_DLL which puts allegro and all addons into a single dll. Then nobody could complain about too many libs any longer, and since ABI compatibility would be per-symbol instead of with weird index files it wouldn't matter that there's now a multi-dll as well as a possible single-dll distribution.

--
"Either help out or stop whining" - Evert

Thomas Fjellstrom
Member #476
June 2000
avatar

The problem with one big dll gets into dependency issues. And sooner or later people will start using other peoples unofficial DLLs thinking they are the same thing, but will either not have some of the needed functionality (iio, acodec, whatever) or will have some when they dont need it..

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Matthew Leverton
Supreme Loser
January 1999
avatar

That problem already exists with any add-on that has multiple, optional dependencies (e.g., acodec).

Thomas Fjellstrom
Member #476
June 2000
avatar

Not if you don't need it it doesn't. But if you're using some all in one allegro dll, it'll be there regardless if you use any acodec functions. A somewhat worse problem than you currently have with acodec. Which I assume will be fixed by splitting it up into separate libs as is done in allegro 4 currently (alpng, alogg, alfoo, albar, aletc...).

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Kitty Cat
Member #2,815
October 2002
avatar

Elias said:

Once we got rid of the .def files, we could add a cmake-option ONE_DLL which puts allegro and all addons into a single dll.

That will make it incompatible with the separated DLLs. Unlike .so's, the DLL a symbol comes from is determined at link time. If a person links an app using the single DLL, that app won't work with the separated DLLs because the symbols that are in the extra DLLs won't be found in the main DLL, even if the extra DLLs are loaded.

It also makes the fun that if one part of an app uses the single DLL, and a plugin for the app uses the separated DLLs, any Allegro objects or state from one part of the app will not be recognized by the other. MS's C-runtime hits this problem a lot because it seems to get a new DLL name every few years. Resources from one C runtime (eg. an open file descriptor) won't be recognized in the other C runtime.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Kibiz0r
Member #6,203
September 2005
avatar

This has probably been beaten to death, but what is the design rationale for A5 having multiple DLLs?

torhu
Member #2,727
September 2002
avatar

Kitty Cat said:

That will make it incompatible with the separated DLLs. Unlike .so's, the DLL a symbol comes from is determined at link time. If a person links an app using the single DLL, that app won't work with the separated DLLs because the symbols that are in the extra DLLs won't be found in the main DLL, even if the extra DLLs are loaded.

You can have the main DLL forward symbols it doesn't define itself, but that might be complicating things too much. And it requires a custom .def file, or linker options. But it does have the advantage that the forwarded symbols are not looked up if never used, so the additional DLLs don't need to be present at all.

Of course, the other problem you mentioned would still be there.

If there was an all-in-one option in addition to the current way, the 'core' dll and the all-in-one dll could have different names. As for making 3rd-party dll dependencies optional, enabling delay-loading is a cheap option.

I'm really just making some suggestions here, I don't really have an opinion yet. ;)

Peter Wang
Member #23
April 2000

The all-in-one DLL sounds like too much trouble.

I'm almost decided on splitting up acodec. Most programs are not going to be using FLACs, and even fewer require sndfile.

For consistency, we should split up iio as well... not particularly keen on that.

Evert
Member #794
November 2000
avatar

For consistency, we should split up iio as well... not particularly keen on that.

As long as I can load PNG files without extra effort, I have no objections to someone else doing the work. ;)

Matthew Leverton
Supreme Loser
January 1999
avatar

Why are all of the add-ons built as shared DLLs in the first place? Say you split up acodec and iio, and you end up with a5-sndlib.lib, a5-png.lib, a5-jpeg.lib, etc... Why would anybody ever want those to be DLLs? They'd only ever have one or two functions, none of which would probably ever change.

Thomas Fjellstrom
Member #476
June 2000
avatar

Mixing static and shared libs doesn't tend to work that well in MSVC no?

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Matthew Leverton
Supreme Loser
January 1999
avatar

I've never used aldmb.lib or loadpng.lib as shared DLLs with Allegro 4, even when using Allegro 4 as a shared DLL. I'd never want aldmb.dll or loadpng.dll; that's just silly.

Now, you do need two different versions of each of those libs depending on if Allegro is static. So you'd still need a5-png.lib and a5-png-static.lib. But a5-png.lib need not create a DLL.

And you cannot mix /MT and /MD, but that's independent of being a static library or not.

Thomas Fjellstrom
Member #476
June 2000
avatar

but that's independent of being a static library or not.

I just assumed it wasn't independent. Makes a lot of sense that it isn't though.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Matthew Leverton
Supreme Loser
January 1999
avatar

Note that I edited my post to be more clear... you'd still need two versions of each add-on library, but the "shared" version wouldn't need to create a DLL.

Peter Wang
Member #23
April 2000

It's a worthwhile idea, at least for Windows. I don't think anyone on Linux cares about more shared libraries. How do you decide which addons need to be DLLs? kcm_audio and primitives are pretty substantial, I think.

[I think this topic should be moved to the development section.]

Matthew Leverton
Supreme Loser
January 1999
avatar

How do you decide which addons need to be DLLs?

A judgment call... The only legitimate reason somebody would want to use a DLL instead of a static library for a released game is because he thinks that the library will be updated more often than his game. As such, users can download updated DLLs.

So, it should depend on how likely the library is to be updated. I think the two you listed are good examples of substantial add-ons. Also, neither of them introduce additional dependencies on Windows, as opposed to something like a5-png.dll + libpng.dll.

I don't know if cmake supports it, but ideally one could set a default option (e.g., per-default, all static, all shared) and then set each add-on's mode individually.

cmake .. -G "Visual Studio 9 2008" -DSHARED=default/on/off -DWANT_ACODEC=shared/static

Go to: