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!

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.

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.

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.

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.