Hello all,

I've finally managed to put together a new release of JPGalleg, version 2.6. I've had some patches sitting on my HD collecting dust for some time, and this release brings them onto the main package. 2.6 brings some little bugfixes and improvements, more JFIF variants compatibility, plus PyJPGalleg, a Python wrapper for JPGalleg kindly donated by Grzegorz Adam Hankiewicz. Changelog follows:

• Added more JFIF variants compatibility

• Fixed 1-byte memory leak in the decoder

• Made compatible with Allegro 4.2.x

• Refactored source code to avoid linking decoder or encoder functions when one of these is not used by the user application

• Introduced a new jpgalleg_error_string() function to return the last error message in string form

• Small makefile fixes

</li>

I'm releasing 2.6 as a release candidate for the moment, so you are encouraged to test it and give feedback so I can finalize it. I'm particularly interested to know if the build system actually works in various environments, expecially Visual C++ (I don't have VC over here, so if you spot problems, please be constructive and provide a possible fix).

Here is the package: http://www.ecplusplus.com/jpgalleg-2.6-rc.tar.gz

Thanks for your support!

I wasn't expecting any updates, because it was already excellent:) Very nice work! And thanks...

I don't have MSVC so I tested it only with MinGW, everything went fine.

Hi,

I was guy who previously sorted out issues with JPGalleg under Cygwin and MSVC back in 2003. I have not yet had the time to test it under MSVC (I suspect that there may be some issues with building the MSVC build with Cygwin), but I've tried building the mingw32 version with Cygwin.

Firstly, both the dynamically linked, statically-linked and debug versions of libjpgal.a have the same name. This can cause a conflict if the user wishes to install all possible versions at once. To remedy this, I suggest that the debug libs have the last 'l' in libjpgal changed to a 'd', and that the statically-linked ibs should have '_s' added to the end.

Under Cygwin, the "make uninstall" target does not change the backslashes into forward slashes in the paths for the lib and include. Below is the output. Because of this quirk, these two files are not removed.

Also, I notice that /allegro/obj/<compilername>/<libname>/datjpeg.o does not seem to be deleted from the Allegro obj folder whenever a make-distclean is done (although if we're really being thorough, the grabber would have to be rebuilt without the JPGalleg plugin, but that might be a bit overkill).

And finally, some good news. Back when I was helping you out, I came accross a jpeg that wouldn't work. Now, it works fine.

AE.

cool to have someone here who makes not a game, but a helpfull library

Just tried it on MSVC - both under Win98 with DJGPP and Win2K with Cygwin. Unfortunately, it failed to build on both systems. Here's what happened.

I suspect the problem here is that lib is being passed command-lines that are too long. Allegro creates a program called runner.exe that sorts out the long command-lines. I think I may have sent you a patch back when you were working on version 2.2

This is caused by Cygwin installing it's own program called link that is in the path before MSVC's link. The Allegro makefile overcomes this problem by using the full path of link.exe . This was mentioned on the [AD] list around March 2005.

I also tried installing JPGalleg for DJGPP. If I don't set the UNIX environment variable, JPGalleg is set up. However, I can only build the grabber with the plugin if I call make install before make plugin.

However, if I set UNIX=1 under DJGPP, then I can build and install DJGPP JPGalleg, but if I try to build the plugin, I get the following message as part of the ouput...

(note that I did the above after I built JPGalleg and the plugin and then did make uninstall and make distclean without the UNIX variable being set, and then set UNIX=1 and make)

Also, with UNIX=1, make distclean prints out the following

I'm not sure what's going on with either of the above.

Anyway, let me know if you need help fixing this.

AE.

Thanks for the feedback!

I've applied some more fixes to the build system and I've put up a new release candidate here:

http://www.ecplusplus.com/jpgalleg-2.6-rc2.tar.gz

These are the supposed fixes:
- when building with DEBUG=1, the library name is now libjpgad.a (or .lib if building with MSVC). There is no need to introduce a _s variant for static linking: JPGalleg is always linked as static library, the STATICLINK=1 flag when building it is just needed to let it know if you're going to link it with a static version of Allegro itself...
- make uninstall under Cygwin should now remove all files successfully.
- added the Runner workaround for when building with MSVC
- MSVC makefile always use full pathes to its tools to avoid tool name conflicts

Some issues remain unsolved for a reason:
- deleting datjpeg.o is not performed in distclean because it is already part of the uninstall process...
- the "plugin" makefile target should always be issued after you have successfully installed the library, no need to worry if it doesn't work the other way around.
- UNIX=1 and DJGPP were not meant to be mixed from the start... UNIX=1 is a way to tell the system you have Unix tools installed onto a Win32 system IMHO. DOS is out of games here.

Please test again and let me know!

OK, I got round to trying RC2 under Cygwin and MSVC 6 (with Cygwin) builds under Windows 2000 (haven't yet tried anything on W98 yet).

The Cygwin (mingw32) build works fine. The problem with backslashes in the filenames when removing the installed files has been fixed, so it can now safely be uninstalled.

However, the MSVC build under Cygwin still fails to build

As well as MSVC 6, has this been tested under either MSVC7 or MSVC8? I only have MSVC 6.

Also, I think that for the MSVC builds, you should use the runner program whenever you are calling an MSVC tool (ie. not just on the lib tool).

So if I have both the Allegro DLL-build and statically linked Allegro installed (sometimes, I build versions of my programs that require the DLL, and sometimes, I build statically-linked verrsions), would libjpgal be able to link with either DLL-allegro apps or static-allegro apps? If so, then what is the point of having STATICLINK=1 ?

AE.

Andrei: thanks for the feedback, here's a new (hopefully final this time) release candidate:

http://www.ecplusplus.com/jpgalleg-2.6-rc3.tar.gz

I've fixed the MSVC problem, and now runner is also used for all tools, not just link. About STATICLINK, I didn't realize (or was too lazy to) an user could have installed both the static and shared Allegro versions on the same development computer... Ok, now the lib name has a pending "_s" when building with STATICLINK=1 to identify the static version of the lib.

At last, I have given it a more thorough workout. While RC3 still failed to build under MSVC, I have managed to fix it myself so that it does (although the grabber plugin still doesn't). Attatched are some patches with various changes.

In the patch for the MSVC makefile, I have also fixed a long-standing issue with the debug-build under MSVC. When linking the debug lib to a program, the error-message "LINK : warning LNK4098: defaultlib "MSVCRT" conflicts with use of other libs; use /NODEFAULTLIB:library" appears. This is because makefile.vc links the wrong run-time library (which means that I get several DEBUG messages about memory-managment warnings and some crashes as well).

Incidentally, I notice that the other builds do not have the various debug options set - that is, the flags passed to the compiler are more or less identical in the release and debug builds.

The following are things I did not fix:

The object files for each build (libjpgal, libjpgad, libjpgal_s, libjpgad_s) should have their own subdirectories within the obj/<compiler>/ folder. The reason for this is that if I call make DEBUG=1 immediately after I call make, make considers the object files up to date, and includes the non-debug objects inside the debug lib. The same happens with the static-link and non-static-link versions of the lib.
In the meantime, a workaround can be used. Just remember to call make clean with the same options you pased to make inbetween making the various builds of jpgalleg.

When attempting to build the plugin using MSVC, I get the following message

This I suspect is a bug in allegro and not jpgalleg (the way MSVC handles grabber-plugins). I will shortly post my findings to the [AD] list. [EDIT: I've posted it to the [AD] list. See http://sourceforge.net/mailarchive/forum.php?thread_id=10504056&forum_id=34598 ]

When DEBUG=1 is set, the grabber plugin uses the release lib instead of the debug lib (although I somehow suspect that this behavour might be deliberate, unless the plugin itself is being debugged).

When building the MSVC version under DJGPP, the following command produces the following output:

You may have to use the runner for that one.

The optimisation settings for MSVC coud still do with a bit of tweaking, but at least it works now.

When copying files to the allegro grabber plugins directory, you may want to use the allegro-makefile's PLUGIN_SCR variable to determine which of the jpgalleg.sc* files to copy.

In the documentation, you should mention that when setting the ALLEGRO variable (this might only affect a any DOS-based environment such as DJGPP, but have not tested it with Cygwin), the filenames should not contain spaces (use things like "g:\progra~1\micros~3\vc98\allegro" instead of "G:\Program Files\Micorsoft Visual Studio\VC98\Allegro").

Also, I still have a small number of JPEGs that either load incorrectly or don't load at all in JPGalleg (but load fine elsewhere). Do you want me to send them to you?

And finally, some good news: The problem with the screwed up jpeg I reported in 2003 (with ex1.exe when built under MSVC in Windows 98) has gone.

Here is a list of changes by patch (including a few minor changes I've not mentioned above)

makefile.all:
+ $(RUNNER) is a dependency of more rules.
+ The message telling you to run 'make install' now reminds you that is should be called with the same paramaters passed to 'make' (which is the same combination of 'STATICLINK=1' and 'DEBUG=1')

makefile.vc:
+ Fixed the flags for debug build so it uses the correct runtime library. I've also added a debug-switch to the debug-build, and removed the optimisation settings from the debug build.
+ if UNIX=1, uninstall works properly

makefile.mgw
+ tidied up code for uninstalling plugin

makefile.mgw makefile.vc:
+ if UNIX=1, the plugin is uninstalled using REMOVE_PLUGIN_UNIX

makefile.mgw makefile.vc makefile.all:
+ Fixed typo: environmental -> environment

datjpeg.c
+ made a small change to remove a warning message when compiling in MSVC.

internal.h
+ The TRACE macro only uses _FUNCTION_ if _FUNCTION_ is defined. In MSVC 6, it is not defined.

AE.