Solaris: patches to run-octave.in

Moritz Borgmann octave at moriborg.de
Mon Dec 3 18:46:41 CST 2007


>In any case, I don't think we absolutely have to exec Octave in the
>script.  David, would removing LD_PRELOAD and the exec fix the problem
>for you?

To conclude the discussion, I propose the following patchset:

ChangeLog:

2007-12-03  Moritz Borgmann  <octave at moriborg.de>

	* run-octave.in: no longer using LD_PRELOAD, which caused havoc
	with octave child processes under Solaris. The substitute is to
	spawn octave as a child process instead of using exec. This should
	allow the loader to pick up LD_LIBRARY_PATH even on Linux systems
	where it previously failed to.

Index: run-octave.in
===================================================================
RCS file: /cvs/octave/run-octave.in,v
retrieving revision 1.24
diff -u -r1.24 run-octave.in
--- run-octave.in       12 Oct 2007 21:27:12 -0000      1.24
+++ run-octave.in       4 Dec 2007 00:40:33 -0000
@@ -28,10 +28,6 @@
  top_srcdir='%abs_top_srcdir%'
  builddir='%builddir%'

-liboctinterp="$builddir/src/%liboctinterp%"
-liboctave="$builddir/liboctave/%liboctave%"
-libcruft="$builddir/libcruft/%libcruft%"
-
  d1="$top_srcdir/test"
  d2="$top_srcdir/scripts"
  d3="$builddir/scripts"
@@ -65,7 +61,7 @@
  fi

  OCTAVE_SITE_INITFILE="$top_srcdir/scripts/startup/main-rcfile" \
-LD_PRELOAD="$liboctinterp $liboctave $libcruft" \
  %library_path_var%="$builddir/src:$builddir/liboctave:$builddir/libcruft:$%library_path_var%" 
\
-  exec $driver "$builddir/src/octave" --no-initial-path 
--path="$LOADPATH" --image-path="$IMAGEPATH" --info-file="$INFOFILE" 
"$@"
+$driver "$builddir/src/octave" --no-initial-path --path="$LOADPATH" \
+  --image-path="$IMAGEPATH" --info-file="$INFOFILE" "$@"



More information about the Octave-maintainers mailing list