Re: [Mingw-users] Re: Final Q on libjpeg dll build

[Soren A. <so...@wo...>]

On 19 Dec 2000, an entity purporting to be Paul 
Sokolovsky [Paul Sokolovsky <pa...@is...>] 
wrote [regarding Final Q on libjpeg dll 

> Soren Andersen <so...@wo...> wrote on Thursday, December 14, 2000:
 
> SA> If this additional hack isn't done, the sample apps cannot be built by
> SA> being linked to a DLL using minGW/gcc. (Nor would Cygwin/gcc work in
> SA> principle). In this sense, Mr. Sokolovsky's patch doesn't patch the entire
> SA> "jpeg-6b" _package_, only allows building a DLL. I think users should be
> SA> aware of this and so I am saying so. I lost a LOT of hours on this.

>     I don't understand how your problems apply to my ports. My ports
> are complete - everything what package normally builds is built with
> my port, unless impossible due to the mingw underfunctionality (not
> the case with libjpeg) and are tested (with regression procedure, if
> available, otherwise manually). Patches proving the opposite are
> welcome.

Paul, I was addressing specifically the jpeg-6b/libjpeg I was directed to 
awhile back on this List, at the url:
http://download.sourceforge.net/mingwrep/libjpeg-devel-6b-20000702.zip

I won't enter into a discussion about your ports or patches in general, that I 
haven't ever worked with.

Your file includes a makefile, a .diff patch for morecfg.h, and that's about all. 
In the archive there are the following files:
---------------------------------------------------
include:
jconfig.h   jerror.h    jmorecfg.h  jpeglib.h

lib:
libjpeg.a

var/build/libjpeg-6b:
Build.sh*   patch.diff
---------------------------------------------------
So, in the patch.diff file it does this:
diff -cr libjpeg-6b/jmorecfg.h libjpeg-6b-mingw32/jmorecfg.h
which is fine as far as it goes. It makes the header file "jmorecfg.h" read

---------------------------------------------------
#if defined(_WIN32) || defined(__declspec) || !defined(STATIC)
#ifdef BUILD
#define GLOBAL(type)		__declspec(dllexport) type
#define EXTERN(type)		extern __declspec(dllexport) type
#else
#define GLOBAL(type)		__declspec(dllimport) type
#define EXTERN(type)		extern __declspec(dllimport) type
#endif
#else
/* a function referenced thru EXTERNs: */
#define GLOBAL(type)		type
/* a reference to a GLOBAL function: */
#define EXTERN(type)		extern type
#endif
---------------------------------------------------
But this header file is included in a chain of includes, into the code for the 
applications cjpeg, djpeg and jpegtran. That springs a compiler error when 
the cpp encounters "__declspec(dllimport)" definitions/initializations *in the 
files comprising the source for the apps*. That is because the same 
preprocessor defines are used in those sources as in the sources for the 
library. So, I cannot see how you can say that there are no problems with 
jpeg-6b and building it under MinGW.

You don't provide a makefile, instead you provide a shell script that reads 
thus (in part):
------------------------------------------------------------------------
#!/bin/sh

echo Should build using native compiler
prefix=/usr/local
export CFLAGS="-O2 -DBUILD"
./configure
make libjpeg.a
a2dll libjpeg.a -o libjpeg.6.dll
make
------------------------------------------------------------------------
What your script does is set the define for BUILD (thru "CFLAGS") when 
building the DLL lib, then runs ./configure, then `make's the interface lib, 
then `make's the default target ('all'). Letting alone the limitation that the 
user has to have a flawlessly working POSIX shell to do it this way, it 
simply won't won't work. You never set BUILD = '' (null) do you? So where 
do the macro defines get set to allow the import of symbols when the apps 
are being built? And where do the defines get set to *nothing* when the 
source files for the apps themselves are being parsed?

This is all the age-old C programming "extern" problem. "extern" means 
something different and often contradictory to the intentions the 
programmer has (and what the cpp will accept) depending on where it is 
encountered as the cpp parses the source files. My intention is not to attack 
you, but you have consistently thrown the ball back at me brusquely, 
basically claiming the burden is on me to show that there's a problem, 
whenever I have addressed a problem question to something you've 
originated. 

It's possible that there is something about how you have everything set up 
in one tiny detail or another, that has escaped my efforts to absolutely 
precisely duplicate your approach. Nevertheless, I ask you, Paul, to show 
me a makefile generated by your shell script and the ./configure it runs, 
and some binaries of the apps you build with it linked against your 
"libjpeg.6.dll" by your makefile. (The binary download at:
http://download.sourceforge.net/mingwrep/libjpeg-6b-20000702.zip
*does not include the apps*, only these four files: libjpeg.mft, libjpeg.ver, 
libjpeg.6.dll).

I *have mine* (that is, at the url
http://www.wonderstorm.com/techstuff/libjpeg.html
) I have posted the makefile and the binary fruits of the build using MinGW 
and my working shell (what `make' uses to run commands: the latest 
Cygwin bash invoked as `sh'). I am NOT using PW32 because I have given 
up on it, because it simply won't run on my system, and "that's all MY fault 
[somehow] and not your problem". The Cygwin bash is glorious, much 
improved over previous buggy beta releases. Using my makefile, however, 
one doesn't have to fire up a login session in bash to build the package. 
Running it from cmd.exe works just fine.

A final thought of mine, Re: statements made by anyone here that maintain 
that running / learning PW32 is necessary before one asks for help / makes 
queries on this List: part of the point of MinGW, I thought, was its 
"minimalism": just enough of "everything" (POSIX, etc.)  to get the job 
done.

  Best,
     soren andersen