Hello Charles,
Charles S. Wilson <[EMAIL PROTECTED]> wrote:
[ Talk about versioning on win32 skipped - I'd rather have DLLs being
built first, and them go for elaborating their versioning. But I agree
with Gary's following letter that mere libfoo.dll.a should suffice -
if one would like to have several versions of implibs, one free to do
it on his own]
CSW> Developing an ld.so runtime loader requires far fewer changes to
CSW> libtool, and since you *can* link directly to dll's (*) it'll work 'just
CSW> like unix (tm). But developing ld.so will be a tough job.
Well, can't stand itch to comment on this. I don't think that
porting ELF loader to windows would be very hard. Of course, Linux's
ld.so is a mess (well, I even don't know how much ELF handling on
Linux is done in ld.so and how much in kernel), but that's not the
only source. Just to remember, lxrun could be one. In fact, I even saw
someone working ELF .o loader for win32 (of course, it doesn't have
loader for shared libs). But what the point would be of such thing?
Before I go for it, let me summary some PE-DLL idiosycrasies and
how they are accounted by some people vs me:
Implibs: I consider implib unalienable part of DLL model, and eager to
support this MS feature; I'd never give up it. But DJ Delorie did hack
for ld to link against bare dll and Gary put it into libtool.
Mandatory data imports marking: I *hate* this feature and develop
libtool re-implementation which frees programmer from it. But when I
mentioned it on cygwin maillist, DJ Delorie was rather sceptical about
it, saying they will support MS way.
So, it seems that mileage is really varies unpredictably. My one
concerning ld.so on win32 is as follows: it would be just to
far-fetched; win32 is about PE, and PE is about DLL, maintaining
compatibility and direct interopertability with native way is
important to me. YMMV
CSW> --Chuck
--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135
