unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* dynamic argv0 relocation
@ 2005-06-10 13:05 Jan Nieuwenhuizen
  2005-06-10 15:52 ` Ken Raeburn
  2005-06-10 21:49 ` Kevin Ryde
  0 siblings, 2 replies; 7+ messages in thread
From: Jan Nieuwenhuizen @ 2005-06-10 13:05 UTC (permalink / raw)
  Cc: Han-Wen Nienhuys

Hi,

It would be nice if guile/libguile would have/support dynamic
relocation based on the location of the executable (be it guile or
lilypond).

For installations on Windows and autopackage installations on Linux,
the install prefix is determined at install time.  On Linux, this can
be fixed with wrappers (not very elegant), but on Windows (read: lots
of flavours, lots of different problems) that can hardly be done, if
at all.

Below is an attempt that works, but I'm not sure about the api nor the
implementation.  What do you think?

Jan.

Index: ChangeLog
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/ChangeLog,v
retrieving revision 1.464
diff -p -u -r1.464 ChangeLog
--- ChangeLog	5 Jun 2005 18:15:30 -0000	1.464
+++ ChangeLog	10 Jun 2005 12:27:07 -0000
@@ -1,3 +1,7 @@
+2005-06-08  Jan Nieuwenhuizen  <janneke@gnu.org>
+
+	* configure.in: Add --enable-relocation option.  Default off.
+
 2005-06-05  Marius Vollmer  <mvo@zagadka.de>
 
 	From  Jan Nieuwenhuizen <janneke@gnu.org>.  Thanks!
Index: configure.in
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/configure.in,v
retrieving revision 1.267
diff -p -u -r1.267 configure.in
--- configure.in	5 Jun 2005 18:15:21 -0000	1.267
+++ configure.in	10 Jun 2005 12:27:07 -0000
@@ -1030,6 +1030,18 @@ esac
 AC_MSG_CHECKING(what kind of threads to support)
 AC_MSG_RESULT($with_threads)
 
+## Dynamic relocation, based on argv[0].
+reloc_p=no
+AC_ARG_ENABLE(relocation,
+    [  --enable-relocation     compile with dynamic relocation.  Default: off],
+    [reloc_p=$enableval])
+
+if test "$reloc_p" = "yes"; then
+   AC_DEFINE([ARGV0_RELOCATION], [1], [Dynamic relocation])
+   AC_DEFINE_UNQUOTED([PATH_SEPARATOR], "$PATH_SEPARATOR", [Path separator])
+   AC_DEFINE_UNQUOTED([GUILE_EFFECTIVE_VERSION], "$GUILE_EFFECTIVE_VERSION", [GUILE_EFFECTIVE_VERSION])
+fi # $reloc_b
+
 ## Cross building	
 if test "$cross_compiling" = "yes"; then
   AC_MSG_CHECKING(cc for build)
Index: libguile/ChangeLog
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/ChangeLog,v
retrieving revision 1.2280
diff -p -u -r1.2280 ChangeLog
--- libguile/ChangeLog	6 Jun 2005 19:55:08 -0000	1.2280
+++ libguile/ChangeLog	10 Jun 2005 12:27:09 -0000
@@ -1,3 +1,18 @@
+2005-06-09  Jan Nieuwenhuizen  <janneke@gnu.org>
+
+	Experimental relocation patch.
+
+	* load.c (scm_init_argv0_relocation)[ARGV0_RELOCATION]: New
+	function.
+	
+	(scm_init_load_path)[ARGV0_RELOCATION]: Use it.
+
+	* load.c (scm_c_argv0_relocation)[ARGV0_RELOCATION]:
+	
+	* guile.c (main)[ARGV0_RELOCATION]: Use it to append from
+	executable location derived scm library directory.
+	[__MINGW32__|__CYGWIN__]: Append directory of executable to PATH.
+
 2005-06-06  Marius Vollmer  <mvo@zagadka.de>
 
 	* print.c (iprin1): When writing a string, collect all characters
Index: libguile/guile.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/guile.c,v
retrieving revision 1.19
diff -p -u -r1.19 guile.c
--- libguile/guile.c	23 May 2005 19:57:20 -0000	1.19
+++ libguile/guile.c	10 Jun 2005 12:27:09 -0000
@@ -71,6 +71,11 @@ main (int argc, char **argv)
   extern const lt_dlsymlist lt_preloaded_symbols[];
   lt_dlpreload_default (lt_preloaded_symbols);
 #endif
