Nevermind. Ctrl ^C works from the console after you switch back to it.

Edit
The links to the snapshots on the strangesoft download page are coming up with 404 Not Found errors. I'll try again later.

Edit2
All better now, downloading 4.3.11r11485 to test tomorrow.

Edit3
The downloads for both the .7z and .zip archives of 4.3.11r11485 keep failing midway through without any error messages. SeaMonkey seems to be keeping a cache of what it downloaded of it, so when I go to download it again it starts back up where it left off, but somethings funny.

All the versions of Allegro 4.3.11 Rev. 11485 compiled fine again, with one warning from the profiling static version (only) :

c:\mingw\allegro-4.3.11plusSVN_11485>mingw32-make STATICLINK=1 all
.....
tests/test.c:4637: warning: zero-length printf format string

All 4 versions of AGL compiled fine again, as well as Logg.

Still some trouble with JpgAlleg though :
In jpgalleg's makefile.all file, there is a line (149-151) that tests for DEBUGMODE being defined, in which case it defines DEBUG=1, but that is after several tests that check for DEBUG being defined, and after the $(MAKEFILE_INC) file is included (which also relies on DEBUG being defined), so it would miss both of them.

I'm also having problems building the non-static versions of the jpgalleg addon. I attached a text file of the build log (I'm using the DEBUG=1 option until DEBUGMODE is sorted out).

Errors (from allegro/addons/jpgalleg/ dir) :

