Re: [PATCH] Thread Plug-in Support #2

[NIIBE Yutaka]

Marius Vollmer wrote:
 > Is this a good assumption?  I'd rather work from what libtool
 > specifies, or guarantees to work portably.  My main point is that I
 > have a bad feeling about stretching the shared library systems too
 > far, since the different systems are, well, different on the various
 > platforms.  Ideally, we should also take systems into account that
 > don't have dynamic linking at all.

Agreed.  I didn't say, we assume the ELF system for Guile.  I
explained ELF dynamic linking.  Well, backlinking is not supported for
AIX's shared library (IIRC) or others, but what I've said is
applicable to many platforms which is supprted by libtool.  At least,
with static linking, it works.

 > Basically, I want to be really conservative here.

I understand.

 > Yes, good point.  I haven't thought of this previously.  But again, I
 > feel safer when we would do it the standard way (standard for C, not
 > for Perl, etc, since the shared libraries have been designed for C).

Well, how about static linking?  Building the library B which depends
on library A, there's no dependency information within the library B
(except the references themselves).

When we use the library B, say, build the executable with library B,
we need library A too.  Here, the information of dependency is not in
library B, but programmer specifies library A.  In this view, it's not
rather trycky but usual for C programming.  Well, YMMV.

                        *       *       *

Well, perhaps I've found the difference of assumptions among us.

While I assume Guile system should provide the dependency information
about extension, it seems you're not.  I'm afraid of putting extension
under /usr/lib, because it means, it can be used under no control of
Guile system, which results chaos.  It seems that you think that it is
programmer who cares which extention is depends on which.

If Guile is going powerful enough, we need more good support for
interfaces, modules, and dependency.  Then, I think that it is not
programmers job to keep the knowledge of dependency in his memory.

 > I'm all for improving the Unix way of managing software components,
 > but I think we need to do this by changing the build tools like the
 > compiler itself, if we want to do it right.  IMO.

Yes, that is my point too.

When Guile will support interface/module/dependency, I think that
Guile system should support compiling/building as well as running.

For current system, I agree with you. 
--