+
+#if ARGV0_RELOCATION
+  scm_c_argv0_relocation (argv[0]);
+#endif /* ARGV0_RELOCATION */
+
   scm_boot_guile (argc, argv, inner_main, 0);
   return 0; /* never reached */
 }
Index: libguile/load.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/load.c,v
retrieving revision 1.86
diff -p -u -r1.86 load.c
--- libguile/load.c	23 May 2005 19:57:20 -0000	1.86
+++ libguile/load.c	10 Jun 2005 12:27:09 -0000
@@ -180,6 +180,45 @@ SCM_DEFINE (scm_parse_path, "parse-path"
 }
 #undef FUNC_NAME
 
+#if ARGV0_RELOCATION
+#include "filesys.h"
+#if defined (__CYGWIN__) || defined (__MINGW32__)
+#include "posix.h"
+#endif
+
+char const *global_argv0 = 0;
+
+void
+scm_c_argv0_relocation (char const *argv0)
+{
+  global_argv0 = argv0;
+}
+
+SCM
+scm_init_argv0_relocation (char const* argv0)
+{
+  SCM bindir = scm_dirname (scm_from_locale_string (argv0));
+  SCM prefix = scm_dirname (bindir);
+  SCM libdir = scm_string_append (scm_list_2 (prefix,
+					     scm_from_locale_string ("/share/guile/" GUILE_EFFECTIVE_VERSION)));
+
+#if defined (__CYGWIN__) || defined (__MINGW32__)
+  {
+    SCM path;
+    char *env = getenv ("PATH");
+    if (env)
+      path = scm_string_append (scm_list_3 (scm_from_locale_string (env),
+					    scm_from_locale_string (PATH_SEPARATOR),
+					    bindir));
+    else
+      path = bindir;
+    scm_putenv (scm_string_append (scm_list_2 (scm_from_locale_string ("PATH="), path)));
+  }
+#endif /* __CYGWIN__ || __MINGW32__ */
+    
+  return scm_list_1 (libdir);
+}
+#endif /* ARGV0_RELOCATION */
 
 /* Initialize the global variable %load-path, given the value of the
    SCM_SITE_DIR and SCM_LIBRARY_DIR preprocessor symbols and the
@@ -200,6 +239,11 @@ scm_init_load_path ()
   if (env)
     path = scm_parse_path (scm_from_locale_string (env), path);
 
+#if ARGV0_RELOCATION
+  if (global_argv0)
+    path = scm_append (scm_list_2 (path, scm_init_argv0_relocation (global_argv0)));
+#endif /* __CYGWIN__ || __MINGW32__ */
+  
   *scm_loc_load_path = path;
 }
 
Index: libguile/load.h
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/load.h,v
retrieving revision 1.22
diff -p -u -r1.22 load.h
--- libguile/load.h	23 May 2005 19:57:20 -0000	1.22
+++ libguile/load.h	10 Jun 2005 12:27:09 -0000
@@ -26,6 +26,10 @@
 
 \f
 SCM_API SCM scm_parse_path (SCM path, SCM tail);
+#if ARGV0_RELOCATION
+SCM_API void scm_c_argv0_relocation (char const *argv0);
+SCM_API SCM scm_init_argv0_relocation (char const* argv0);
+#endif
 SCM_API void scm_init_load_path (void);
 SCM_API SCM scm_primitive_load (SCM filename);
 SCM_API SCM scm_c_primitive_load (const char *filename);


-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: dynamic argv0 relocation
  2005-06-10 13:05 dynamic argv0 relocation Jan Nieuwenhuizen
@ 2005-06-10 15:52 ` Ken Raeburn
  2005-06-10 21:49 ` Kevin Ryde
  1 sibling, 0 replies; 7+ messages in thread
From: Ken Raeburn @ 2005-06-10 15:52 UTC (permalink / raw)


On Jun 10, 2005, at 09:05, Jan Nieuwenhuizen wrote:
> It would be nice if guile/libguile would have/support dynamic
> relocation based on the location of the executable (be it guile or
> lilypond).

