Wow those directories are waaay to deep. Whoever did that was not afraid of PATH_MAX.
You have two different versions of middleware. While trying what I am showing you, be sure sure you find a common and correct release level of the libraries. Maybe it is: libbfunctor.so. in the 7.5.5.0.02 subdirectory -- this must match the current production version of the library.
Anyway - you have coerce the linker ld into using directory names that match what is on the problem server, even if they are not real on the compile server
Here is one way:
Library names are often symlinks. Like /usr/lib/libc.so is usually a symlink that points to the current version of libc, like maybe libc.so.4.2.1.
You need to trick the linker into using names it can find on the other box. This means two separate compiles with two makefiles, one the old way, one the new way to get around this nonsense for the problem machine. You already know the old way.
Those names are beyond absurdly long, so here is an example using sane paths.
Let's say you compile on machine A. And link to libfunctor.so which is really:
Code:
/usr/path/to/libc/libfunctor.so.1234
# where it is a symlink
/usr/path/to/libc/libfunctor.so -> /usr/path/to/libc/libfunctor.so.1234
Now we know that
Code:
/usr/path/to
does not exist on one machine. So, on the compile machine we create a dummy directory that just has some symlinks in it.
We also know that on the problem machine the path to a libfunctor library we can use is
/opt/foo/gargle/libfunctor.so.1234 (HAS TO BE the SAME version as on the compile box).
This does not exist yet on the compile box. So. On the compile box we are going one make one via a symlink:
---------- Post updated at 01:11 AM ---------- Previous update was at 12:35 AM ----------
ldd -r DDQueryEnv.so.1 on the production server for both on Machine A's and,Machine B's are using the same
libfunctor2312d10g.so => /u01/apps/WatchMark/FlexPM/R401BED2G1/pm/lib/ln/sunw/libfunctor2312d10g.so
I know this is confusing. Giving you an example did not work. These are your requirements:
(try requirement 1a first)
1. All machines need to have exactly the pathnames to libraries
1a: Or all binaries have to know how to find the libraries
2. The actual names you set up have to exist everywhere.
You achieve 1a a single way:
LD_LIBRARY_PATH variable that shows how to find the library you want. This has to be in the environment variable set up for any user that runs the code: .profile, .bashrc, etc.
Example LD_LIBRARY_PATH
export LD_LIBRARY_PATH=/path/to/library:${LD_LIBRARY_PATH}
"/path/to/library" is an example do not use it.
I can not know which if that jumble of output for libfunctorxxxxxx is where the correct library is. I AM GUESSING.
You will select the path that exists on the machine the process runs on
if
You do this on all 3 machines. You validate this by setting LD_LIBRARY_PATH, and executing the command
Code:
ldd example_program_name
where example_program_name is the name of your compiled code file
Keep twiddling the LD_LIBRARY_PATH until all libraries show in the ldd output.
You achieve #1 two possible ways
Way #1. Add symbolic links as paths on the production box to match development
-- this requires no change in compilation
Way #2: Add symbolic links (extra set of paths to libraries) on development, AND
change the link statement to follow the new symbolic path.
-- requires that you change compilation -- you have two make files
libaio.so.1 => /usr/lib/libaio.so.1
libkstat.so.1 => /usr/lib/libkstat.so.1
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
librt.so.1 => /usr/lib/librt.so.1
libthread2412d10g.so => /u01/apps/WatchMark/FlexPM/R39PSLBLD1/pm/lib/ln/sunw/libthread2412d10g.so
libitc2312d10g.so => /u01/apps/WatchMark/FlexPM/R39PSLBLD1/pm/lib/ln/sunw/libitc2312d10g.so
libfunctor2312d10g.so => /u01/apps/WatchMark/FlexPM/R39PSLBLD1/pm/lib/ln/sunw/libfunctor2312d10g.so
libfunctor_list2312d10g.so => /u01/apps/WatchMark/FlexPM/R39PSLBLD1/pm/lib/ln/sunw/libfunctor_list2312d10g.so
libfunctor_map2312d10g.so => /u01/apps/WatchMark/FlexPM/R39PSLBLD1/pm/lib/ln/sunw/libfunctor_map2312d10g.so
libpointer2512d10g.so => /u01/apps/WatchMark/FlexPM/R39PSLBLD1/pm/lib/ln/sunw/libpointer2512d10g.so
libsync2412d10g.so => /u01/apps/WatchMark/FlexPM/R39PSLBLD1/pm/lib/ln/sunw/libsync2412d10g.so
libthrexcept2312d10g.so => /u01/apps/WatchMark/FlexPM/R39PSLBLD1/pm/lib/ln/sunw/libthrexcept2312d10g.so
libtrace2312d10g.so => /u01/apps/WatchMark/FlexPM/R39PSLBLD1/pm/lib/ln/sunw/libtrace2312d10g.so
libstd4112d10g.so => /u01/apps/WatchMark/FlexPM/R39PSLBLD1/pm/lib/ln/sunw/libstd4112d10g.so
libtls71012d10g.so => /u01/apps/WatchMark/FlexPM/R39PSLBLD1/pm/lib/ln/sunw/libtls71012d10g.so
libdbt6312d10g.so => /u01/apps/WatchMark/FlexPM/R39PSLBLD1/pm/lib/ln/sunw/libdbt6312d10g.so
libexpat.so => /u01/apps/WatchMark/FlexPM/R39PSLBLD1/pm/lib/tp/libexpat.so
libWmEncoding.so => /u01/apps/WatchMark/FlexPM/R39PSLBLD1/pm/lib/wm/libWmEncoding.so
libc.so.1 => /usr/lib/libc.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libmd.so.1 => /usr/lib/libmd.so.1
libscf.so.1 => /usr/lib/libscf.so.1
libpthread.so.1 => /usr/lib/libpthread.so.1
libdoor.so.1 => /usr/lib/libdoor.so.1
libuutil.so.1 => /usr/lib/libuutil.so.1
libgen.so.1 => /usr/lib/libgen.so.1
libm.so.2 => /usr/lib/libm.so.2
/lib/libm/libm_hwcap1.so.2
/platform/sun4v/lib/libc_psr.so.1
/platform/sun4v/lib/libmd_psr.so.1
The .so files could able to link the binaries of same version
But the application when started with some command on command line of C is not initiated
Any solution to the problem is helpful and appreciable.Thanks in advance.
The .so files are taking files from there respective workspaces on same server(R39PSLBLD1,R401BED2G1 these two are diffrent workspaces for code BUild on Machine B, Machine A respectively)
Thanks,
Revathi R
---------- Post updated at 08:33 AM ---------- Previous update was at 07:43 AM ----------
on The Machine A when i ve run the command
#/net/rtp-netapp1/vol/build/nwwls/devspace/thirdparty/SunOS/5.8/Studio8rev2/SUNWspro/bin/fpversion
A SPARC-based CPU is available.
Kernel says CPU's clock rate is 450.0 MHz.
Kernel says main memory's clock rate is 112.5 MHz.
Sun-4 floating-point controller version 0 found.
An UltraSPARC chip is available.
Use "-xtarget=ultra2 -xcache=16/32/1:4096/64/1" code-generation option.
Hostid = 0x80F00203.
On Machine B
/opt/SUNWspro/bin/fpversion
A SPARC-based CPU is available.
Kernel says CPU's clock rate is 2847.9 MHz.
Sun-4 floating-point controller version 0 found.
An UltraSPARC chip is available.
Use "-xtarget=generic -xcache=generic" code-generation option.
Hostid = 0x85D6F7A6.
but any way i am setting in "-xtarget=ultra" in Makefile will it be a problem
Any solution to the problem is helpful and appreciable.Thanks in advance.
Seems as if this is more complex than just a machine architecture issue. But there's a simple test you can do quickly.
Offhand, I'd think the code compiled with "xtarget=ultra2" should work fine on a SPARC T4 machine. Can you compile a simple "Hello world" binary on the Ultra 2 box with that "xtarget=ultra2" or even just the simple "-fast" option and see how it runs on the SPARC T4 servers?
If that doesn't work, try "xtarget=generic" on the Ultra 2 server.
And FWIW, the "xtarget" option has to come after the "-fast" on the command line. Basically, when you use "-fast" and a bunch of other options to compile, always put "-fast" first because if you don't it will override a lot of other command line options.
rsync --delay-updates -F --compress --archive --rsh='/usr/bin/ssh -t -a -x' /web/admin/Transfer/data/ user1@destserver1:/tmp/testf
rsync version on sender server is:3.0.9
rsync version on sender server is:3.0.6
Linux sourceserver1 3.10.0-693.17.1.el7.x86_64 #1 SMP Sun Jan 14 10:36:03 EST... (1 Reply)
Hi all,
currently I'm facing a issue in linking a .so file.
In my build machine, I've libcrypto.so.6 and there is a softlink as libcrypto.so.
In my make file I'm trying to link to the lib using -L -lcrypto and it is success and created my test.exe.
When I copy this test.exe to other... (4 Replies)
Hi,
Below is output of lslpp command.
bash-3.00# lslpp -L | grep xlC
xlC.aix50.rte 11.1.0.1 C F XL C/C++ Runtime for AIX 5.3
xlC.cpp 9.0.0.0 C F C for AIX Preprocessor
xlC.msg.en_US.cpp 9.0.0.0 C F C for AIX... (2 Replies)
Hi,
I'm new, here, and I'm searching for a simple solution for a simple problem.
I'm working on RedHat 4.4.6-4 through a CentOS Virtual Machine and due to some reasons I must compile my C++ codes with these two different g++ versions: 4.4.6 and 4.2.2.
The fact is that I should be able to... (4 Replies)
:confused: I installed latest version of java ( jre 1.6) on Solaris Machine ......when I run java -version as root, shows the latest version but when I run java -version as normal user, shows the old / previous version
What should I do to fix this ...should show the latest version... (3 Replies)
Hi all.
I have a simple question.
There's a way to install under AIX system (5.3) two different compiler version, i.e. ibm xlf fortran 11 and 12?
Seems that smitty doesn't allows user to change the default installation path; it only allows you to save the replaced files of the superseded... (1 Reply)
Command to get the Compiler version(xlc/gcc) from the binary on AIX platform.
I m searching for the Command, to get the Compiler(xlc/gcc) used to build the binary on AIX.
I got two commands used on Linux Platform:
- readelf -a <lib> | grep comment
- hexdump -C -s 0x49e7b -n 1812 <lib>
... (1 Reply)
I want to use calls from the X Keyboard Extension, but get "library version mismatch" error.
First one is XkbLibraryVersion(..). This one already returns false.
Then I call XkbOpenDisplay(...) which does not return a valid display; return value is XkbOD_NonXkbServer. If I open the display with... (0 Replies)
12-12-2012
