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

[Paul S. <pa...@is...>]

Hello Soren,

Soren Andersen <so...@wo...> wrote on Monday, November 27, 2000:

SA> On 26 Nov 2000, an entity purporting to be Paul Sokolovsky [Paul Sokolovsky
SA> <pa...@is...>] wrote [regarding Re: [Mingw-users] Final Q on libjpeg
SA> 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:

SA> Paul,

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

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

    Thanks, that's exactly what I'm lacking and what I'd like to hear.

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

    I should note that my a2dll script is just offshot of my research
of making dll building more sane. I also did exhaustive consideration
(and implementation) of many different approaches, but finally have
fount ultimate way - all gory details can (so, should) be done in ld.
Still, some by-products may be useful ;-)

SA> Your shell script crashed repeatedly (ntvdm faults I think Windows says).

    Sorry, but that's shell script and hence cannot crash (not in the
same sense as machine code app). That's interpreter or some other
utility crashes.

SA> And it contains hardcoded paths to POSIX commands like (as I recall) rm,
SA> that therefor failed for me. You should change that. I am not going to
SA> spare the time now to go much into my POV on the UNI*-like filesystem
SA> issue. I believe it isn't widely correctly understood that this *IS* a
SA> *big* problem. If you tell users that they *have to have* (gosh, I am
SA> taking the time .. ) a certain _filesystem tree_ set up on their system
SA> (and also cannot build sources on another volume !!), how *different* is
SA> that from the monolithic, "we'll decide what's best for everyone"
SA> philosophy of M$?

    It differs because those paths are standard - for example, that
script can be run on any (properly installed) Linux box and I
believe, on most other unices too.

SA> I will leave the provocative question there. Suffice to
SA> say, my view is that the classic "you must have xxx.??? in your PATH" is
SA> the right way to approach this on Win computers.

    But you're right, no need to use explicit paths when it can go
without it. I may describe why I used them: win32 native shells
(command.com and cmd.exe) are somewhat broken and interprete some
commands, for example, mkdir and rmdir inherently as the builtins. For
example, try to run 'mkdir.exe' at the native prompt. So, I get used
to workaround it by specifying full path and dragged that bad habit to
sh scripts too.

SA> I fixed your script and oddly, basename STILL crashes *every time*.

    Submit a bug report to vendor of your posix environment ;-) I use
pw32 - it works perfectly.

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

    With one difference: my way (patch is a part of it) leads to
correctly working result (for me, of course).

SA> Again, not meaning to be negatively critical, but to help you get up to
SA> speed, like a reality check: you may be just a touch overconfident about
SA> the universal efficacy of what you've developed.

    Just exactly opposite! I'm quite underconfident about that stuff,
I simply don't get enough feedback on it! Fortunately, this improves
last time.

SA>  Overconfidence is often
SA> behind refusing to believe that an intelligent and motivated individual has
SA> actually grasped and executed all the prerequisites of one's proposed
SA> methodology, yet it still hasn't worked as you passionately believe it
SA> should have.

    I only think that idea - having one place for the ports of
commonly used stuff, and following strict rules for syntax (not
semantics) of those ports is beneficial. I cannot pledge that way it's
done currently is totally right, and even in its bounds, totally
consistent. Still, I think it's somewhat better that was available
before. There's big room for improvement, particulary in documentation
for those strict conventions. That's what fresh mind can do the best
;-)

SA> Plus, Mumit has allegedly (I don't say single-handedly, I don't know)
SA> updated ld.exe to produce dlls *directly* and *it worked* for me.

    (Clean) patches to bring libjpeg to use ld --shared to build dll
are welcome!

SA> I need to
SA> emphasize at this point that a more careful reading of my recent messages
SA> would cause to rise to the place of foremost noticeability, that *I have
SA> the DLL,* the problem is that *I cannot build the apps*.

    As you might infer from my messages, this is implication of
building dll not so right way.

SA> The messages I
SA> have posted indicate that ld.exe doesn't know what __declspec(dllimport)
SA> means. I think that maybe on the use-dll run, such symbols should just be
SA> declared "extern" and maybe it will work. I have some basis in empirical
SA> recent experience (10 hours ago) for thinking so.

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

    Please don't let it - pgrep is just a demonstration app of PCRE,
it may or may not have all functionality of the standard grep. You'd
better use the latter for the common tasks. YMMV


SA> Best,
SA>     soren andersen


--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135