Would configuring Guile with this option break executables linked 
against libguile and installed with different prefixes?  Or is there 
something the application can do (aside from using the same prefix) to 
find the Guile code?

> Below is an attempt that works, but I'm not sure about the api nor the
> implementation.  What do you think?

I haven't reviewed it closely, but at first glance, you do seem to be 
assuming that whoever runs configure doesn't use the --bindir (etc) 
arguments, so that you know how to construct $bindir (etc) from a 
single prefix string.  That's all well and fine, and probably correct 
99% of the time, but it might be good to add a check in the configure 
script, and error out if one of the directory variables is set to 
something other than what's expected.

Ken


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: dynamic argv0 relocation
  2005-06-10 13:05 dynamic argv0 relocation Jan Nieuwenhuizen
  2005-06-10 15:52 ` Ken Raeburn
@ 2005-06-10 21:49 ` Kevin Ryde
  2005-06-11  2:03   ` Ken Raeburn
  2005-06-15 14:38   ` Jan Nieuwenhuizen
  1 sibling, 2 replies; 7+ messages in thread
From: Kevin Ryde @ 2005-06-10 21:49 UTC (permalink / raw)
  Cc: Han-Wen Nienhuys, guile-devel

Jan Nieuwenhuizen <janneke@gnu.org> writes:
>
> Below is an attempt that works, but I'm not sure about the api nor the
> implementation.  What do you think?

No offence, but it sounds very dubious to me.  These things are meant
to be settled at the "make all" build stage.  (The gnu standards have
bits about that.)

Incidentally, for a normal svr4 system won't you still need
libguile.so in a location known to the loader?  It won't be able to
find it for the main guile executable otherwise.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: dynamic argv0 relocation
  2005-06-10 21:49 ` Kevin Ryde
@ 2005-06-11  2:03   ` Ken Raeburn
  2005-06-12  4:20     ` Rob Browning
  2005-06-15 14:38   ` Jan Nieuwenhuizen
  1 sibling, 1 reply; 7+ messages in thread
From: Ken Raeburn @ 2005-06-11  2:03 UTC (permalink / raw)


On Jun 10, 2005, at 17:49, Kevin Ryde wrote:
> No offence, but it sounds very dubious to me.  These things are meant
> to be settled at the "make all" build stage.  (The gnu standards have
> bits about that.)

Normally, it is, yes, if the application has to have that knowledge 
pre-compiled in.  But does it have to?  It's better still if it just 
doesn't need to do that.

I'd like to bring up a variant on the package-installation issue that 
Jan raised: Mac OS X applications.  An app is represented to the user 
as an object.  It can be moved around, opened (launched), or deleted, 
like any other object.  It just happens that its representation in the 
file system is a directory hierarchy with certain standard components, 
and some application-specific components.  The "Emacs" app, for 
example, includes all of the content of a normal Emacs installation 
buried under Emacs.app/Contents/MacOS and Emacs.app/Contents/Resources. 
  My copy lives in /Applications, but the string "/Applications" doesn't 
