IRIX and Software

Nekoware gdb install problem - Page 1

rwengerter
Who joined Nov. 22, 2010, 12:02 a.m.
and authored 53 notes

Wrote the following at March 23, 2013, 9:52 a.m...

I have installed Nekoware gdb from Nekoware current under Irix 6.5.29. I get the following message
when I run gdb:
2322:gdb: rld: Fatal Error: Cannot Successfully map soname 'libiconv.so.3' under any of the
filenames ...

I deinstalled gdb and deinstalled libiconv. Then I reinstalled libiconv and gdb and get the same error
message. I additionally installed Firefox 3 together with all the libraries it needs but I still
cannot run gdb.
How can I fix it?

_________________
:Fuel:

600 MHz, 2 GB RAM, 72 GB 15k RPM HD
:O2:

180 MHz

duck
Who joined Oct. 27, 2003, 5:22 p.m.
and authored 363 notes

Wrote the following at March 23, 2013, 11:29 a.m...

It's either the wrong iconv (version) or a path problem. The former probably. It might be as simple as symlinking the lib file to the version it expects (though IRIX often uses the ELF version numbers more than other platforms [in my experience] and this might cause problems even if the different versions ABI equivalent)

_________________
:Octane:

halo , oct ane
N.B.: I tend to talk out of my ass. Do not take it too seriously.

foetz
Who joined April 14, 2003, 3:34 a.m.
and authored 4683 notes

Wrote the following at March 23, 2013, 11:57 a.m...

execute:

Code:

versions -n | fgrep iconv

ld -liconv

if the output doesn't help please post it here then

_________________
r-a-c.de

rwengerter
Who joined Nov. 22, 2010, 12:02 a.m.
and authored 53 notes

Wrote the following at March 23, 2013, 12:29 p.m...

Here is the output of the comands:

Quote:

versions -n | fgrep iconv
I neko_libiconv 4 libiconv-1.14 character set conversion library
I neko_libiconv.man 4 man pages
I neko_libiconv.man.doc 4 html documentation
I neko_libiconv.man.manpages 4 man pages
I neko_libiconv.sw 4 software
I neko_libiconv.sw.eoe 4 execution only env
I neko_libiconv.sw.lib 4 shared libraries
-bash-4.2$ ld -liconv
-bash: ld: command not found

_________________
:Fuel:

600 MHz, 2 GB RAM, 72 GB 15k RPM HD
:O2:

180 MHz

rwengerter
Who joined Nov. 22, 2010, 12:02 a.m.
and authored 53 notes

Wrote the following at March 24, 2013, 2:59 a.m...

The problem is still not solved.
Any more suggestions?

_________________
:Fuel:

600 MHz, 2 GB RAM, 72 GB 15k RPM HD
:O2:

180 MHz

hamei
Who joined Feb. 24, 2004, 4:10 p.m.
and authored 8449 notes

Wrote the following at March 24, 2013, 3:30 a.m...

rwengerter wrote:

The problem is still not solved.
Any more suggestions?

I don't have gdb but < ls -l > in /usr/nekoware/lib returns

Code:

-rw-r--r--    1 root     sys           945 Feb 15  2012 libiconv.la

lrwxr-xr-x    1 root     sys            15 Feb 24 15:53 libiconv.so -> libiconv.so.3.1

lrwxr-xr-x    1 root     sys            15 Feb 24 15:53 libiconv.so.3 -> libiconv.so.3.1

-rw-r--r--    1 root     sys        965748 Feb 15  2012 libiconv.so.3.1

Looks like a couple of links. It's quite possible I did this under similar circumstances ... while hacks like this are not recommended, can't hurt to try

_________________
lemon tree very pretty and the flower very sweet ...

foetz
Who joined April 14, 2003, 3:34 a.m.
and authored 4683 notes

Wrote the following at March 24, 2013, 5:45 a.m...

rwengerter wrote:

The problem is still not solved.
Any more suggestions?

