Anyone know where I can get a valid sys/resource.h & sys/times.h ?

On a Unix system of your choice.

--tml

On Monday 27 October 2008, steve@advance-software.com wrote:

Ok. I choose Cygwin, as it contains these files. Is this OK ?

I've copied the files from this crappy system into my MSYS/MINGW tree. This is the same tree I'm using for my mozilla build environment.

I've not built anything on windows, let alone set up a build environment there, but "just copy random files around because they are asked for" sounds like a bad idea in nearly all cases. Your errors seemt o indicate that at least some other header files are missing as well.

gcc -Wall -O3 -ffast-math -std=c99 -fPIC -Ilibopenjpeg -c libopenjpeg/j2k_lib.c

Next thing (it probably isn't the reason for your trouble here) are your compile flags. If you ever run into runtime trouble, probably nobody will help you with flags like -O3.

Just my 2¢, Daniel

Ok. I choose Cygwin, as it contains these files. Is this OK ?

Sure, if you want to build code for Cygwin, but that has then nothing to do with the "native" Win32.

My reply was perhaps a bit too terse, a failed attempt to be ironic.

I've copied the files from this crappy system into my MSYS/MINGW tree.

That is totally wrong and won't work at all. You wouldn't copy header files like from Windows to Linux and think "hey, now I can build Windows software to run on Linux", would you? No more can you copy header files from Cygwin to a Win32 compiler and expect to be able to build Win32 software using those header files.

What you need to do is to *port* the code to use what's available on Windows instead of the functionality declared in the "missing" header files.

#ifndef _WIN32
#include
#else
#include
#endif
...
#ifndef _WIN32
... whatever code that uses functionality declared in #else
... either just dummy replacement, or use corresponding Win32 APIs #endif

This is the same tree I'm using for my mozilla build environment. (I don't want two msys systems on the same PC, unless there is no choice).

No need for two MSYS systems.

--tml

What you need to do is to *port* the code to use what's available on Windows instead of the functionality declared in the "missing" header files.

Of course, it is highly likely that a library like openjpeg intended to be generally usable and cross-platform already *is* portable to Windows. And indeed it is. It's just that only project files for MSVC are provided. Furthermore, openjpeg uses a hardcoded Makefile for Unix-like compilation. no configure scripts etc, which is a bit sad.

But openjpeg is far from complex and it was trivial to modify the Unix Makefile to work with mingw. Took some fifteen minutes. There is no comprehensive test suite, but I tried building the two programs in the "codec" folder and they seemed to work, converting a TIFF image to JPEG2000 and back to TIFF. The JPEG2000 image also loaded fine into IrfanView.

Patch included below, as I don't think attachments make it through this mailing list.

The patch simply adds two files, Makefile.mingw and codec/Makefile.mingw, and adds the targets "mingw", "mingwinstall" and "mingwclean" to the main Makefile. I build only a shared library (DLL) in Makefile.mingw. Building a static library is left as an exercise to the interested.

BTW, why does the code bother to use the stdcall calling convention? Isn't stdcall kinda a historical artefact of dubious value for new code? But oh well, I didn't bother to change that.

--tml

diff -ru ../1.3.orig/codec/Makefile.mingw ./codec/Makefile.mingw --- ../1.3.orig/codec/Makefile.mingw 2008-10-28 12:27:23.509000000 +0200 +++ ./codec/Makefile.mingw 2008-10-28 12:24:06.665500000 +0200 @@ -0,0 +1,16 @@
+# Makefile for the main OpenJPEG codecs: j2k_to_image and image_to_j2k +
+CFLAGS = -O3
+
+TIFF = /devel/dist/win32/tiff-3.8.2-1 +
+all: j2k_to_image.exe image_to_j2k.exe +
+j2k_to_image.exe: j2k_to_image.c ../libopenjpeg-2.dll.a + gcc $(CFLAGS) compat/getopt.c index.c convert.c j2k_to_image.c -o j2k_to_image -L.. -lopenjpeg-2 -I ../libopenjpeg -L$(TIFF)/lib -ltiff +
+image_to_j2k.exe: image_to_j2k.c ../libopenjpeg-2.dll.a + gcc $(CFLAGS) compat/getopt.c index.c convert.c image_to_j2k.c -o image_to_j2k -L.. -lopenjpeg-2 -I ../libopenjpeg -L$(TIFF)/lib -ltiff +
+clean:
+ rm -f j2k_to_image image_to_j2k
diff -ru ../1.3.orig/Makefile ./Makefile --- ../1.3.orig/Makefile 2007-12-21 12:39:41.000000000 +0200 +++ ./Makefile 2008-10-28 12:12:18.149875000 +0200 @@ -76,3 +76,13 @@

