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

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

On 26 Nov 2000, an entity purporting to be Paul Sokolovsky [Paul Sokolovsky 
<pa...@is...>] wrote [regarding Re: [Mingw-users] Final Q on libjpeg 
dll build]  

> 
>     Now, can you bridge new devel tools and my port? Just in case it's not
> obvious ;-) (I guess it should be in the docs also), you should apply
> patch.diff and run (sh script) Build.sh from my distribution. Let's look
> at the latter:

Paul,

There are a *great many* not-very-obvious things about the current state of 
minGW development. If I was inclined to be easily discouraged by having to 
figure things out on my own, I would have given up long ago.

In the interest of contributing to your better knowledge of what might be 
happening to people using the code/methodologies *you* develop, I offer my 
experience. Not intended as negative criticism.

First of all, I have tried 4 or 5 ways of building libjpeg.dll -- I have 
**exhaustively** investigating **everything**, from the oldest pre-dllwrap 
methods (everything I am referring to is documented at various places on 
the Internet or comes from notes inside source packages) .. to the classic 
one-shot dllwrap invocation, to a first run (this is my personal fav) of 
dlltool to generate a *.DEF file that I can (I think one *should*) 
"manually" review before proceeding, followed up by using that *.DEF file 
as input into a dllwrap run to finish up .. to your shell script a2dll, to 
the new gcc/ld "native" ("knows how to do it at last") DLL building 
invocation.

Your shell script crashed repeatedly (ntvdm faults I think Windows says). 
And it contains hardcoded paths to POSIX commands like (as I recall) rm, 
that therefor failed for me. You should change that. I am not going to 
spare the time now to go much into my POV on the UNI*-like filesystem 
issue. I believe it isn't widely correctly understood that this *IS* a 
*big* problem. If you tell users that they *have to have* (gosh, I am 
taking the time .. ) a certain _filesystem tree_ set up on their system 
(and also cannot build sources on another volume !!), how *different* is 
that from the monolithic, "we'll decide what's best for everyone" 
philosophy of M$? I will leave the provocative question there. Suffice to 
say, my view is that the classic "you must have xxx.??? in your PATH" is 
the right way to approach this on Win computers.

I fixed your script and oddly, basename STILL crashes *every time*. So, I 
am NOT thrilled with your method. But I succeeced in building a dll, as I 
did also through numerous other approaches. I -- if I had saved them all -- 
would have more than a dozen "libjpeg.dlls" on my filesystem.

As for your patch: it's trivial. It hardly needs to be applied as a patch. 
I think my previous messages adaquately documented what I did and showed 
that I had used the substance of your patch.

Again, not meaning to be negatively critical, but to help you get up to 
speed, like a reality check: you may be just a touch overconfident about 
the universal efficacy of what you've developed. Overconfidence is often 
behind refusing to believe that an intelligent and motivated individual has 
actually grasped and executed all the prerequisites of one's proposed 
methodology, yet it still hasn't worked as you passionately believe it 
should have.

Plus, Mumit has allegedly (I don't say single-handedly, I don't know) 
updated ld.exe to produce dlls *directly* and *it worked* for me. I need to 
emphasize at this point that a more careful reading of my recent messages 
would cause to rise to the place of foremost noticeability, that *I have 
the DLL,* the problem is that *I cannot build the apps*. The messages I 
have posted indicate that ld.exe doesn't know what __declspec(dllimport) 
means. I think that maybe on the use-dll run, such symbols should just be 
declared "extern" and maybe it will work. I have some basis in empirical 
recent experience (10 hours ago) for thinking so.

Thanks for the time you've taken to contribute to minGW some very 
insightful and useful tools and knowledge/documentation. I benefitted from 
visiting your site enormously, would have if no other reason than (I think) 
from there, I found `pgrep', a GREAT tool that is going to _change my life_ 
;-).


Best,
    soren andersen