hehe sure, one at a time

now we need:

Code:

find /usr/nekoware -name 'libiconv*'

_________________
r-a-c.de

rwengerter
Who joined Nov. 22, 2010, 12:02 a.m.
and authored 53 notes

Wrote the following at March 24, 2013, 2:07 p.m...

This is the output of the command:

Quote:

find /usr/nekoware -name 'libiconv*'
/usr/nekoware/share/locale/af/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/bg/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/ca/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/cs/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/de/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/eo/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/es/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/et/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/fi/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/fr/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/ga/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/hu/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/id/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/nl/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/pl/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/pt_BR/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/ro/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/ru/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/sk/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/sv/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/tr/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/uk/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/vi/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/zh_CN/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/zh_TW/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/da/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/el/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/gl/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/it/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/sl/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/sr/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/hr/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/sq/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/wa/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/locale/rm/LC_MESSAGES/libiconv.mo
/usr/nekoware/share/doc/libiconv
/usr/nekoware/lib/libiconv.so.3
/usr/nekoware/lib/libiconv.la
/usr/nekoware/lib/libiconv.so
/usr/nekoware/lib/libiconv.so.3.1
-bash-4.2$

_________________
:Fuel:

600 MHz, 2 GB RAM, 72 GB 15k RPM HD
:O2:

180 MHz

foetz
Who joined April 14, 2003, 3:34 a.m.
and authored 4683 notes

Wrote the following at March 24, 2013, 2:42 p.m...

alright there we have the not found libiconv. do you have /usr/nekoware/lib in your LD_LIBRARYN32_PATH?

_________________
r-a-c.de

rwengerter
Who joined Nov. 22, 2010, 12:02 a.m.
and authored 53 notes

Wrote the following at March 25, 2013, 10:43 a.m...

LD_LIBRARYN32_PATH is empty.
If I set LD_LIBRARYN32_PATH to "/usr/nekoware/lib" gdb and ddd works.
Is this the recommended setting?

_________________
:Fuel:

600 MHz, 2 GB RAM, 72 GB 15k RPM HD
:O2:

180 MHz

foetz
Who joined April 14, 2003, 3:34 a.m.
and authored 4683 notes

Wrote the following at March 25, 2013, 3:21 p.m...

rwengerter wrote:

LD_LIBRARYN32_PATH is empty.
If I set LD_LIBRARYN32_PATH to "/usr/nekoware/lib" gdb and ddd works.
Is this the recommended setting?

it's not recommended it's a must

it's a basic, mandatory setting for all system running n32 libs which goes for everything running irix 6.5. consider it a replacement of LD_LIBRARY_PATH as you have it on other unix flavors.

_________________
r-a-c.de

duck
Who joined Oct. 27, 2003, 5:22 p.m.
and authored 363 notes

Wrote the following at March 26, 2013, 5:35 a.m...

Weeelll... It really should have a baked-in rpath for /usr/nekoware/lib. That's where the dependent libraries are installed anyway, and if they aren't THEN LD_LIBRARYx_PATH comes into play, IMHO.

_________________
:Octane:

halo , oct ane
N.B.: I tend to talk out of my ass. Do not take it too seriously.

foetz
Who joined April 14, 2003, 3:34 a.m.
and authored 4683 notes

Wrote the following at March 26, 2013, 9:33 a.m...

duck wrote:

Weeelll... It really should have a baked-in rpath for /usr/nekoware/lib. That's where the dependent libraries are installed anyway, and if they aren't THEN LD_LIBRARYx_PATH comes into play, IMHO.

not sure about nekoware but i always disable rpath explicitly. this way you're free to place stuff where you want and just need to add it to a few env vars.

_________________
r-a-c.de

jpstewart
Who joined Sept. 21, 2010, 2:31 p.m.
and authored 165 notes

Wrote the following at March 26, 2013, 9:59 a.m...

