From: Rob Browning <rlb@defaultvalue.org>
To: guile-devel@gnu.org
Subject: Re: scm_cell vs threads build option
Date: Sun, 02 Sep 2007 17:09:21 -0700 [thread overview]
Message-ID: <87lkbovccu.fsf@raven.defaultvalue.org> (raw)
In-Reply-To: <87fy1x9a8u.fsf@zip.com.au> (Kevin Ryde's message of "Sun\, 02 Sep 2007 10\:33\:37 +1000")
Kevin Ryde <user42@zip.com.au> writes:
> I gave Rob's new debian packaged 1.8.2 a go and found a bit of a problem
> with scm_cell. The new packages have threads enabled, where the old
> ones had it disabled, and alas that setting infects the inlined
> scm_cell(). If you built your app against the old and run it against
> the new then it bombs on SCM_FREELIST_LOC doing the different "thread
> key" thingie access.
>
> I guess scm_cell has been inlined that way for a while, but it'd be
> worth thinking about not inlining it, or only inlining for internal
> uses, in the interests of binary compatibility among as many build
> options as possible.
>
> I struck the problem in my own build of guile-gtk, not sure what
> packaged stuff might be affected. gnome-games seems ok. Anything using
> smobs probably isn't.
This is potentially bad (for Debian at least). I'll have to
investigate, but it may mean that I will have to revert Debian's build
for now so that it doesn't enable threads.
If the library ABIs really aren't binary compatible, then I probably
won't be able to re-enable threads in Debian for 1.8 without some
fairly ugly workaround (parallel packages, or similar).
The problem is that Guile 1.8 in Etch was compiled without threads
(due to some serious problems at the time). So if there is a binary
incompatibility, then I can't re-enable threads now without breaking
everything in stable (Etch) that was compiled against the non-threaded
version.
Of course, it's generally considered a big mistake to produce two
libraries with the same soname and incompatible binary APIs. Perhaps
Guile should use a different name for the threaded libs if they're not
compatible.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2007-09-03 0:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-02 0:33 scm_cell vs threads build option Kevin Ryde
2007-09-03 0:09 ` Rob Browning [this message]
2007-09-03 7:28 ` Ludovic Courtès
2007-09-04 5:22 ` Rob Browning
2007-09-04 0:46 ` Kevin Ryde
2007-09-03 7:34 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lkbovccu.fsf@raven.defaultvalue.org \
--to=rlb@defaultvalue.org \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).