//
gcc -s  -L../../lib/mingw32 obj/mingw32/ex1.o -o examples/ex1.exe lib/mingw32/libjpgad.a -lalleg
Info: resolving _screen by linking to __imp__screen (auto-import)
Info: resolving _allegro_error by linking to __imp__allegro_error (auto-import)
fu000001.o:(.idata$2+0xc): undefined reference to `lib_mingw32_liballeg_a_iname'
fu000002.o:(.idata$2+0xc): undefined reference to `lib_mingw32_liballeg_a_iname'
fu000004.o:(.idata$2+0xc): undefined reference to `lib_mingw32_liballeg_a_iname'
nmth000000.o:(.idata$4+0x0): undefined reference to `_nm__screen'
nmth000003.o:(.idata$4+0x0): undefined reference to `_nm__allegro_error'
mingw32-make: *** [examples/ex1.exe] Error 1
//

Also, the -g flag is not being passed to the command line during compilation, and it is not added in any of the makefile references to CFLAGS, so none of jpgalleg actually has debugging symbols anyway.

It also looks like the debug version uses -fomit-frame-pointer, doesn't that ruin the stack for debugging purposes?

LoadPng compiled fine, except for the deprecated function warnings for browse.c again. I made a unified diff of the minimum amount of changes necessary to preserve exact functionality and to remove the deprecated function calls. If you use it, you might want to run dtou on it, as it has CRLF line endings. I didn't know which kind of line endings you might want for a diff file.

So should dynamic library builds always link against other dynamic libraries then? Because to build the dynamic libvorbis libraries I had to hack the build process so that they were linked against the static libogg libraries. I take it this was not correct then? Conversely, if I forced them to link to the dynamic libogg libraries to build the static libvorbis libraries, that would be incorrect also? Perhaps my 'fix' isn't really a sound fix then.

Re: Newest strangesoft snapshot of 4.3.11-r11520 - The .7z file is only 1.0MB, and can't be opened by 7-zip as an archive. The zip file worked fine for me though.

Testing revision 11520 :
Allegro and AllegroGL both compiled fine for all available targets. Logg and LoadPNG built fine as well.

The dynamic versions of JpgAlleg still won't build though. (The makefiles look much cleaner with your latest update BTW).

I'm not sure I know what you're getting at here. So why not link the dynamic JPGAlleg library to dynamic Allegro then? <Doing some research...> Okay, I think I get it. The 'ar' utility doesn't actually create an export library, does it. So wouldn't 'dllwrap' or 'dlltool' be more appropriate to use then?

I guess my main concern is that not all of the addon's build systems mesh perfectly with Allegro's. That is, I think that they should all support the same 6 build options that Allegro does -

make [ "" (Optimized) | DEBUGMODE=1  | PROFILEMODE=1 ] [ "" (Dynamic) | STATICLINK=1 ]

with

make all [ "" (Dynamic) | STATICLINK=1 ]

building all 3 versions of the dynamic or static library, and having the WITH_* defines pass those same options to the individual add on packages.

- even if it is only to say that
"The build of the $(BUILD_TYPE_STRING) $(LIB_NAME_STRING) library is not supported at this time."

That's fine with me. I never said I wanted to cross breed static and dynamic builds.

But the dynamic build of JpgAlleg isn't working though. The examples don't build in the dynamic version due to undefined references. Here's my latest build log of the four different versions of JpgAlleg (static/dynamic , debugging/optimized) for Revision 11520 :

So the static optimized version, and the static debug version both build fine along with the examples, but then the dynamic optimized and the dynamic debug versions fail to compile the example programs.

All four versions of the library call the 'ar' utility in the same way (pseudocode) :

ar rs LIB_NAME $(OBJ_LIST)

I don't have any dll's in the jpgalleg\lib\mingw32 folder, and I don't think the 'ar' utility creates an export library, so you're really confusing me here.

Edit
I see what's going wrong now. The object files for the example programs are only built for the very first version of the JpgAlleg library that you create. Each time after that, it just links the ex#.o files into the ex#.exe executables without recompiling them first. I had to really scrutinize it to see that. Also, the object files are not being put into the proper folder for their library versions :

//
gcc -c -s -I./include -I../../include -march=pentium -O0 -g2 -Wall -W  -DALLEGRO_STATICLINK -DDEBUG -DDEBUGMODE examples/ex1.c -o obj/mingw32/ex1.o
gcc -s  -L../../lib/mingw32 obj/mingw32/ex1.o -o examples/ex1.exe lib/mingw32/libjpgad_s.a -lalld_s -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lole32 -ldinput -lddraw -ldxguid -lwinmm -ldsound
//

See how the statically linked version of the ex1 object file gets placed into the obj/mingw32 folder instead of the obj/mingw32/jpgalls folder?

That still doesn't solve the missing dynamic libraries though.

You found the necessary changes much faster than I did. I had only gotten through $(EXAMPLE_OBJECTS) and $(EXAMPLES) by the time you had it fixed in SVN.

OT : Now that I've gotten a local working copy of 4.3.11 from SVN, it's so much nicer to just use TortoiseSVN to 'Update' than download it all each time.

Okay, so does that mean that when I want to link my program to allegro dynamically that I link against libjpgad.a and libjpgal.a, and when I want to link my program to allegro statically that I link to libjpgad_s.a and libjpgal_s.a? (Only linking to the appropriate debugging or optimized one of course)

Me too! I'm slow.

I could do it today or tomorrow if I have time between shopping, skype, work and Allegro 5.

You have to admit though, that it sounds a little strange to have a "dynamic" version of a library that is actually static. Whatever though, I'll get used to it.

Okay, so, all 4 versions of JpgAlleg and the examples build fine for me now. Thank you, Milan.

A while back, I made a thread about adding a mouse_on_screen() function to Allegro here :
Simple Mouse API feature request

I was wondering if it would be alright to have this function added to Allegro. All it does is return a copy of allegro's _mouse_on variable that indicates whether the mouse is on the screen or not, but it's very useful to prevent having two mouse pointers on the screen at the same time when running in windowed mode and you're drawing the mouse pointer yourself. It would also allow other effects such as pausing the game when the mouse goes off the window, and only scrolling when near the edge of the window, but not while off of the window, etc...

Thanks again,
Edgar

No, I don't mind making a patch. Does SVN sort out DOS and UNIX line endings automatically?

Do I need to change the .def file? I think that will be taken care of when 'misc/fixdll.sh' is run before the distribution is put together, but I'm not certain.

What format is the documentation supposed to be in? Give me a little while to figure out the _tx stuff, and I'll get back to you.
(Ah, I found 'allegro/docs/src/makedoc/format.txt'. Reading it now.)

Edit

Right Click on local working copy of allegro folder -> TortoiseSVN -> Create Patch. That's handy. The Tortoise UDiff viewer even makes it look nice too.

The diff it made is a little odd though - there were two lines in allegro._tx that had degree symbols changed to an Angstrom and degree symbol. Must be some encoding problem. Since my default save encoding in Code Blocks is UTF-8, I think I changed allegro._tx from Windows-1252 into UTF-8, and so the degree symbol changed. Hold on, let me try again.

Alright, I resaved the files as Windows 1252, and now the patch looks right :
mouse_on_screen patch for
docs\src\allegro._tx
src\mouse.c
include\allegro\mouse.h

Please take a look and see if there's anything that I missed in there.

Milan, the OS X build worked fine. I did not remove any config files or do anything out of the ordinary - just the fix.sh, make, install and the lib and addons all compiled and ran without a hitch. Nice!

iMac intel, 10.5.6

Paul

[AD] would be the the best place to post such things

I would have released it months ago but it's not up to me in the end. Just wanted to nail down this few known issues to make the 4.4 release the most stable ever. If it ever comes out that is. We're all too excited about A5.

It would be also fair to mention it in this thread: DOS is broken in 4.3.10plus and likely will stay so.

Since the vote is started, I also vote for a 4.4 public release.