Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Allegro 4 is not dead

This thread is locked; no one can reply to it. rss feed Print
 1   2 
Allegro 4 is not dead
Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Peter, how can I help? If I clone your repo and checkout your 64 bit branch, is it ready to build and test with MinGW? I can try it with a x86_64 GCC 8.1 compiler.

Peter Hull
Member #1,136
March 2001

Yes, it should work. There will be warnings I expect but nothing of real concern (at least on MSVC it uses warn level W3 which is very picky). Then as I said I will try and sort it out into more coherent commits.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

I'm having trouble building a 64 bit ogg and vorbis for 64 bit allegro. I can't figure out how to verify that they are actually 64 bit libraries. MSYS' file command doesn't help. Windows Explorer properties doesn't help. My Ubuntu 20.04 in a VM won't let me access the shared drive so I can't test from there either.

Maybe I will see if your allegro builds without the addons first. I'll try that and report back.

UPDATE
64bit allegro builds fine (*cough* with about 1000 warnings) with jpgalleg and allegrogl. The examples seem to work fine. I didn't test the grabber. And those warnings look pretty scary, but I don't think any of them had anything to do with your code. I get those when building 32 bit allegro 4 as well.

Any clues how to make sure my libraries are 64 bit? I don't have a way to verify that atm. file doesn't help. explorer doesn't help. Dependency walker crashes and doesn't work in Windows 10. I'm all out of ideas.

I counted 32 commits in your repo from the time of the 4.4 branch. Does that sound about right?

Peter Hull
Member #1,136
March 2001

I counted 32 commits in your repo from the time of the 4.4 branch. Does that sound about right?

Not that many

> git log --pretty=oneline upstream/4.4...origin/64-bit-allegro4-ph
8400ebc8b8a7f635cafe2f7679c5d36f7e9f1aba (origin/64-bit-allegro4-ph) Fix some types to match Win API
5f13fd2297968c2477e90dbfa66261e386623de1 Fix some casts from pointer to long
0dc3c1e12a52bb1b8bc5d43d20cb56e3eb7b316b Add Visual Studio's CMake support dirs
6a156e75278b645de6fa3fc8e3102729ed049478 Make conditional on SHARED build
f1c485dd0936ce829aa4f87db022f65cff76aa60 Also allow DLL building with MSVC
b2ab27c62857940b9f73e426c14bd71033b5f848 For MSVC, ensure DLL symbols are exported/imported
7172efad62cde97078b8ff9d6e6391b1ae26ff4f Fix a couple more warnings
bdf1f0b495dd4f90435e8369dc7ad7f6aadbde23 Visual Studio - fix some compiler warnings
706fafec9750d176ff88b03aa11cc0c69d5bc8f1 Fix misc warnings
689f3fb4bd4667234f9b7ca3f704ad6045329af9 Use stdint types where possible
fc8cb8e0846a397fcd1990a5aa92fa3a18e722f8 Marek Ratajczak's 64-bit patch

Quote:

64bit allegro builds fine (*cough* with about 1000 warnings) with jpgalleg and allegrogl.

AFAICS the remaining ones are all spurious/unhelpful, e.g. expressions of the form s + (i + 1) * sizeof(T) where s is 64-bit and i is an int complain about doing 32-bit arithmetic and then casting to a larger type (even when we know i is never going to be big enough to overflow). The fix seems to be s + ((int64_t) i + (int64_t) 1) * sizeof(T), anything else won't satisfy it. And that seemed to be a bit over-the-top to me!

[edit]
dumpbin is the thing Windows uses to tell you if a library is 32 or 64 bit. I don't know if mingw has a version of it?

[edit2] I've merged together some commits to make it easier to see what's going on. If you've got time can you check if it's still working ok? If so, then that's done as far as I am concerned.
https://github.com/pedro-w/allegro5/tree/64-bit-allegro4-ph

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

I tested your patch and everything builds okay, sans the addons until I get the deps built.

EDIT
Here's the full build log including allegrogl (which has the most warnings of all) :

buildlog.txt

 1   2 


Go to: