I've installed libiconv-1.8-sol7-sparc-local and
gcc-3.4.2-sol7-sparc-local from sunfreeware on an old Solaris7 system we
have that can't be upgraded. My problem is when I try to run perl
v5.6.1 which I compiled using the gcc I downloaded. Unless I set
LD_LIBRARY_PATH, I always get:
ld.so.1: / fatal: libiconv.so.2: open
failed: No such file or directory
How can I get past this without having to always set LD_LIBRARY_PATH?
Thanks, Clif
SunHELP maillist - SunHELP (AT) sunhelp (DOT) org

In /.profile

LD_LIBRARY_PATH=$
export LD_LIBRARY_PATH

Side note: Thats a wierd place for perl to land from *-local @
sunfreeware.com

Clif Smith wrote:
I've installed libiconv-1.8-sol7-sparc-local and
gcc-3.4.2-sol7-sparc-local from sunfreeware on an old Solaris7 system we
have that can't be upgraded. My problem is when I try to run perl
v5.6.1 which I compiled using the gcc I downloaded. Unless I set
LD_LIBRARY_PATH, I always get:
ld.so.1: / fatal: libiconv.so.2: open
failed: No such file or directory

How can I get past this without having to always set LD_LIBRARY_PATH?

Thanks, Clif

SunHELP maillist - SunHELP (AT) sunhelp (DOT) org

SunHELP maillist - SunHELP (AT) sunhelp (DOT) org

So, there's no way I can compile perl so it knows where the library is
itself vs. telling users to set this and/or me setting it in
/etc/profile, etc.?

RE: Side Note: I compiled and placed it there as I'm supporting a number
of applications and some need perl v5.8 and one old one needs v5.6.1.

Marc Belanger wrote:

>In /.profile
>
>LD_LIBRARY_PATH=$
>export LD_LIBRARY_PATH
>
>Side note: Thats a wierd place for perl to land from *-local @
>sunfreeware.com
>
>Clif Smith wrote:

>
>>I've installed libiconv-1.8-sol7-sparc-local and
>>gcc-3.4.2-sol7-sparc-local from sunfreeware on an old Solaris7 system we
>>have that can't be upgraded. My problem is when I try to run perl
>>v5.6.1 which I compiled using the gcc I downloaded. Unless I set
>>LD_LIBRARY_PATH, I always get:
>>ld.so.1: / fatal: libiconv.so.2: open
>>failed: No such file or directory
>>
>>How can I get past this without having to always set LD_LIBRARY_PATH?
>>
>>Thanks, Clif
>>
>>SunHELP maillist - SunHELP (AT) sunhelp (DOT) org
>>
>>
>>
>
>>
>
>SunHELP maillist - SunHELP (AT) sunhelp (DOT) org
>

SunHELP maillist - SunHELP (AT) sunhelp (DOT) org

Matthew Weigel wrote:
Clif Smith said:

>>So, there's no way I can compile perl so it knows where the library is
>>itself vs. telling users to set this and/or me setting it in
>>/etc/profile, etc.?

1- Yes, you could fix it as you compile Perl. I haven't compiled Perl,
but "-R/path" in the argument list to ld will do it. That might go
through gcc ("-Wl,-R/path"), or it might not. If Perl uses autoconf then
adding "-R/path" to your LDFLAGS environment variable (or "-Wl," to
CCFLAGS) while running configure should do it.

2- You could also add it to the global library search path using crle(1).
If you use crle, you have to add *all* paths, not just the non-default
paths so be sure to check what the current defaults are before doing
anything.

While playing with crle, I recommend having a root shell open that has the
environment variable LD_NCNFIG set; if you screw up, you may be
completely unable to spawn new processes. Note that since su strips LD_*
environment variables when it runs, you won't even be able to set
LD_NCNFIG and then su to root - su attempts to spawn the new process
after LD_NCNFIG is stripped. Same applies to sudo if you've installed
that.

I usually use crle so that all programs will find the libraries I use.
Typically I will run crle to see the current paths then run crle -l
/usr/lib:/usr/local/lib + whatever other paths I need. My current Ultra2
workstation shows me this with crle:

Configuration file [version 3]: /var/ld/ld.config
Default Library Path (ELF):
/
Trusted Directories (ELF):/usr/lib/secure (system default)

