unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
To: Peter O'Gorman <peter@pogma.com>
Cc: "Guile bug" <bug-guile@gnu.org>, "Ludovic Courtès" <ludo@gnu.org>,
	libtool-patches@gnu.org
Subject: Re: Mac OS X .dylib not working
Date: Fri, 4 Mar 2011 19:47:25 +0100	[thread overview]
Message-ID: <20110304184724.GL10500@gmx.de> (raw)
In-Reply-To: <4D712A62.2090901@pogma.com>

[ dropping bug-libtool ]

Hi Peter,

* Peter O'Gorman wrote on Fri, Mar 04, 2011 at 07:07:30PM CET:
> Ok?

A few copyright year bumps are missing.
Some minor nits inline below.

Thank you,
Ralf

> Subject: [PATCH] On Mac OS X try .dylib as well as .so with lt_dlopenext
> 
> * libltdl/m4/ltdl.m4: Define extra extension if module extension
> differs from shared lib extension.
> * libltdl/ltdl.c: Use it.
> * tests/darwin.at: Test it.
> Reported by Hans Aberg, Michael Ellis, and others.

> --- a/tests/darwin.at
> +++ b/tests/darwin.at
> @@ -228,3 +228,224 @@ mv stdout expout
>  LT_AT_CONFIGURE([LDFLAGS=-L/there/is/no/dir/here])
>  AT_CHECK([./libtool --config],[ignore],[expout],[ignore])
>  AT_CLEANUP
> +
> +AT_SETUP(darwin can lt_dlopen .dylib and .so files)

Missing m4 quotes (for style only)

> +AT_KEYWORDS([libltdl dylib])
> +
> +# This test requires shared library support.
> +AT_CHECK([$LIBTOOL --features | grep 'enable shared libraries' || exit 77],
> +	 [], [ignore])
> +
> +
> +eval `$LIBTOOL --config | $EGREP '^(shlibpath_var|shrext_cmds)='`
> +
> +module=no
> +eval shared_ext=\"$shrext_cmds\"
> +module=yes
> +eval module_ext=\"$shrext_cmds\"
> +
> +# Only bother with this test if module extension is different from
> +# shared extension
> +AT_CHECK([test "$shared_ext" != "$module_ext" || exit 77],
> +         [], [ignore])

You can drop arguments two and three here.

> +# This code is copied from the Autobook:
> +# <http://sources.redhat.com/autobook/autobook/autobook_169.html>
> +# so if it needs changes, be sure to notify the Autobook authors
> +# about them.

> +int
> +main (int argc, const char *argv[])
> +{
> +  char *errormsg = NULL;
> +  lt_dlhandle module = NULL;
> +  entrypoint *run = NULL;
> +  int errors = 0;

Isn't this lacking
  LTDL_SET_PRELOADED_SYMBOLS();

or was that needed only for static libs (which you've excluded earlier)?

> +  if (argc != 3)
> +    {
> +      fprintf (stderr, "USAGE: main MODULENAME ARGUMENT\n");
> +      exit (EXIT_FAILURE);
> +    }
> +
> +  /* Initialise libltdl. */
> +  errors = lt_dlinit ();
> +
> +  /* Set the module search path. */
> +  if (!errors)
> +    {
> +      const char *path = getenv (MODULE_PATH_ENV);
> +
> +      if (path != NULL)
> +        errors = lt_dlsetsearchpath (path);
> +    }
> +
> +  /* Load the module. */
> +  if (!errors)
> +    module = lt_dlopenext (argv[1]);
> +
> +  /* Find the entry point. */
> +  if (module)
> +    {
> +      run = (entrypoint *) lt_dlsym (module, "run");
> +
> +      /* In principle, run might legitimately be NULL, so
> +         I don't use run == NULL as an error indicator
> +         in general. */
> +      errormsg = dlerrordup (errormsg);
> +      if (errormsg != NULL)
> +        {
> +          errors = lt_dlclose (module);
> +          module = NULL;
> +        }
> +    }
> +  else
> +    errors = 1;
> +
> +  /* Call the entry point function. */
> +  if (!errors)
> +    {
> +      int result = (*run) (argv[2]);
> +      if (result < 0)
> +        errormsg = strdup ("module entry point execution failed");
> +      else
> +        printf ("\t=> %d\n", result);
> +    }
> +
> +  /* Unload the module, now that we are done with it. */
> +  if (!errors)
> +    errors = lt_dlclose (module);
> +
> +  if (errors)
> +    {
> +      /* Diagnose the encountered error. */
> +      errormsg = dlerrordup (errormsg);
> +
> +      if (!errormsg)
> +        {
> +          fprintf (stderr, "%s: dlerror() failed.\n", argv[0]);
> +          return EXIT_FAILURE;
> +        }
> +    }
> +
> +  /* Finished with ltdl now. */
> +  if (!errors)
> +    if (lt_dlexit () != 0)
> +      errormsg = dlerrordup (errormsg);

I'm not particularly fond of this coding style, where ownership
information essentially gets lots once an error occurs in any
of the commands.  Might be ok for a test like this, but not such
a good example for users.  lt_dlexit could be warranted even if
some error occurred before.  Anyway, I won't reject the patch for
this.

> +  if (errormsg)
> +    {
> +      fprintf (stderr, "%s: %s.\n", argv[0], errormsg);
> +      free (errormsg);
> +      exit (EXIT_FAILURE);
> +    }
> +
> +  return EXIT_SUCCESS;
> +}
> +
> +/* Be careful to save a copy of the error message,
> +   since the  next API call may overwrite the original. */
> +static char *
> +dlerrordup (char *errormsg)
> +{
> +  char *error = (char *) lt_dlerror ();
> +  if (error && !errormsg)
> +    errormsg = strdup (error);
> +  return errormsg;
> +}
> +]])

