[Mingw-users] msvc libs & headers errors (DLL-building)

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

Hello Again,

Happy holiday to those of you who consume the Bird at this time of year, 
hope yours was tender.

I am trying a fresh build of a DLL from the venerable libjpeg-6.0b package. 
I have built it before using mingw but only with frantic, disorganized & 
ugly hacking that left me (months later) without a good way to do it again 
from pristine source (I have gotten a little less clueless since then about 
many things relating to makefiles etc.). When I tried to link the stuff from 
the gd package with my old lib, I got errors. So I decided to invest some 
time in trying to do it better so that I can readily set up multiple-package 
builds like gd and GD.pm that use libjpeg (and so i can document precisely 
what i do this time for other's sake). I built the static lib first and linked it in 
to gd, as a test-run, to be methodical and be sure I know what I am doing 
this time.

Background:
I am using "mingw32 0.3" - gcc 2.95.2 on WinNT. My make is gnu make. 
My `make' shell is the sh.exe from Cygwin (or bash from same). I have 
tried to leave as much of the Cygwin stuff out of the picture as possible, 
though. That is, I don't fire up interactive login in bash before I start 
running `make'; I just do stuff from cmd.exe.

To the point:
I want to ask the sages here who know the libs like the back of their hands 
(or wrote or hacked them) about these errors from gcc at compile-and-link 
time for the sample exes that come in jpeg-6.0b. [THAT IS, I *did* get a 
DLL built and now I am trying to check its soundness/usability by liking 
something to the interface lib libjpeg_dll.a (my naming scheme, non-
standard, in case someone wonders. I keep my DLL interface libs and my 
static libs named differently so as to distinguish one from the other. 
Requires only the most minimal makefile tweaking to accomplish.).


# 11/24/00
# error in linking libjpeg 6.0b app `jpegtran'  to libjpeg.DLL

# [cpp_msvc_path] = D:\MingW32\gcc-2.95.2\bin\..\lib\gcc-lib\i386-
mingw32msvc\2.95.2\..\..\..\..\i386-mingw32msvc **(for readability)**


gcc -Wall -s -L. -o jpegtran.exe jpegtran.o rdswitch.o cdjpeg.o transupp.o \
          -ljpeg_dll
[cpp_msvc_path]\lib/libmsvcrt.a(
ds222.o)(.idata$5+0x0): multiple definition of `__imp__iob'
./libjpeg_dll.a(ds0.o)(.idata$5+0x0): first defined here
[cpp_msvc_path]\lib/libmsvcrt.a(
ds222.o)(.idata$5+0x0): multiple definition of `_imp___iob'
./libjpeg_dll.a(ds0.o)(.idata$5+0x0): first defined here

make: *** [jpegtran.exe] Error 1


# compile-time error on same run (previous to above)


gcc -c -O2 -I. -I.. -Wundef -DBUILD_DLL ../jcapistd.c -o jcapistd.o
[cpp_msvc_path]\include\stdlib.h:186:
  warning: array `_sys_errlist' assumed to have one element
[cpp_msvc_path]\include\stdio.h:163:
  warning: array `_iob' assumed to have one element

---- end console dump -----------

I am going to mention right now that I haven't been able to keep up 
rigorously with every change happening with mingw over the months, and 
while I applied patches and updates quite extensively in the past, that was 
months ago. Therefore I conceed it is possible that the issues raised here 
have been discussed, and I missed it. If so, if someone will be kind enough 
to let me know that (and in whatever tone they want, although, just FYI, 
this group has a bit of a collective tendency toward snippiness in our 
responses; I am sure that is due to working so hard on this, heavy 
involvement which leads to loss of perspective about those who haven't 
been able to make mingw the continual center of their concerns ..) and I 
apologize in advance.

Once again, the point of this present exercise is to get the latest Perl mod 
`GD.pm' built using mingw, to add to my mingw-built Perl 5.7 installation, 
and to be able to offer the module on the 'Net as a ppm binary zip to those 
who would like to download it (vs. a MSVC++ -built binary). To do this 
right I have to first build every dependency in a reliable, robust way. I 
admit my desire to use libjpeg as a DLL instead of linking it in statically is 
my whim, tho.

 Thanks,
    soren andersen