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

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

I (Soren Andersen <so...@wo...>) wrote on Sat, 25 Nov 
2000 21:08:49 , Regarding Re: Final Q on libjpeg dll build:

SA>
    I am *still* not able to link the sample apps that are part of the 
    package jpeg-6.0b. To the interface lib `libjpeg_dll.a', that is. I get 
    an error that makes NO sense at all if I try to use the
    #define GLOBAL(type)  __declspec(dllimport) *type*
    syntax for the macro.
     [this]: 
      --- console dump -----
    ../rdppm.c: In function `jinit_read_ppm':
    ../rdppm.c:444: function `jinit_read_ppm' definition is marked dllimport
    make: *** [rdppm.o] Error 1
     ---- end dump ---------
    
    If I just leave it out when building the apps I get this message:
    
      --- console dump -----
    D:\MingW32\gcc-2.95.2\bin\..\lib\gcc-lib\i386-
    mingw32msvc\2.95.2\..\..\..\..\i386-
    mingw32msvc\lib\libmsvcrt.a(ds222.o)(.idata$5+0x0): multiple definition 
    of `_imp___iob'
    .\libjpeg_dll.a(d000001.o)(.idata$5+0x0): first defined here
    make: *** [cjpeg.exe] Error 1
     ---- end dump ---------
    
    In other words if it seems I am doing it right, with the right gcc at last, *gcc 
    tells me I am doing it right and then FAILS!*
</SA

Previous replies to this posting suggested that my DLL must not be right, 
that the cause of my failure to be able to build the IGJ sample  
applications that are part of the libjpeg ("jpeg-6b") package was a 
problem with how I was building the DLL. As previously stated, I was 
trying to build the libjpeg.DLL using the new ld syntax that supports 
'--shared' and so on.

Further work on this has turned up the result that I in fact was right.

The DLL I was building was NOT the problem. I ascertained this by 
downloading the libjpeg.dll + import/interface lib from MinGW on 
SourceForge, then linking (attempting to) that. I got errors which had to 
be fixed before finally getting a clean `make' run. Those errors are *due 
to the way the sources for the "jpeg-6b" package are written*, not to my 
approach for buildding the DLL.

In detail, the sources [multiple source dependencies for each app of: 
cjpeg(.exe), djpeg(.exe), and jpegtran(.exe)] use the Cpp macros 
"EXTERN" and "GLOBAL" which are used to 'mark' functions and data for 
export by Paul Sokolovsky's patch for this package. Because I was using 
that patch (which affects one header file which is #included in all 
sources), I was telling gcc that I wanted to import functions in the 
*application* code from the *DLL*. Made no sense to gcc so it caused 
and error, and why should it make sense?

The answer I came up with is to hack two header files #included in the 
apps sources, to redefine both EXTERN and GLOBAL so that they are 
simply "extern" or naught (in the case of the GLOBAL I think this might be 
the 'right thing' to do, but I think I used "extern" and I think it didn't 
matter).

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

Building the apps against one's DLL is a good way, IMHO, to test the DLL 
for soundness before attempting to link to it in a larger package project 
which might involve multiple library dependencies (many examples of such 
come to mind: libgd, for instance, or Ghostscript) and quite a higher 
degree of complexity. Also the apps are valuable little utilities in their own 
right.

   Best,
      soren andersen