|
From: Soren A. <so...@wo...> - 2000-11-24 19:46:43
|
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
|