This sounds like a shell init issue... and you probably want to hunt
down where LD_LIBRARY path is *set*, rather than how it is inherited.
When you log in in run-level three, you get a login shell rather than
a normal interactive shell, and your startx inherits your login-shell's
environment, You get a normal interactive shell(?) inside
gnome-terminal/xterm if you start at run-level 5, and finally, you get
a non-interactive shell if you run a script, most of the time.
The environments in the three cases are all different, and
sometimes security related environment variables are not inherited
by forked sub-shells, such as LD_LIBRARY_PATH; or more likely,
LD_LIBRARY_PATH is set up for the login shell, and other shells
simply don't get it.
HTL
From the INVOCATION part of bash's man page - assuming that's your
login shell, otherwise, others.
===========
When bash is invoked as an interactive login shell, or as a non-inter-
active shell with the --login option, it first reads and executes com-
mands from the file /etc/profile, if that file exists. After reading
that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile,
in that order, and reads and executes commands from the first one that
exists and is readable. The --noprofile option may be used when the
shell is started to inhibit this behavior.
When a login shell exits, bash reads and executes commands from the
file ~/.bash_logout, if it exists.
When an interactive shell that is not a login shell is started, bash
reads and executes commands from ~/.bashrc, if that file exists. This
may be inhibited by using the --norc option. The --rcfile file option
will force bash to read and execute commands from file instead of
~/.bashrc.
When bash is started non-interactively, to run a shell script, for
example, it looks for the variable BASH_ENV in the environment, expands
its value if it appears there, and uses the expanded value as the name
of a file to read and execute. Bash behaves as if the following com-
mand were executed:
if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi
but the value of the PATH variable is not used to search for the file
name.
=========
Marc Schwartz (via MN) wrote:
> Hi all,
>
> In follow up to my prior post on this issue, I have found a workaround,
> but have not yet clearly identified the etiology of the problem.
> Whatever it is, it is presumably unique to my system, though if anyone
> can replicate this on another FC4 system... :-)
>
> The workaround involves booting to init 3 rather than init 5 and
> starting X manually from the console. I found this after going through
> some of the steps described below regarding my X configuration. In this
> way, LD_LIBRARY_PATH is preserved and RODBC works without issue in both
> ESS and the gnome-terminal shell start up script.
>
> Dirk was kind enough to send me an offlist e-mail yesterday in reply,
> which sparked some thoughts as I was away from the computer for a few
> hours yesterday afternoon and evening.
>
> Dirk's e-mail logically queried on any issues with gnome-terminal and/or
> the bash shell itself.
>
> Since this problem was new (this had all worked previously), I checked
> to see if there had been any recent updates to either gnome-terminal or
> bash in the FC repos. There were none, although there have been of
> course updates to GNOME, GTK and other libs.
>
> This got me to think about other updates since the last known time this
> process worked properly. So I spent several hours last night and this
> morning reviewing possibilities.
>
> The last Xorg updates are from last September, so these are not new.
>
> Other changes that I had made in the recent past include:
>
> 1. Modifying my xorg.conf to support nVidia TwinView hardware
> acceleration functionality. TwinView is like xinerama mode, spanning
> both displays to give me a virtual 3200x1200 screen, though supporting
> HW acceleration on both displays. Previously I had been using two X
> servers (also using the nVidia driver in non-xinerama mode) to support
> my dual display configuration. Reverting back to the old configuration
> did not resolve the problem.
>
> 2. The last nVidia driver update (8178) was in December and this process
> had worked since then.
>
> 3. There was an updated Cisco VPN client for Linux (4.8) to support
> recent kernels. The VPN client is installed from source. This normally
> starts up on boot as a service. Disabling the service, thus removing the
> kernel module, did not resolve the problem.
>
> 4. I had updated the encryption of several of my partitions on my laptop
> to use dm-crypt/LUKS with 256 bit AES from regular dm-crypt to take
> advantage of pending LUKS support updates in HAL and other system
> functions. Disabling the encryption (so the relevant kernel modules did
> not load), logging in as root and running ESS from root's home did not
> resolve the problem.
>
> 5. Just in case, I also reinstalled kernel version 2.6.15-1.1830
> (running 1833 now) to see if there was any change there. No joy. I
> cannot locate any of the 2.6.14 FC4 kernel versions, as these have been
> removed from the repos, so it leaves open the possibility of something
> in the .14 to .15 rebase change.
>
>
> Other than routine system updates via yum, these are the only
> "self-inflicted" changes that I have made recently. If any of the above
> should spark some thoughts, let me know.
>
> My plans are to live with this for now. FC5 is targeted for release next
> Wednesday, presuming that it stays on schedule. I'll do a clean install
> with that and see if anything is resolved, perhaps indicating some other
> issue that is as yet unidentified.
>
> Many thanks to Dirk for your assistance.
>
> Best regards,
>
> Marc Schwartz
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
