g-wrap-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Runtime library structure


From: Andreas Rottmann
Subject: Re: Runtime library structure
Date: Wed, 12 Nov 2003 23:14:03 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

Rob Browning <address@hidden> writes:

> Andreas Rottmann <address@hidden> writes:
>
>> - Have one shared lib with all the non-generated stuff that almost
>>   every wrapset would need. This would include my runtime wrapper
>>   stuff and probably g-wrap-wct.c; name this something like
>>   libgwrap-runtime.
>
> Sounds reasonable, depending on what's included.
>
This is in already a patch in my archive:

tla revisions -s g-wrap--rotty--0.2
patch-1
    Add runtime library, ffi support
...

My g-wrap-runtime.c has 774 lines...

>> - For each wrapper shlib, directly link in the support functions
>>   needed. I can see the need for explicitly compiling linking against
>>   those support functions from other wrapsets, but I think we should
>>   get rid of it (this is certainly possible with runtime wrapper
>>   creation).
>>
>> - Can't a wrapset compile/link against a wrapset shlib? If it can, I
>>   don't see a need for separation into support wrapper shared
>>   libraries.
>
> Can you elaborate on these a bit?  I'm not sure I completely
> understood the proposal.
>
Hmm, I'm not exactly totally clear what I intended here, too ;-) My
idea was to get rid of the second shared libs per wrapset
(e.g. libgwrap-glib.la). But don't I think that is that important
anymore. Anyhow, if it is possible to link against a .la that is used
used as the C part of the guile module generated, we may as well link
e.g.  g-wrap-glib.c into libgw-glib.la instead of libgwrap-glib.la and
get rid of the latter. Hope this makes this a bit clearer. A related
note: libtool (1.5 at least) apparently complains about the mix of
-module and direct linking:

*** Warning: Linking the executable test-link-gw-wct against the loadable 
module*** libgw-wct.so is not portable!

This may indicate that direct linking is not supported for modules,
which would make the separate shlib necessary in cases where the
functions in there are used by more than one wrapset.

Cheers, Andy
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Python is executable pseudocode, Perl is executable line-noise.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]