On Fri, Mar 31, 2000 at 11:29:46PM +0300, Paul Sokolovsky wrote:
> Hello Gary,
Hi Paul,
> 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?
Are there architectures which do this? I can (AFAIK) link an elf
shared library from non-pic objects on my linux box if I don't care
about them loading more slowly.
> 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.
Without meaning to be inflammatory, an elf shared library can do
everything a dll can do. The reverse is certainly *not* true!
> 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.
This is a good and true goal. But the road ahead is twisty turny and
fraught with danger... =/O|
> 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)
For modern elf based architectures compiling pic objects is an
optimisation and not a requirement.
Your statement about DLLs is wrong. Even with hairy macro usage (as
libtool supports) to allow using the same source file to build an
object for linking to a dll and an object for adding to a static
archive, the objects are different if they import or export data tags
-- and by that I mean gcc generates different asm instructions. Try
it if you don't believe me... I was rather shocked by this.
> 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.
I believe the symmetry is different to how you describe it:
Building: can be optimised with -pic can be built from same sources
with difficulty. cannot be
built from same objects, except
where no DATA is imported or
exported.
App sources: no different must be changed wrt to
which will marking imported and
be linked exported symbols.
Objects: no different compiled from different asm
which will
be linked
Symbol: linktime, loadtime, all symbols must be resolved
resolution or runtime, in deplibs or at linktime, by deplibs only.
backlinking to application (can you make an import lib
from an unlinked application?)
> 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).
I agree that it can be done. But it is *a lot* of work. Because
unix developers rely upon and use the features of elf libraries,
libtool would never be adopted if we took all these features away
because they are too hard to emulate under the Windows port.
> 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?
Not me. Your comments are valuable and appreciated. libtool could
really use someone with a better grounding in win32 to shake out the
gremlins in its feeble windows support.
> 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."
Well okay. Its a wart. I agree that it should be removed as soon as
(if) a libtool dll can be made to appear to support all the elf
features unix developers take for granted. There is a post in the
archives from me about a year ago which gives a proposal for emulating
runtime symbol resolution with dlls -- I just haven't had the time to
implement it yet (I am keen to finish 1.4, and get 1.5 underway and
finish my prototype for libtool-2.0 before I think about this proposal
again, so you are more than welcome to take it over if you like).
> Ridiculous? Then, why such technique applied to win32 (and
> eventally to its poor users?) - just because it's written by
> microsoft?
No, because a package developer must do extra work in their package for
dlls to work in all but the most trivial cases.
> 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!
The -no-undefine thing has been done to death already (see the
archives around November 1998 when I was in your shoes).
One of the TODO items for 1.4 is to audit the demo builds, and ensure
they are safe to convert to dll's -- because of the issues I have
mentioned libtool cannot transparently build them, and it is not safe
to blindly add AC_LIBTOOL_WIN32_DLL =(O|
> 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.
Agreed. If you have a way for libtool to detect that it can build a
dll (perhaps some nm magic to look for global symbols), and make sure
that all the hoops for mutual dependencies are done (even cvs libtool
won't allow this, since I only figured out it could be done a few
months ago), and diagnose problems rather than build the dll so that
no error is apparent (until you try to call one of its symbols at
runtime), it would be great to know about it =)O|
> 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.
I have a heavy workload for at least the next four weeks, during which
I will reply to email addressed directly to me, but have not enough
time to do anything else =(O| Feel free to remind me occasionally if
I forget though.
Cheers,
Gary.
--
___ _ ___ __ _ mailto:[EMAIL PROTECTED]
/ __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED]
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
\___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page: /___/ /___/ gpg public key:
http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc
