Hello Gary,
Gary V. Vaughan <[EMAIL PROTECTED]> wrote:
[]
GVV> Unfortunately the dll architecture is so bust, that it would be unfair
GVV> to use it as a baseline for all the nicer shared library architectures
GVV> libtool supports.
Which shared library architectures are nicer - those which
require special compilation flags, and being linked (without any
warnings!) with objects compiled without that flag, crashing at
runtime? Well, we may dispute whether shared libraries are nice and
dlls are stupid, or vice-versa, but what the point. Let's just say
that they are different. Now, let me say it in system analysis/design
terms ("While I don't claim to be..." ;-))) ): those both model have own
idiosyncrasies. And our aim is to be level up those idiosyncrasies, so
they won't be idiosyncrasies any more, but just parameters of libtool
model. So, let's analyse those traits:
Shared DLLs
Building: require special support doesn't require special support
(namely, building with PIC) (are built from the same
set of objects as static would)
Using: doesn't require special require special support
support (namely, marking data as
dllimported)
So, they're not entirely different - there's strange symmetry with
them. Now let's come back to commonsense level and take shared as our
base. How can DLL's model be described? I'd call it "upside-down"
comparing to shared libs. And I find that metaphor very vivid - that's
exactly my idea behind possibility of building DLLs in similiar (by interface)
way to shared libs. Maybe to build dlls libtool will need to perform
strange steps in non-obvious order. But that's just implementation -
it *will* build them. (to the extent possible, of course).
GVV> The AC_LIBTOOL_WIN32_DLL is a *good* thing, it tells you that the
GVV> package has been ported to win32 and supports dlls. My hope is that
GVV> after libtool-1.4, the cygwin community will gradually do the ports
GVV> for all of the interesting packages, and pass the changes back
GVV> upstream to the maintainers.
Cannot agree. AC_LIBTOOL_WIN32_DLL is a *bad* thing. You may ask
who I am in hell and from what I can know that it's bad? My answer is
that I guy who read libtool manual, and then read messages in mail/
CVS subdir. That's from what I know that it's bad. I won't bore you
with reminiscing all that, instead put some humorous passage, something
like that:
"So, from doc I have learned that AIX shared one idiosyncrazy with
win32 dll - its shareds must be self contained. Well, where is
AC_LIBTOOL_AIX_SO? Let's introduce it! No doubt, happy AIX community
gradually submit patches. But stop, you say AC_LIBTOOL_WIN32_DLL means
package has been ported to win32 and supports dlls? O, what a
wonderful cause to abuse! Lets introduce AC_LIBTOOL_<os>_SO for each
existing OS! And yes, you guessed - let's not build shared libs if
it's not defined! Then, all Free Software community will have great
fun for the next millenium."
Ridiculous? Then, why such technique applied to win32 (and
eventally to its poor users?) - just because it's written by
microsoft? But if vendor does their systems bad, does it imply
that everyone who develop something for that platform should does it
that way? And that if something gets ported to it, some quirks should
be put in that?
Four days ago I got Libtool 1.3.4. I looked at code and ensured it
has support to build dlls. I decided to see how it works on 'demo'.
I ran configure. It said me it won't build dlls. "Strange", though I,
"AFAIK it should build both shared and static, if it possible, by
default". I ran configure --enable-shared. It said it won't build
dlls. "Strange", I thought. I ran configure --disable-static --enable-shared
I said no. I started suspect my sh, since it's ash and its port to my
own posix layer, pw32, which is not yet as stable as rock. But well, I
decided to look at doc, maybe it lists some additional options to
build dll? What I found is AC_LIBTOOL_WIN32_DLL . Well, I hacked to
ltconfig to forget about it. Now it agreed to build dlls.
I got "link: warining: undefined symbols not allowed in
i386-pc-mingw32 shared libraries". Totally agree. Fortunately,
libhello of course doesn't have them. Then, it choked on dlpreopen,
but I don't care about that now... 8-) No dlls! Well, let's see when
that message is printed. Aha, when $allow_underfined=='yes' and
$allow_underfined_flag=='unsupported'. Defining $allow_underfined_flag
to ''. Ok, sed chokes on .def, it doesn't support DATA, entry point is
for cygwin (I know, both problems are fixed in CVS) but DLL is finally
built!
Resume: if libtool wouldn't care too much about me, I'd get it
from the first time. If I couldn't get it, I'd get fairly
understandable linker message about underfined symbols. If libtool
were smart enough, it would suggest me what to do next. *After*
there's problem. Not saving me from the problem *before it might happen*.
Support, not deny.
Well, I talk too much. That's not what I came for. I would like
to invite you take a look at my a2dll script,
http://www.is.lg.ua/~paul/devel/binutils.html . I appreciate your
comments.
GVV> Cheers,
GVV> Gary.
--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135