osxclean:
make -f Makefile.osx clean
+
+mingw:
+ make -f Makefile.mingw
+
+mingwinstall:
+ make -f Makefile.mingw install
+
+mingwclean:
+ make -f Makefile.mingw clean
+
diff -ru ../1.3.orig/Makefile.mingw ./Makefile.mingw --- ../1.3.orig/Makefile.mingw 2008-10-28 12:27:29.196000000 +0200 +++ ./Makefile.mingw 2008-10-28 12:37:06.681125000 +0200 @@ -0,0 +1,54 @@
+# MinGW (i.e. GNU toolchain targeting Win32) makefile for OpenJPEG +
+VER_MAJOR = 2
+VER_MINOR = 1.3.0
+
+SRCS = ./libopenjpeg/bio.c ./libopenjpeg/cio.c ./libopenjpeg/dwt.c ./libopenjpeg/event.c ./libopenjpeg/image.c ./libopenjpeg/j2k.c ./libopenjpeg/j2k_lib.c ./libopenjpeg/jp2.c ./libopenjpeg/jpt.c ./libopenjpeg/mct.c ./libopenjpeg/mqc.c ./libopenjpeg/openjpeg.c ./libopenjpeg/pi.c ./libopenjpeg/raw.c ./libopenjpeg/t1.c ./libopenjpeg/t2.c ./libopenjpeg/tcd.c ./libopenjpeg/tgt.c +INCLS = ./libopenjpeg/bio.h ./libopenjpeg/cio.h ./libopenjpeg/dwt.h ./libopenjpeg/event.h ./libopenjpeg/fix.h ./libopenjpeg/image.h ./libopenjpeg/int.h ./libopenjpeg/j2k.h ./libopenjpeg/j2k_lib.h ./libopenjpeg/jp2.h ./libopenjpeg/jpt.h ./libopenjpeg/mct.h ./libopenjpeg/mqc.h ./libopenjpeg/openjpeg.h ./libopenjpeg/pi.h ./libopenjpeg/raw.h ./libopenjpeg/t1.h ./libopenjpeg/t2.h ./libopenjpeg/tcd.h ./libopenjpeg/tgt.h ./libopenjpeg/opj_malloc.h ./libopenjpeg/opj_includes.h
+INCLUDE = -Ilibopenjpeg
+
+# General configuration variables:
+CC = gcc
+AR = ar
+
+PREFIX = /dummy
+INSTALL_BINDIR = $(PREFIX)/bin
+INSTALL_LIBDIR = $(PREFIX)/lib
+INSTALL_INCLUDE = $(PREFIX)/include +
+COMPILERFLAGS = -Wall -O3 -ffast-math -std=c99 -DWIN32 -DOPJ_EXPORTS +
+MODULES = $(SRCS:.c=.o)
+CFLAGS = $(COMPILERFLAGS) $(INCLUDE) +
+TARGET = openjpeg
+SHAREDLIB = lib$(TARGET)-$(VER_MAJOR).$(VER_MINOR).dll +IMPLIB = lib$(TARGET)-$(VER_MAJOR).dll.a +
+
+default: all
+
+all: OpenJPEG
+
+dist: OpenJPEG
+ install -d dist
+ install $(SHAREDLIB) dist
+ install $(IMPLIB) dist
+ install libopenjpeg/openjpeg.h dist +
+OpenJPEG: $(SHAREDLIB)
+
+.c.o:
+ $(CC) $(CFLAGS) -c $< -o $@
+
+$(SHAREDLIB): $(MODULES)
+ $(CC) -shared -o $@ -Wl,--out-implib,$(IMPLIB) $(MODULES) $(LIBRARIES) +
+install: OpenJPEG
+ install -d '$(DESTDIR)$(INSTALL_LIBDIR)' '$(DESTDIR)$(INSTALL_INCLUDE)' + install $(SHAREDLIB) '$(DESTDIR)$(INSTALL_BINDIR)' + install $(IMPLIB) '$(DESTDIR)$(INSTALL_LIBDIR)' + install libopenjpeg/openjpeg.h '$(DESTDIR)$(INSTALL_INCLUDE)' +
+clean:
+ rm -rf dist u2dtmp* $(MODULES) $(SHAREDLIB) $(IMPLIB)

But openjpeg is far from complex

I mean source code file and folder structure -wise. The algorithms and code in the source files is of course probably quite complex. But one doesn't need to dive into the actual code just to build the software.

--tml

it was trivial to modify the Unix Makefile to work with mingw. Took some fifteen minutes.

That said, as there already *are* official Windows binaries (including a DLL) of libopenjpeg available from the openjpeg.org site, why not use that instead of compiling an own build? My personal opinion has always been that one should use official DLLs when available and usable.

That the OpenJPEG.dll evidently is linked with a static unknown C library and not the msvcrt.dll that mingw-compiled code uses should not be of any harm here, as the libopenjpeg API doesn't seem to pass any references to data inside the C library (like file descriptors, including those in FILE structs).

Sure, the openjpeg_v1_3_win32.zip contains no import library for the GNU toolchain, just the MS import library OpenJPEG.lib. But it should be trivial to generate a .def file from the DLL with the pexports command, and then an import library from the .def file with the dlltool command (both part of mingw).

--tml