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