IRIX and Software

Nekoware gdb install problem - Page 1

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
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.
execute:
Code:
versions -n | fgrep iconv
ld -liconv


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

_________________
r-a-c.de
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
The problem is still not solved.
Any more suggestions?

_________________
:Fuel: 600 MHz, 2 GB RAM, 72 GB 15k RPM HD
:O2: 180 MHz
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 :D

_________________
lemon tree very pretty and the flower very sweet ...
rwengerter wrote:
The problem is still not solved.
Any more suggestions?

hehe sure, one at a time :P

now we need:
Code:
find /usr/nekoware -name 'libiconv*'

_________________
r-a-c.de
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
alright there we have the not found libiconv. do you have /usr/nekoware/lib in your LD_LIBRARYN32_PATH?

_________________
r-a-c.de
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
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 :P
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
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.
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
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.

_________________
:Indigo2IMP: :Octane: :Indigo: :O3x0:
Sun SPARCstation 20, Blade 2500
HP C8000
LD_LIBRARYN32_PATH is a mandatory requirement of all irix system running n32 libs and binaries.

_________________
r-a-c.de
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.

_________________
:Indigo2IMP: :Octane: :Indigo: :O3x0:
Sun SPARCstation 20, Blade 2500
HP C8000
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
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 :D

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 ...
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
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?