unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: Patrick Horgan <phorgan1@gmail.com>
To: bug-guile@gnu.org
Subject: SCM_INTERNAL causes problems
Date: Fri, 20 Jun 2008 21:15:33 -0700	[thread overview]
Message-ID: <485C8065.3090508@dbp-consulting.com> (raw)

When building lilypond the following variables:
`scm_i_gc_admin_mutex'          SCM_INTERNAL gc.h
`scm_i_init_mutex'              SCM_INTERNAL init.h
`scm_i_locale_mutex'            SCM_INTERNAL posix.h
`scm_i_misc_mutex'              SCM_INTERNAL threads.h
`scm_i_port_table_mutex'        SCM_INTERNAL ports.h
`scm_i_port_table_room'         SCM_INTERNAL ports.h
`scm_i_port_weak_hash'          SCM_INTERNAL ports.h
`scm_i_signal_delivery_thread'  SCM_INTERNAL scmsigs.h
`scm_i_structs_to_free'         SCM_INTERNAL struct.h
`scm_i_sweep_mutex'             SCM_INTERNAL gc.h

show up as multiple defines in the link phase and keep lilypond from 
building.  The problem is that the include files they are in are 
included in different .c files, so the variable definitions are in 
various .o files.  If they are really supposed to just have internal 
visibility in guile libraries wouldn't it be better to not put them in 
include files that are installed as part of make install?  I mean, you 
could put #ifdefs around them so that they wouldn't show up in builds of 
other programs like lilypond, but it seems a cleaner solution to put 
them in private include files that are never installed publicly, but 
only used in the build.

Patrick




             reply	other threads:[~2008-06-21  4:15 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-21  4:15 Patrick Horgan [this message]
2008-06-23 10:04 ` SCM_INTERNAL causes problems 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=485C8065.3090508@dbp-consulting.com \
    --to=phorgan1@gmail.com \
    --cc=bug-guile@gnu.org \
    --cc=patrick@dbp-consulting.com \
    /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).