> +if test "$shlibpath_var" = PATH; then

This looks wrong; shouldn't it be != here?  Otherwise, ...

> +  $unset shlibpath_var || shlibpath_var=
> +fi
> +rm $libdir/simple-module.la

... this has only a small chance of succeeding.

> +rm $libdir/libsimple-dylib.la
> +
> +for dir in inst/lib "$libdir"; do
> +  LT_AT_EXEC_CHECK([./ltdl-loader], [], [stdout], [ignore],
> +	    [$dir/simple-module World])
> +  AT_CHECK([grep "Hello, World" stdout], [], [ignore])
> +  LT_AT_EXEC_CHECK([./ltdl-loader], [], [stdout], [ignore],
> +	    [$dir/libsimple-dylib World])
> +  AT_CHECK([grep "Hello, World" stdout], [], [ignore])
> +done
> +
> +AT_CLEANUP



  reply	other threads:[~2011-03-04 18:47 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-03 19:32 Mac OS X .dylib not working Hans Åberg
2011-03-03 19:56 ` Michael Ellis
2011-03-04  2:59   ` Peter O'Gorman
2011-03-04  3:41     ` Michael Ellis
2011-03-04  8:59     ` Andy Wingo
2011-03-04  9:44     ` Hans Aberg
2011-03-04 18:07       ` Peter O'Gorman
2011-03-04 18:47         ` Ralf Wildenhues [this message]
2011-03-04 19:00           ` Peter O'Gorman
2011-03-05 16:16             ` Peter O'Gorman
2011-03-04  3:00 ` Bob Friesenhahn
2011-03-04  3:48   ` Michael Ellis
2011-03-04 17:04     ` Ralf Wildenhues
2011-03-04  9:47   ` Hans Aberg
  -- strict thread matches above, loose matches on Subject: below --
2011-03-03 19:53 Hans Aberg
2010-02-01 14:26 Hans Aberg
2010-02-02  6:42 ` Ralf Wildenhues
2010-02-02  9:08   ` Hans Aberg
2010-02-02 14:20     ` Ken Raeburn
2010-02-02 15:48       ` Hans Aberg
2010-02-02 16:52         ` Bob Friesenhahn
2010-02-02 17:15           ` Hans Aberg
2010-02-02 18:01             ` Ludovic Courtès
2010-02-03 14:23               ` Ken Raeburn
2010-02-03 15:10                 ` Ludovic Courtès
2010-02-04 12:40           ` Hans Aberg
2010-02-04 13:49             ` Peter O'Gorman
2010-02-04 15:21               ` Hans Aberg
2010-02-04 15:34                 ` Peter O'Gorman
2010-02-04 16:52                   ` Hans Aberg
2010-02-04 16:58                   ` Hans Aberg

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=20110304184724.GL10500@gmx.de \
    --to=ralf.wildenhues@gmx.de \
    --cc=bug-guile@gnu.org \
    --cc=libtool-patches@gnu.org \
    --cc=ludo@gnu.org \
    --cc=peter@pogma.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).