octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lt-octave and libtool run at first Octave invocation (was Re: Strang


From: Mike Miller
Subject: Re: lt-octave and libtool run at first Octave invocation (was Re: Strange Permission denied error, JIT related?)
Date: Sun, 26 Aug 2012 11:38:56 -0400

On Sun, Aug 26, 2012 at 5:18 AM, Daniel J Sebald wrote:
> On 08/26/2012 03:39 AM, Max Brister wrote:
>>
>> On Sun, Aug 26, 2012 at 2:01 AM, Daniel J Sebald<address@hidden>
>> wrote:
>>>
>>> Max,
>>>
>>> I just started seeing a strange error from the most recent code.  I
>>> compiled
>>> as root, then run octave from a user account and get a permission denied
>>> error.  I ran twice and got this:
>>>
>>> [sebald ~]$ /usr/local/src/octave/octave/build-nogui/run-octave
>>> /usr/bin/ld: cannot open output file
>>> /usr/local/src/octave/octave/build-nogui/src/.libs/19012-lt-octave:
>>> Permission denied
>>> collect2: ld returned 1 exit statusn[sebald ~]$
>>> /usr/local/src/octave/octave/build-nogui/run-octave
>>> /usr/bin/ld: cannot open output file
>>> /usr/local/src/octave/octave/build-nogui/src/.libs/19205-lt-octave:
>>> Permission denied
>>> collect2: ld returned 1 exit statusn[sebald ~]$
>>>
>>> Notice that the error message looks to be missing a backslash.  It says
>>> "statusn" and then the command line begins.  I think that is supposed to
>>> be
>>> "status\n".
>>>
>>> Notice that the library that Octave is looking for changed between
>>> attempts.
>>> In one case it is 19012-lt-octave, in the other it is 19205-lt-octave.
>>> Neither of these files are present in src/.libs.  All I see in that
>>> directory is "octave" and "octave-cli".  The two different file names
>>> make
>>> me think JIT.
>>>
>>> Now here's the strange part.  I launch ./run-octave from the build
>>> directory
>>> as root and Octave runs as normal (not surprising, I suppose).  But then
>>> I
>>> try again as a user and now Octave runs as normal (surprising?).
>>>
>>> Dan
>>
>>
>> Dan,
>>
>> I think something odd happened when you were linking. I do not see how
>> JIT could be directly related to this issue as JIT does not generate
>> any temporary files, and nothing is kept across multiple invocations
>> of Octave.
>>
>> When I look in my src/.libs folder I see
>> lt-octave  octave  octave-cli
>
>
> OK, sorry.  I must have never run from "user" without having run from "root"
> first.  Running octave from root (i.e., the first invocation) creates the
> "lt-octave" file.

Yes, "lt" is short for libtool, which is supposed to manage the
complexity of shared libraries on differing systems with no set
standard. More on that further down.

This begs the question that I think was posed in a prior thread, why
are you building or running as root? Whichever user does the compile
owns the build directory, other users should stay out.

> I've looked at "run-octave", and not much... oh wait, I think I see it now:
>
> OCTAVE_DEFAULT_QT_SETTINGS="$top_srcdir/gui/default-qt-settings" \
>   exec $builddir/libtool --mode=execute $driver \
>     "$octave_executable" --no-init-path --path="$LOADPATH" \
>     --image-path="$IMAGEPATH" --doc-cache-file="$DOCFILE" \
>     --texi-macros-file="$TEXIMACROSFILE" --info-file="$INFOFILE" "$@"
>
> I did a simple grep:
>
> [sebald octave]$ grep OCTAVE_DEFAULT_QT_SETTINGS */*/*
> libgui/src/resource-manager.cc:  std::string dsf = octave_env::getenv
> ("OCTAVE_DEFAULT_QT_SETTINGS");
>
> IF I'm understanding this correctly, the first time Octave is launched, it
> looks for OCTAVE_DEFAULT_QT_SETTINGS and runs that script?  That means the
> "lt-octave" comes from the "libtool" invocation at first launch.

Unrelated. That variable is the path for Octave to load instead of
"default-qt-settings". This is just a way to get the GUI to find the
default settings file in the build directory in case it is your first
time running Octave. If that variable is not set, it will look in a
directory under the Octave install location.

The run-octave script does for m-files, info documentation, and this
Qt settings file, what libtool does for shared libraries, it sets up
the environment and command line of Octave to find all the pieces it
needs in the build directory which has a different hierarchy from the
install directory.

> A couple things about this:
>
> 1) I indicated the option "--disable-gui", so I would think
> OCTAVE_DEFAULT_QT_SETTINGS wouldn't have any bearing.
>
> 2) If my interpretation is correct, I think neither will this run for
> someone who compiles and then installs to a system directory.  To do that
> install would require being root (or if it asks for a root password, then
> enter the root password).  So once it is installed at the system level and a
> user tries to run, the same thing will happen as I described.
>
> I'm not sure what the intended behavior is.  Can someone please clear up the
> sequence of events.

Here's my attempt. This is all related to libtool, and all intended to
be "under the hood", no need to dig into these details normally.

When you run in the build directory, libtool is intervening to make
sure the shared libraries that the executable needs are found in the
build hierarchy, because they haven't been installed yet.

In the build directory, look at src/octave. It is a shell script
created by libtool just for the purpose of running in the build
directory. This is the script that creates lt-octave the first time
you run it.

Now if you look in src/.libs, those are the real executables, octave
is the one that is installed by "make install", lt-octave is only used
for running in the build tree.

When you make "install", the libraries and executables are copied to
the paths you specified in your invocation of configure (or defaults).
This means the libraries will be found as intended and none of this
libtool shell script indirection is needed anymore. As long as basic
file permissions are correct on the install destination, anyone can
run the installed binaries.

Hope that clears things up a bit.

-- 
mike


reply via email to

[Prev in Thread] Current Thread [Next in Thread]