Segmentation Fault on export LD_LIBRARY_PATH

[liaK]

Hi,
I am using both Centos & RedHat distributions.

In my RedHat one, I tried echo $LD_LIBRARY_PATH which returns a blank line. I added my lib dir as export LD_LIBRARY_PATH=/mylibdir. Now after I done this, even my ls throws me segmentation fault. I even tired export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/mylibdir. I couldn't run my application too. It too shows Segmentation fault.

I am doing this all under a user who is not root. I need this because my application comes in a RPM package which can be relocated and installed in the user directory instead of a default one. Now in the installed path all the libraries will be present and I have to add them to LD_LIBRARY_PATH.

But for some reason, it shows segmentation fault afterwards. I tried this in CentOS as well, even as a non root user which works fine as expected. My RedHat that shows segmentation fault is Red Hat Enterprise Linux Client release 5.7 (Tikanga).

What am I missing here?

[atreyu]

Your CentOS version is not the same as your RHEL version (b/c CentOS did not release 5.7, I believe), is that right? That might be why it works on CentOS and not on RHEL.

As to the reason for the segfault, I'm not sure. Something to do with library conflicts, I'm guessing. What is in your /mylibdir? Does it contain static libraries that the binaries installed by your RPM require?

Pick a binary from the RPM you installed and are trying to run, and do this:

ldd /path/to/RPM/bin

What does that tell you?

[liaK]

Pick a binary from the RPM you installed and are trying to run, and do this:

ldd /path/to/RPM/bin

What does that tell you?

Well, I tried ldd /home/installedDirectory/libQtCore.so.4, which tells me that

linux-vdso.so.1 => (0x00007fff98dfe000)
libz.so.1 => /home/installedDirectory/libz.so.1 (0x00007f2090745000)
libpthread.so.0 => /home/installedDirectory/libpthread.so.0 (0x00007f2090529000)
libdl.so.2 => /home/installedDirectory/libdl.so.2 (0x00007f2090325000)
libstdc++.so.6 => /home/installedDirectory/libstdc++.so.6 (0x00007f2090025000)
libm.so.6 => /home/installedDirectory/libm.so.6 (0x00007f208fda1000)
libgcc_s.so.1 => /home/installedDirectoryy/libgcc_s.so.1 (0x00007f208fb93000)
libc.so.6 => /home/installedDirectory/libc.so.6 (0x00007f208f83c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2090ce5000)

And I don't think they are static libraries. Every library has .so.* extensions.

I made to link the correct libraries by adding a .conf file in the /etc/ld.so.conf.d directory and running /sbin/ldconfig. Now it links the correct directory. But it do require a sudo access for adding /etc/ld.so.conf.d directory. I'd love make this done without a sudo access. That's why I went for LD_LIBRARY_PATH.

And I am at a loss why am receiving a seg.fault at LD_LIBRARY_PATH.

[atreyu]

Yeah, I meant shared, sorry.

I'm guessing that is why your 'ls' command broke, b/c in that /home/installedDirectory are core libraries (libc.so.6, libgcc_s.so), which are different (I'm assuming) from the ones installed in /lib. So ls was using the newer (wrong) libraries when executed, versus the ones it was built against (in /lib).

Is your hardware 64-bit?

What RPM are you trying to run? It might be easier to rebuild (from the Source RPM) if the platform is different, or if the binary is not built against libraries matching your system.

[liaK]

Is your hardware 64-bit?

Yes.

And I think your guess might very well be the reason.

What RPM are you trying to run?

I ran a binary rpm which I built through rpmbuild -bb. I believe this is what you meant.
I am bit naive in RPM,TBH.

It might be easier to rebuild (from the Source RPM) if the platform is different, or if the binary is not built against libraries matching your system.

Can you please elaborate on that? I am not aware of it.

[atreyu]

I guess you rebuilt the RPM (rpmbuild -bb) on a machine OTHER than the RHEL box? If so, try rebuilding the RPM on the RHEL box itself. There are ways to build an RPM for other distros on one box (see mock) but that takes some setting up. It's easier to just rebuild it on the machine itself, if you can.

[liaK]

I guess you rebuilt the RPM (rpmbuild -bb) on a machine OTHER than the RHEL box?

Yes.

If so, try rebuilding the RPM on the RHEL box itself.

That might not be possible because it is on the Customers end who aren't well versed with Linux and I don't want them build the files by themselves.

There are ways to build an RPM for other distros on one box (see mock) but that takes some setting up.

Probably what I want and I'll look into that.

And thanks for your replies. It is really helpful. Thanks and Cheers.