seem to live in the executable; it figures out where it is.  I can move 
it to my desktop and launch it from there, and it still works just 
fine.  Or I can copy it to an external drive or a network drive.  If I 
had a copy stored in a networked home directory for use from multiple 
machines, I could copy the *same* application to local disk on my 
office workstation and use it locally, without having to rebuild.  It's 
*very* nice to be able to copy/move an application from one place to 
another or rename it, like you could do for any other object, and have 
it Just Work.  (And it's not unheard of in other GNU software.  See 
GCC's GCC_EXEC_PREFIX environment variable, for example.)

I could see, maybe, creating a Guile.app which starts up a 
terminal-like window with a Guile interpreter running, or something 
like that.  Menu items for "load Scheme file", "new interpreter", etc.  
With all the Scheme support files buried inside, it too could be 
treated as a standalone object.

I think the thing that makes this case tricky is the Guile library.  
The other cases of this sort of thing that I'm familiar with are all 
applications, and don't have to worry about library search paths, or 
being used from within a different package located someplace else.  
(And in the case of Mac OS X, it appears that the "launch" protocol 
includes invoking the executable via an absolute path name and with 
some magic arguments.)  Unfortunately, I don't have any good ideas for 
how to make the library code path-independent without introducing 
environment variables or something like that which the user would have 
to manually set.

Ken


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: dynamic argv0 relocation
  2005-06-11  2:03   ` Ken Raeburn
@ 2005-06-12  4:20     ` Rob Browning
  0 siblings, 0 replies; 7+ messages in thread
From: Rob Browning @ 2005-06-12  4:20 UTC (permalink / raw)
  Cc: guile-devel

Ken Raeburn <raeburn@raeburn.org> writes:

> I think the thing that makes this case tricky is the Guile library.

You may have already been thinking of these, but in case not, it's
also any other libraries provided by Guile (srfi 13/14) or by any
external modules, and while the Guile library has to be somewhere that
ld.so looks, the other libtool loaded libraries have to be somewhere
that libtool's libltdl looks.  These are similar, but I believe may
not always be the same.  (Does liblttdl look in /usr/local/lib by
default now?).

In any case, I'd be hesitant to start automatically modifying the
environment unless we're *really* sure that what we're doing is the
right thing.  For example, prepending something to PATH or
LD_LIBRARY_PATH may alter a user's intentional ordering and may change
the effective versions of other libs or executables in undesirable
ways.

Of course these comments are most directly applicable to traditional
unix-like OSes.  I'm sure it's possible that we might need to do
arrange things differently on other platforms, but if so, I'd like to
try to make sure that it's clear what the appropriate solution is, and
that those with sufficient experience with the platform (i.e. probably
not me) have adequately considered any corner cases.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: dynamic argv0 relocation
  2005-06-10 21:49 ` Kevin Ryde
  2005-06-11  2:03   ` Ken Raeburn
@ 2005-06-15 14:38   ` Jan Nieuwenhuizen
  2005-06-17  0:03     ` Kevin Ryde
  1 sibling, 1 reply; 7+ messages in thread
From: Jan Nieuwenhuizen @ 2005-06-15 14:38 UTC (permalink / raw)
  Cc: Han-Wen Nienhuys

Kevin Ryde writes:

> No offence, but it sounds very dubious to me

That's why I added the configure option and compile switch.  You do
not want this enabled for well behaved systems.  Could you live with
that?

> These things are meant to be settled at the "make all" build stage.

I know, but when installing on Microsoft Windows, or in a user account
using autopackage on Linux, the install prefix is determined at
install time.

> (The gnu standards have bits about that.)

(I really like the gnu standards, but when these where written, was
build time not virtually the same as install time?)

Btw, what bit are you referring to?

> Incidentally, for a normal svr4 system won't you still need
> libguile.so in a location known to the loader?  It won't be able to
> find it for the main guile executable otherwise.

Yes, if something like this goes in, we should add that.  I only used
this for LilyPond's native Windows port, where wrappers are not really
an option.

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: dynamic argv0 relocation
  2005-06-15 14:38   ` Jan Nieuwenhuizen
@ 2005-06-17  0:03     ` Kevin Ryde
  0 siblings, 0 replies; 7+ messages in thread
From: Kevin Ryde @ 2005-06-17  0:03 UTC (permalink / raw)
  Cc: Han-Wen Nienhuys, guile-devel

Jan Nieuwenhuizen <janneke@gnu.org> writes:
>
> That's why I added the configure option and compile switch.  You do
> not want this enabled for well behaved systems.  Could you live with
> that?

I guess it's not actively harmful :-).  Some configury that divined or
selected the conventions of a particular system might be clearer than
stuff about argv0.  I'm not sure how many w32 users for instance would
be smart enough to associate that with moving their tree :).

> (I really like the gnu standards, but when these where written, was
> build time not virtually the same as install time?)
>
> Btw, what bit are you referring to?

Only the little spot in "Directory Variables" about $prefix where it's
supposed to influence compiling with "make all", but then doesn't
change the contents under "make install".  $DESTDIR probably/hopefully
renders that slightly obsolete.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2005-06-17  0:03 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-06-10 13:05 dynamic argv0 relocation Jan Nieuwenhuizen
2005-06-10 15:52 ` Ken Raeburn
2005-06-10 21:49 ` Kevin Ryde
2005-06-11  2:03   ` Ken Raeburn
2005-06-12  4:20     ` Rob Browning
2005-06-15 14:38   ` Jan Nieuwenhuizen
2005-06-17  0:03     ` Kevin Ryde

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).