I'll agree with duck that LD_LIBRARYN32_PATH shouldn't be a requirement. It sounds like the packager forgot to use the -Wl,-rpath -Wl,/usr/nekoware/lib option (or specified the wrong path) when building the software.

In another thread elsewhere here (which I can't seem to find at the moment), I was told point blank (by somebody more knowledgable than I am about these things) that it should be considered an error in the package if LD_LIBRARYN32_PATH was required for any of Nekoware; that rpath was considered the correct way to handle Nekoware library paths.

_________________

Sun SPARCstation 20, Blade 2500
HP C8000

foetz
Who joined April 14, 2003, 3:34 a.m.
and authored 4683 notes

Wrote the following at March 26, 2013, 10:47 a.m...

LD_LIBRARYN32_PATH is a mandatory requirement of all irix system running n32 libs and binaries.

_________________
r-a-c.de

jpstewart
Who joined Sept. 21, 2010, 2:31 p.m.
and authored 165 notes

Wrote the following at March 26, 2013, 11:44 a.m...

foetz wrote:

LD_LIBRARYN32_PATH is a mandatory requirement of all irix system running n32 libs and binaries.

No. It is not. Read the rld man page for more information. It is clearly optional ("3. Use LD_LIBRARY_PATH, if it is defined in the environment at the time of execution" from that page, emphasis mine) and only used if the shared object was specified without a full path and it's not found in the specified RPATH (which may be empty). In other words, LD_LIBRARYN32_PATH is a fallback for when the executable doesn't supply library path info of its own.

And there's a hardcoded default path that's used as a fallback after that, that includes /usr/lib32 and other standard paths where you'll find the system-installed libraries. For many N32 binaries (such as those installed with IRIX itself) that is sufficient to find their shared libraries without needing LD_LIBRARYN32_PATH set after a fresh install.

So that should show that there's no "mandatory requirement" for LD_LIBRARYN32_PATH.

Besides, my Octane and O300 both run just fine without it set, including those Nekoware packages which set rpath as suggested in the Packaging Software Wiki page.

_________________

Sun SPARCstation 20, Blade 2500
HP C8000

foetz
Who joined April 14, 2003, 3:34 a.m.
and authored 4683 notes

Wrote the following at March 26, 2013, 2:11 p.m...

hehe by the book often doesn't reflect reality. those vars exist for a reason, offer nice flexibility and don't affect performance or anything else in a negative way in any way. for every unix user it's a self-evident task to set environment variables so i don't see any problem at all.

_________________
r-a-c.de

hamei
Who joined Feb. 24, 2004, 4:10 p.m.
and authored 8449 notes

Wrote the following at March 26, 2013, 6:09 p.m...

foetz wrote:

those vars exist for a reason, offer nice flexibility and don't affect performance or anything else in a negative way ...

While it's true that normally the LD_LIBRARYN32_PATH causes no problems, under some circumstances it can. If you search around here you can probably find a few cases. Since I live at the fringe, it's happened to me. Canavan did a good job of explaining why, so I'm not going to muddy the clear waters of his description

A different method of achieving the same result is to create a wrapper script for problematic programs (such as this gdb) which sets the LD_LIBRARYN32_PATH for just that process then starts the program. That way you get your environment setting for only the faulty apps that need it.

_________________
lemon tree very pretty and the flower very sweet ...

foetz
Who joined April 14, 2003, 3:34 a.m.
and authored 4683 notes

Wrote the following at March 27, 2013, 8:31 a.m...

sure nothing is 100% but in my experience those path/var issues are mostly caused by messed up installations and/or just missing skills at setting such things. that goes for unix in general not only for irix' specific variables.

_________________
r-a-c.de

canavan
Who joined July 21, 2003, 5:19 a.m.
and authored 665 notes

Wrote the following at March 28, 2013, 9:30 a.m...

Maybe your skills are superior to mine, so maybe you have a solution to install a nekoware sqlite and still get a functioning nekoware firefox?