Command line:
crle -c /var/ld/ld.config -l
/

Steve

SunHELP maillist - SunHELP (AT) sunhelp (DOT) org

Matthew Weigel wrote:
Steve Sandau said:


>>I usually use crle so that all programs will find the libraries I use.

You aren't playing with fire by having two versions of Perl, and from the
sound of it, two versions with different libraries. In his particular
situation, per-binary runpaths *might* be the way to go.

(then again, as I mention, crle is playing with fire too :-)

The bit about two versions of perl may be true here. I know that there
are problems installing a second version of perl on a Solaris box. I
usually do not need a specific version enough to install a second one.
Please do take my advice as being from a one-perl-version guy.

Having different versions of libraries that different programs need to
find certainly is playing with fire. I try to avoid that. ;-)

I have not (so far!) had problems using crle as long as I check the
current path before I play with it. I think I recall that deleting
/var/ld/ld.config will put things back to normal, too, though.

Steve

SunHELP maillist - SunHELP (AT) sunhelp (DOT) org

Matthew Weigel wrote:
26 May, 2005, at 10:11 PM, Steve Sandau wrote:


>>I have not (so far!) had problems using crle as long as I check the
>>current path before I play with it. I think I recall that deleting
>>/var/ld/ld.config will put things back to normal, too, though.

Yep. Just make sure you have a root shell open, because if ld.config
is broken enough you can not start a privileged process that doesn't
use it, and you need privilege to delete it.

Yes. Always having a root shell open when changing things is a good
idea. I think you have to be very careful with crle; I think it may
change the environment for an already-open shell, too. A root shell
ought to allow you to fix mistakes with 'rm /var/ld/ld.config' though.

Steve

SunHELP maillist - SunHELP (AT) sunhelp (DOT) org

I've set the following:
- LDFLAGS="-L/usr/local/lib -R/usr/local/lib"
- CFLAGS="-Wl,-L/usr/local/lib -Wl,-R/usr/local/lib"
However, I couldn't compile it until I again set:
- LD_LIBRARY_PATH=/usr/local/lib
After I compiled I still have the same issue of not being able to run
perl unless I set LD_LIBRARY_PATH.

I'd rather not use crle as 1) it's scary ;-) and 2) if I ever have to
use this install of perl on other systems it's one more complication to
add to the mix. Any other ideas?

Thanks, Clif

Matthew Weigel wrote:

26 May, 2005, at 10:38 PM, Steve Sandau wrote:


>
>>Yes. Always having a root shell open when changing things is a good
>>idea. I think you have to be very careful with crle; I think it may
>>change the environment for an already-open shell, too.
>
>>
>
>Yes, it effects process creation.
>

>
>A root shell
>>ought to allow you to fix mistakes with 'rm /var/ld/ld.config' though.
>
>>
>
>By itself, that's not even enough - creating the 'rm' process might
>fail :-) However, you can set LD_NCNFIG, which ignores ld.config
>long enough to delete it or change it.

SunHELP maillist - SunHELP (AT) sunhelp (DOT) org

My experience with default installs is that crle only knows about
/usr/lib. When I add a new box to nagios|plugins, I usually only have to
add /usr/local/lib for libiconv.

The plugins on Solaris 8|9|10 D NT WRK with /usr/lib first in the
library path order, for me at least. That is with a vanilla SUNWxcall
install.

I always have to use; crle -l /usr/local/lib:/usr/lib; after installing
the plugins on target boxes with gcc and libiconv from precompiled binaries.

I will reinforce the statement that having an extra root shell open when
changing global environment things|stuff has saved my ass more than
once. Also note that *.bak or *.YYMMDD is a great idea, in general.

Matthew Weigel wrote:
26 May, 2005, at 10:11 PM, Steve Sandau wrote:


>>I have not (so far!) had problems using crle as long as I check the
>>current path before I play with it. I think I recall that deleting
>>/var/ld/ld.config will put things back to normal, too, though.

Yep. Just make sure you have a root shell open, because if ld.config
is broken enough you can not start a privileged process that doesn't
use it, and you need privilege to delete it.

SunHELP maillist - SunHELP (AT) sunhelp (DOT) org