Building 64bit shared library on Solaris 10

I'm trying to port a Java application that depends on BerkeleyDB from GNU/Linux to Solaris 10. The GNU/Linux version was just recently rebuilt against Sun Java 6. The 64bit version of the JVM for the AMD Opteron processor. It produced a 64bit shared library. All is well in GNU/Linux land.
I try building BerkeleyDB on Solaris following the instructions in the documentation and it produces a 32bit shared library. So when the application starts up and tells the JVM to run in 64bit server mode it complains it cannot load a 32bit shared library. So my question is how do I force the build system to build a 64bit shared library in Solaris 10?
I'm using the Sun Studio 11 compiler for building BDB. I'm also doing this on a T1000 so any T1000 specific flags would be appreciated.

Hi,
I am not familiar with your particular environment. The general method for building a 64 bit Berkeley DB library on Solaris is to pass the "-xarch=v9a" flag to the configure command.
I hope this helps.
- Alex Gorrod

Similar Messages

How to build a shared library (dll) of a VI to be called by VC++

hi All,
How should I build a shared library ( dll ) using LabVIEW so that the desired output from LabVIEW can be returned to the main program that runs in VC++ ?
I'm currently working in a project that uses the PXI 1042 & DMM, AWG, FGEN, SCOPE, RFSG, RFSA etc.
The VC++ programmers dont want the LabVIEW front-end to be visible when called into VC++, in the sense they don't want LV to be another front-end, as the entire software is designed using VC++. It is enough if I simply pass the final values of measurement to them for display purpose.
So, they've asked me if it is possible in LabVIEW to provide the VIs as dlls instead of exes.
Since I've seen the feasibility of building a EXE or a DLL in LV, I've replied positively to them.
In another of my project, I'm using dlls built in VC++ for hardware drive interaction parts in my LabVIEW project.
Likewise, what are the methodologies that I should follow when building a Dll in LV ?
I tried with a simple VI, wherein it returns a value of addtion of 2 elements & I passed it thro' the connector pane correctly.
When I called the same dll in LV itself & configured it correctly by specifying the correct return type & I/O, then also it did not run properly.
I could not understand what was going.
So experts pls help me out by some simple examples or related links.
Regards & Thanks,
Partha.
- Partha
LabVIEW - Wires that catch bugs!

Here you can find Application Notes and examples:
http://zone.ni.com/devzone/devzone.nsf/webcategories/98D192CDCCDA21EE86256AB7006BECAF
Hope this helps!

Using V9 C++ parser within shared library (Solaris)

I am trying to use the latest C++ version of XML parser within a shared library on Solaris (v8) but I am having a problem with an unresolved symbol when the shared library is loaded.
../bin/Release/xxsd: fatal: relocation error: file /space/xxs/bin/Release/libxxtOracle.so: symbol __0fJXMLParserHxmlinitPUcPFPvPCUcUi_vPvP6IxmlsaxcbTDTB: referenced symbol not found
Compiler is Forte V6.
We currently successfully use the previous version of the parser on Solaris (oraxml8) with same build settings within our application.
I am able to build and run the sample demo successfully.
Any suggestions as to what the problem is and how to get round it?.
Mike

All works fine!...
$ mkdir /tmp/xxx
$ cat > dllfile.c
$ cat > dlluser.c
$ gcc -fPIC -c dllfile.c
$ gcc -shared -W1,-soname,libdllfile.so.1 -o libdllfile.so dllfile.o
$ gcc -o prog dlluser.c -ldl
$ ls -l
total 56
-rw-r--r-- 1 xxxxxx users 80 Апр 8 17:04 dllfile.c
-rw-r--r-- 1 xxxxxx users 908 Апр 8 17:15 dllfile.o
-rw-r--r-- 1 xxxxxx users 368 Апр 8 17:03 dlluser.c
-rwxr-xr-x 1 xxxxxx users 5260 Апр 8 17:15 libdllfile.so
-rwxr-xr-x 1 xxxxxx users 6412 Апр 8 17:16 prog
$
$ file *
dllfile.c:     c program text
dllfile.o:     ELF 32-bit MSB relocatable SPARC Version 1
dlluser.c:     c program text
libdllfile.so:     ELF 32-bit MSB dynamic lib SPARC Version 1, dynamically linked, not stripped
prog:          ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped
$
$ su
Password:
# mkdir -p /root/shared_library/
# cp libdllfile.so /root/shared_library/
# exit
$ ./prog
With the changes
library loaded
Inside function
$

Building shared library

I am a new user to Mac and I am trying to build a shared library using gcc. However, I am getting errors when creating a execuatble.
My system info. is:
[email protected] <810> gcc --version
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5363)
[email protected] <811> uname -a
Darwin foxtrot.vni.com 8.8.1 Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PD
T 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386
Here is a small example for the problem.
========= kk.h ===========
#include<stdio.h>
#include<math.h>
void sub();
=========== sub.c =========
#include "kk.h"
void sub() {
printf("sub = %g\n", fabs(-2.0));
======== main.c ========
#include "kk.h"
main() {
sub();
=====================
[email protected] <792> gcc -c -fPIC sub.c
[email protected] <793> gcc -o libkk.so -dynamic -r sub.o
[email protected] <794> gcc main.c libkk.so -lm
/usr/bin/ld: multiple definitions of symbol _NXArgc
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../crt1.o definition of _NXArgc in section (_DATA,_data)
libkk.so definition of _NXArgc in section (_DATA,_data)
/usr/bin/ld: multiple definitions of symbol _NXArgv
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../crt1.o definition of _NXArgv in section (_DATA,_data)
libkk.so definition of _NXArgv in section (_DATA,_data)
/usr/bin/ld: multiple definitions of symbol _progname
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../crt1.o definition of _progname in section (_DATA,_data)
libkk.so definition of _progname in section (_DATA,_data)
/usr/bin/ld: multiple definitions of symbol _environ
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../crt1.o definition of _environ in section (_DATA,_data)
libkk.so definition of _environ in section (_DATA,_data)
/usr/bin/ld: multiple definitions of symbol start
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../crt1.o definition of start in section (_TEXT,_text)
libkk.so definition of start in section (_TEXT,_text)
collect2: ld returned 1 exit status
Thank you.

Hi Gschwert,
our developers told me that for X-Code Version 4 you need an additional download. Then, it should also work with Version 4. Here is what they said:
It turned out that Shared Libraries compile fine with XCode 4, it's just that the command line tools that we need for compilation are now an optional download.
From https://developer.apple.com/xcode/
"Xcode includes a new "Downloads" preference pane to install optional components such as command line tools, and previous iOS Simulators."
So, this is not well documented we will handle that and let make a correction as soon as possible.
Have a nice day,
Abduelkerim
Sales
NI Germany

Loading shared library failed: Reports fatal: libgcc_s.so.1 : open failed

Hi,
I am developing a shared library in solaris. While loading the shared library it reports "ld.so.1: tn-tipc-config-bin: fatal: libgcc_s.so.1: open failed: No such file or directory". I noticed that libgcc_so.1 is available at /usr/sfw/lib. But this library is missing in some solaris build/install configuration. I want my library to loaded in any solaris system. So I want to reduce dependency over libgcc_s.so.1. By looking at the objdump of my shared library, I found that references to
__register_frame_info and __deregister_frame_info which are provided by libgcc_s.so.1. Looks like these references are added by gccfss compiler since I dont call these functions in my code. Please suggest a method to remove reference for these functions.
Thanks
Shankar

If you don't want to bring libraries your app depends on with you, the only choice you have is linking statically. It is a very bad idea to manually "detach" compiler-supplied library from the application unless you know exactly what you are doing. Even if your library does not call anything directly, initialization routines inserted by compiler may need routines from that library (just as an example).

Exceptions not caught in shared library when compiled under Sun Studio 9

I realize it's a fairly old version of Sun Studio, however if at all possibly we'd like to avoid updating to the latest.
Sun Studio 9, version reports
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/cc": Sun C 5.6 2004/07/15
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/CC": Sun C++ 5.6 2004/07/15
uname -a
SunOS sunblade 5.9 Generic_118558-27 sun4u sparc SUNW,Sun-Blade-100
The problem is within our shared library a function calls another method within a try/catch block. This method then sometimes throws an exception which does have a matching catch block. On all other systems (Windows, AIX, HP-UX, Linux) the code works, the exception is caught and handled. On Solaris with Sun Studio 9 though, the exception is ignored and instead triggers an abort and core dump.
Stack Trace:
ffffffff7daa871c lwpkill (6, 0, ffffffff7fffd9c0, ffffffff7d3064d4, 2, ffffffff7fffd9ec) + 8
ffffffff7da3e4b8 abort (ffffffff7d40dac8, ffffffff7d40cc38, ffffffff7d411e78, 10604c, 2, ffffffff7d40dac8) + 100
ffffffff7d3064d4 __1cH__CimplRdefault_terminate6F_v_ (ffffffff7d40dac8, ffffffff7d40cc38, ffffffff7d411e78, 10604c, 104e40, ffffffff7d3064d0) + 4
ffffffff7d3062b4 __1cH__CimplMex_terminate6F_v_ (ffffffff7d40de40, 0, 0, ffffffff7d40de40, ffffffff7d40c978, 1) + 24
ffffffff7d306f04 exthrow_body (ffffffff7d40de40, 0, 0, 105af4, 52, ffffffff7d40e2e8) + 84
ffffffff7d306e58 __1cG__CrunIex_throw6Fpvpkn0AQstatic_type_info_pF1_v_v_ (ffffffff7d40dec8, ffffffff7f0dea78, ffffffff7ecb6b28, ffffffff7d40de40, 0, ffffffff7d40de40) + 3c
ffffffff7ecb6d90 __1cLIGExceptionFThrow6FnQenumIGErrorCodes_pkcxxp2x_v_ (fffffffffffff3e3, 0, 0, 0, ffffffff7f1187da, a0) + 80
ffffffff7ecb6e78 __1cOThrowException6FnQenumIGErrorCodes_pkcxxp1x_v_ (fffffffffffff3e3, 0, 0, 0, ffffffff7f1187da, a0) + 30
ffffffff7f083304 __1cSIGRasterProcessingNVerifyPalette6FpnMIGRasterPage_nTenumIGContrastModes__v_ (1001f3c10, 0, 0, 0, 0, 0) + b4
ffffffff7f083760 __1cSIGRasterProcessingOInvertContrast6FpnMIGRasterPage_nTenumIGContrastModes_nTenumIGColorChannels_pnPtagAT_RECTANGLE__v_ (1001f3c10, 0, 0, ffffffff7fffe1a8, 0, 0) + 20
ffffffff7f039a2c iIG_IP_contrast_invert (1001f3c10, 100162b10, 0, 0, 0, 0) + 104
ffffffff7f039ba0 iIG_IP_contrast_invert_masked (1001f3c10, 100162b10, 0, 0, 0, 0) + 80
000000010000b4e0 ipcontrast_invert_notify (10014d000, 10014d, 0, 100000, 100162000, 100162) + 48
Try/catch block:
     try
          <Triggering function>
     catch(const IGException& ige)
          <Handling Code>
The code which throws the exception is a static method of IGException which has a basic throw line:
     throw IGException(...);
Source code is compiled with the following flags, none of which I could find any info to suggest affect this:
CC -c -Xt -xCC -misalign -xarch=v9 -O
Linking of the shared object is then done via the following, again nothing obvious that could cause issues. mapfile is an empty file.
ld -o <outputfilename> -G -z textoff -M mapfile -z noversion -64 -h <outputfilename> <object files> -L/opt/SUNWspro/lib/v9 -lCrun -lX11 -lc -lm
I did read somewhere mentioning to make sure to use RTLD_GLOBAL if using dlopen on the .so, but the test app is using ld to link the library.
Does anyone have any ideas why with the Sun Studio 9 compiler these exceptions are not being caught? Based on the fact they are caught on all other compilers, i'm guessing this issue is with the compiler.
Also, as a test it seems that if the shared object is not built as a 64-bit object, then everything works. The issue only seems to occur when it is a 64-bit object. Likely an issue with the 64-bit compiling?
Edited by: 837682 on Feb 17, 2011 9:23 AM

As the other poster pointed out, you need to link the shared library using CC, not ld. I should have noticed that error in the original post.
Try using CC instead of ld in your link command. The CC command causes additional files to be linked into the shared library that are required for proper operation, and particularly for exception handling. I think that is the actual source of your problem.
You should not use -L options that point into the compiler installation area, and when you use CC to link, you don't need to.
I'm surprised that you seem to have a copy of libCrun.so.1 in the compiler installation area -- that should not be the case. The the only versions of libCrun should be static libraries libCrun.a. You almost never want to link with a static version of a system library, and absolutely never when building a shared library. The file /opt/SUNWspro/lib/libCrun.so.1 ought to be a symbolic link pointing to /usr/lib/libCrun.so.1, but if that were the case, the version command would have the same output.
By any chance, did you install your compiler by copying it from another installation? If you do that, you need to use tar, not cp, to ensure that symbolic links are preserved.

Cannot load shared library from Java on AIX

I am working on a 64-bit AIX5.2 machine. I created a hello world program using JNI. When I run it, System.loadLibrary() does not find my shared library. After looking into it for several hours, I realized it might be something to do with my 32 bit mode build. The reason I am building as 32 bit is because I thought it would work on both 32 and 64 bit platforms.
This is how I compile my C++ file and build the shared library:
xlC_r -brtl -q32 -c -I"." -I"/usr/java5_64/include" -c NativeHello.cpp -o NativeHello.o
xlC_r -brtl -G -q32 -o libNativeHello.so NativeHello.o
When I run my HelloWorld java program, it gives this error:
java.lang.UnsatisfiedLinkError: NativeHello (A file or directory in the path name does not exist.)
However, when I change the build lines to use -q64 instead of -q32, my hello world program works just fine.
So I am suspecting that Java is not expecting my shared library that was compiled as 32 bit.
How can I correct this problem? Is there any flag that I might be missing? Or do I need to build separate libraries for 32 bit and 64 bit environment?
Thanks for your help in advance.

This is not a java problem.
It is a VM problem.
So for the VM (vendor and version) that you are using it requires certain things.
It might be that the VM doesn't load 32 at all. Or that you have to do something different when you compile it.
A forum that is specific to your VM might be more productive (this site tends to be strongly solaris/linux/windows.)

How to make the symbol to be resolved within the shared library ?

I have two definitions of a symbol, one is in the main code, the other in a shared library. I want the symbol to be resolved within the shared library if it needed in the shared library.
From the 'C++ User�s Guide', use the option '-Bsymbolic' to build the shared library is a choice. But it also said 'Never use -Bsymbolic with programs containing C++ code, use linker map files instead. So I have to try to use the map file, but I did not get more useful information from 'Linker and Libraries Guide'.
I want to know what should be included in the map file and how to generate the map file?
Additionally, from the 'Linker and Libraries Guide', the 'Direct Binding' also could resolve this problem. And I tried to build the shared library by the '-B direct' option, it works.
Could anybody tell me what's the difference between the '-Bsymbolic' and '-B direct'?
Any comments are appreciated.

You didn't provide fun.h, and you didn't show all the commands that you must have used -- there are no commands that compile the source code into .o files. So I can't tell why the -xldscope option didn't work for you.
Problems and errors that I see in your example:
Functions func and swap are referenced from C code, but swap and one of the func functions are compiled by the C++ compiler and will get mangled names. If you compile a function with the C++ compiler that is to be called from C code, you need to declare the function as extern "C". But the extern "C" in a shared header needs to be guarded by +#ifdef __cplusplus+, since a C compiler won't understand the declaration.
When you build a shared library, you must explicitly list the libraries it depends on, since no dependencies are created by default. For a C++ library, you need at least -lCrun -lc in that order. Otherwise, in a real-world program you can have program failures due to incorrect library initialization order. To be sure you have listed all needed libraries, use the -zdefs option, which causes the linker to complain about missing definitions.
To be sure the shared library is picked up at run time, provide a RUNPATH via the -R option when you build the executable.
The -xldscope option must appear on compile commands for the files where you want it to take effect. It has no effect on a link command, because the option affects how code is generated.
Here is my rewrite:
% cat fun.h
#ifdef __cplusplus
extern "C"
#endif
void func();
#ifdef __cplusplus
extern "C"
#endif
void swap();
% cat fun.c
#include <stdio.h>
#include "fun.h"
extern "C" void func()
    printf("func in the shared lib\n");
extern "C" void swap()
    func();
% cat fun_in.c
#include <stdio.h>
#include "fun.h"
void func()
    printf("func in the main code\n");
% cat main.c
#include <stdio.h>
#include "fun.h"
int main()
    func();
    printf("invoke the swap:\n");
    swap();
% CC -G -xldscope=symbolic fun.c -Kpic -o liboutside.so -lCrun -lc -zdefs
% cc -o run main.c fun_in.c -L. -loutside -R .
% ./run
func in the main code
invoke the swap:
func in the shared libAs you can see, it works as advertised.
Please note that the -xldscope option affects all functions in the module. If you need more fine-grained control, you must add declarations to the source code, or use a mapfile instead of -xldscope .

How to create a c++ shared library (.so) for linux real time (for myRio) with Eclipse to use in LabView?

I tried already these Tutorials and Advices but I didn't find a solution:
- http://www.ni.com/tutorial/14625/en/
- http://www.ni.com/tutorial/14690/en/
- http://forums.ni.com/t5/LabVIEW/Shared-Library-on-myrio-Linux-Real-time-system/m-p/2842540/
- http://forums.ni.com/t5/LabVIEW/How-to-create-shared-library-for-linux-real-time-target-in/m-p/28218...
- and some more
I want use c++ codes on linux real time. For testing reasons I want to have a function that adds 2 values and gives the result.
I've done these steps:
1. writing a c++ file in Eclipse (see screensot 2)
2. building a shared library (.so) from my c++ project in Eclipse (with Cross GCC)
3. putting this file on myRio (path: /usr/local/lib/)
4. creating a VI that calls this library from Labview with a "Call Library Function Node" (see screenshot3)
5. Setting the properties for the "Call Library Function Node" (see screenshots 4-7)
After I run this VI i get this error message: LabVIEW: (Hex 0x627) The function name for the ... node cannot be found in the library. To correct this error, right-click the Call Library Function Node and select Configure from the shortcut menu. Then choose the correct function name. (see screenshot1)
I've tried a lot things to solve this problem but I couldn't find a solution. Would be very happy if anyone can help me. I guess that I have to edit my c++ code to export my function (symbol). But I have no idea how to make it. I also tried it with a dll file in the same folder but it didn't help.
Perhaps someone can send an example which works on myRIO.
Thanks!
screenshot1
screenshot2
screenshot3
screenshot4
screenshot5
screenshot6
screenshot7

can see it in the screenshot8 there is a function called "_Z8AddierenddPd" instead of "Addieren". I copied this name to Labview (see screenshot9) and it worked.
I'm sure that there is a way to compile the shared folder with gcc without decorations (mangling). But I don't know how. If someone has a recommendation I would be very glad!
Prepend each function declaration that you want to be available without name decoration with
extern "C" <your function declaration>
Or if you have multiple functions you want to export you can in the header file where you declare your functions simply use:
#ifdef __cplusplus
extern "C" {
#endif
<all your function declarations>
#ifdef __cplusplus
#endif
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Creating shared library of native method implementation using gcc

Hi
I am using Dev-C++ IDE for writing and compiling C Programs. It supports gcc.
I have to build a shared library of a native method implementation using gcc compiler.
In JNI tutorial build script is given for VC++ which is as follows
cl -Ic:\java\include -Ic:\java\include\win32
-LD HelloWorldImp.c -Fehello.dll
Similarly I wanted build script for gcc compiler.
Thanks
Shailesh

Here is an example of building a library from one module with CygWin's gcc:
# Must set JAVA_HOME and LIBRARY_MODULE before
gcc -mno-cygwin -D__int64="long long" -I $JAVA_HOME/include/win32 -I $JAVA_HOME/include -shared -Wl,--kill-at -o $LIBRARY_MODULE.dll $LIBRARY_MODULE.c

Problem with JNI in a Solaris shared library

Hi,
I have a problem.
I have used JNI in my .dll on Windows & .so on Solaris . I have also used the same JNI code in a .exe on Windows & an executable on Solaris. 3 out of the above 4 combinations work & 1 doesen't. When I use JNI from a .so on Solaris 8(with/without the J2SE recommended patch), the JVM seems to have some exception & dumps core when I invoke CreateJavaVM(). See Below - I've included the output on the screen & the output from 'pstack core' :
Unexpected Signal : 11 occurred at PC=0xFED29D44
Function=[Unknown. Nearest: JVM_GetMethodIxExceptionIndexes+0x1994]
Library=/usr/java/jre/lib/sparc/libjvm.so
Current Java thread:
Dynamic libraries:
0x10000 SblSim
0xff280000 /usr/lib/libnsl.so.1
0xfec00000 /usr/java/jre/lib/sparc/libjvm.so
0xff370000 /usr/lib/libpthread.so.1
0xff350000 /usr/lib/librt.so.1
0xff260000 /usr/lib/libsocket.so.1
0xff390000 /usr/lib/libdl.so.1
0xff230000 /usr/lib/libCrun.so.1
0xff200000 /usr/lib/libm.so.1
0xff340000 /usr/lib/libw.so.1
0xff1b0000 /usr/lib/libthread.so.1
0xff080000 /usr/lib/libc.so.1
0xff180000 /usr/lib/libmp.so.2
0xff160000 /usr/lib/libaio.so.1
0xff1f0000 /usr/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1
0xfebd0000 /usr/j2se/jre/lib/sparc/native_threads/libhpi.so
0xfeba0000 /usr/j2se/jre/lib/sparc/libverify.so
0xfeb60000 /usr/j2se/jre/lib/sparc/libjava.so
0xfeb40000 /usr/j2se/jre/lib/sparc/libzip.so
0xfe920000 /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2
0xf1400000 ./libaicd.so
0xfc480000 ./libmttoolkit.so
0xfdfe0000 ./libmttlogger.so
0xfdfb0000 /usr/j2se/jre/lib/sparc/libnet.so
Local Time = Tue Nov 12 09:51:37 2002
Elapsed Time = 29
# HotSpot Virtual Machine Error : 11
# Error ID : 4F530E43505002D5 01
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
# Java VM: Java HotSpot(TM) Client VM (1.4.0_01-b03 mixed mode)
# An error report file has been saved as hs_err_pid3120.log.
# Please refer to the file for further information.
Abort(coredump)
Below is the output of 'pstack core'
$ pstack core
core 'core' of 3120: SblSim libaicd.so 127.0.0.1 9999
----------------- lwp# 1 / thread# 1 --------------------
ff1c9764 __sigprocmask (ff1cbf60, 0, 0, 565f8, ff1de000, 0) + 8
ff1be110 _sigon   (565f8, ff1e5930, 6, ffbedba4, 565f8, 6) + d0
ff1c1150 thrpkill (0, 1, 6, ff1de000, 1, ff140450) + f8
ff0cb900 raise (6, 0, 0, ffffffff, ff1403bc, 4) + 40
ff0b58ec abort (ff13c000, ffbedcf8, 0, fffffff8, 4, ffbedd19) + 100
feee2700 ???????? (1, fef98e50, ffbedd98, 0, feffc130, feee1258)
feee12c8 ???????? (60650, b, fed29d44, ffbeeab8, b, 0)
fede77c0 ???????? (fed29d44, ffbeeab8, ffbee800, fed29d44, fed03744, 0)
ff1cb824 __sighndlr (b, ffbeeab8, ffbee800, fede6f38, 5669c, 5668c) + c
ff1c84d8 sigacthandler (b, 565f8, 0, 0, 0, ff1de000) + 708
--- called from signal handler with signal 11 (SIGSEGV) ---
fed29d44 ???????? (0, 60650, 0, 0, 0, 0)
fed2d7d4 ???????? (606e4, 0, 0, ffbeed00, 0, 0)
f172e818 __1cHJNIEnv_JNewObject6MpnH_jclass_pnK_jmethodID_E_pnI_jobject__ (606e4, 0, 0, ffbeed70, 39, 107f90) + 70
f172dbf8 __1cGJEvent2t5B6M_v_ (107f60, f1a877f4, db088, ff0c1c44, 107f48, 0) + 80
f16f2864 __1cGCEvent2t6Mii_v_ (107f60, 0, 1, ff13c000, 107f48, 0) + 7c
f16e62e8 __1cVCISCHelperThreadMutex2t6M_v_ (107f50, 0, 560ac, 30f68, fefe4000, 0) + c0
f16ddc34 __1cLinitGlobals6F_v_ (0, 1, 19a, f1a198ec, f1a198ec, 0) + 5c
f16de4e4 CreateISCDriverInstance (0, 5cc40, 0, 57608, 565e8, 0) + 554
00034f08 __1cJRunSblSim6F_v_ (1, ffbef322, ffbef32c, ff13fc70, 100d4, 0) + 320
00035588 main (4, ffbef1dc, ffbef1f0, 55c00, 0, 0) + 1a8
00018460 _start   (0, 0, 0, 0, 0, 0) + 108
----------------- lwp# 2 / thread# 2 --------------------
ff11e958 _signotifywait (ff1de000, 59, 0, 0, 0, 0) + 8
ff1c2030 thr_yield (0, 0, 0, 0, 0, 0) + 8c
----------------- lwp# 3 --------------------------------
ff1c9774 private___lwp_cond_wait (ff075d70, ff1ded9c, ff1de000, 0, 0, 4) + 8
ff11c554 doorreturn (ff075cb0, ff1ba740, 0, 0, 0, 0) + 68
----------------- lwp# 4 / thread# 4 --------------------
ff11efbc ___lwp_cond_wait (60048, 60030, fe901ad0, 0, 0, fe901ac8) + 8
ff116610 lwpcond_timedwait (1cb8c88, 3dd1157a, fe901ba4, 60030, 60048, 1) + 98
fecfc7d8 ???????? (0, 1, 0, 581b8, feffa26c, 0)
fecfcfd4 ???????? (ff00a15c, feffa4b8, feffa4b4, 0, 0, 0)
fecfccc0 ???????? (d3980, 0, 0, 0, 0, 0)
fecfcbd0 ???????? (d3980, ff1df688, 1, 1, ff1de000, 0)
ff1cb728 threadstart (d3980, 0, 0, 0, 0, 0) + 40
----------------- lwp# 5 --------------------------------
ff11c4fc doorreturn (4, ff1df688, ff1df6a0, 3, ff1de000, 1) + 10
ff1ba740 lwpstart (fea95d70, 0, 6000, ff075b74, 0, 0) + 18
ff1c2030 thr_yield (0, 0, 0, 0, 0, 0) + 8c
----------------- lwp# 6 / thread# 5 --------------------
ff11efbc ___lwp_cond_wait (d5720, d5708, 0, fed10a40, 0, 0) + 8
fed110d4 ???????? (d56c8, 0, 5000, 5210, d4d38, 4d24)
fed10824 ???????? (fdf8172c, 0, 0, d4d38, d4d38, 30dec8)
fed103b0 ???????? (d4dcc, fdf81824, 0, 0, 0, 0)
fa40cc94 ???????? (f2000380, b6, fdf818a4, ffffffff, 0, fdf817c0)
fa405da0 ???????? (f2000380, b6, fdf818a8, fa415444, 0, fdf81840)
fa405da0 ???????? (fdf81938, 0, 0, fa4157a4, 2f4210, fdf818d8)
fa400438 ???????? (fdf819c0, fdf81c08, a, f6050b68, fa40bc8c, fdf81b50)
fecfe2f8 ???????? (fdf81c00, fdf81a88, fdf81b48, d4d38, d4d38, fdf81a9c)
fed0ff90 ???????? (fefe4000, d5298, fdf81b3c, fdf81b38, fdf81b48, d4d38)
fed0fdf0 ???????? (fdf81c00, fdf81bfc, fdf81bf0, fdf81be8, fdf81be0, d4d38)
fed0fd78 ???????? (d4d38, d4d38, ac9a0, d5298, 2d4488, fed0fa60)
fed0fa88 ???????? (d4d38, 0, 0, 0, 0, 0)
fecfcbd0 ???????? (d4d38, ff1df688, 1, 1, ff1de000, 0)
ff1cb728 threadstart (d4d38, 0, 0, 0, 0, 0) + 40
----------------- lwp# 7 / thread# 6 --------------------
ff11efbc ___lwp_cond_wait (d7040, d7028, 0, 1, 0, 0) + 8
fed110d4 ???????? (d6fe8, 0, 5000, 5210, d6658, 4d24)
fed10824 ???????? (fa38169c, 0, 0, d6658, d6658, 30dec8)
fed103b0 ???????? (d66ec, fa38179c, 0, 0, 0, 0)
fa40cc94 ???????? (f2000490, b6, fa3817a0, fa414050, 0, fa381730)
fa405da0 ???????? (f2000478, b6, fa3818b4, fa415444, 0, fa3817d8)
fa405c4c ???????? (f2000478, b6, fa381934, fa415444, d6658, fa381858)
fa405c4c ???????? (fa381938, 0, 0, fa38197c, 2f4210, fa3818d8)
fa400438 ???????? (fa3819c0, fa381c08, a, f60520b8, fa40bc8c, fa381b50)
fecfe2f8 ???????? (fa381c00, fa381a88, fa381b48, d6658, d6658, fa381a9c)
fed0ff90 ???????? (fefe4000, d6bb8, fa381b3c, fa381b38, fa381b48, d6658)
fed0fdf0 ???????? (fa381c00, fa381bfc, fa381bf0, fa381be8, fa381be0, d6658)
fed0fd78 ???????? (d6658, d6658, ac9e0, d6bb8, 2d4488, fed0fa60)
fed0fa88 ???????? (d6658, 0, 0, 0, 0, 0)
fecfcbd0 ???????? (d6658, ff1df688, 1, 1, ff1de000, 0)
ff1cb728 threadstart (d6658, 0, 0, 0, 0, 0) + 40
----------------- lwp# 8 / thread# 7 --------------------
ff11d194 _poll    (0, 0, 0, fa281a28, ff13f1b4, fa281a28) + 8
ff1cb134 select (0, a, 0, ff1de000, fa281e14, 0) + 34
fed32afc ???????? (d8040, 0, a, 0, 0, 0)
fed328b4 ???????? (d8040, 0, 0, 0, 0, 0)
fecfcbd0 ???????? (d8040, ff1df688, 1, 1, ff1de000, 0)
ff1cb728 threadstart (d8040, 0, 0, 0, 0, 0) + 40
----------------- lwp# 9 / thread# 8 --------------------
ff11efbc ___lwp_cond_wait (5f998, 5f980, 2e7aa0, ff1de000, fa181e14, 0) + 8
fecfc634 ???????? (5f950, 0, 0, 0, feffa26c, 0)
fed3371c ???????? (3c00, 3f44, 0, 0, 0, 0)
fecfcbd0 ???????? (d81a8, ff1df688, 1, 1, ff1de000, 0)
ff1cb728 threadstart (d81a8, 0, 0, 0, 0, 0) + 40
----------------- lwp# 10 / thread# 9 --------------------
ff11f008 lwpsema_wait (f1f81e30, ff1de000, 0, f1f81d70, ff3e2628, 0) + c
ff1b94c0 _swtch   (f1f81d70, ffffffff, ff1de000, 5, 1000, 0) + 158
ff1bcc64 sema_wait (ff020fe0, ff1e98e4, 5000, 10000, 534d, 1) + bc
fed345c8 ???????? (0, 6, b, a, 1, 0)
fed34254 ???????? (ff002ae4, ff00a5a0, ff00a5d4, dab90, 2d4488, fed0fa60)
fed0fa88 ???????? (da630, 0, 0, 0, 0, 0)
fecfcbd0 ???????? (da630, ff1df688, 1, 1, ff1de000, 0)
ff1cb728 threadstart (da630, 0, 0, 0, 0, 0) + 40
----------------- lwp# 11 / thread# 10 --------------------
ff11efbc ___lwp_cond_wait (604e8, 604d0, 2e7aa0, feffa26c, 106c40, 0) + 8
fecfc88c ???????? (604a0, 0, 0, dbbd0, feffa26c, 0)
fed349ac ???????? (db670, db670, dbfd0, dbbd0, 2d4488, fed0fa60)
fed0fa88 ???????? (db670, 0, 0, 0, 0, 0)
fecfcbd0 ???????? (db670, ff1df688, 1, 1, ff1de000, 0)
ff1cb728 threadstart (db670, 0, 0, 0, 0, 0) + 40
-------------------------- thread# 3 --------------------
ff1bddbc reapwait (ff1e29e0, 20520, 0, ff1de000, 0, 0) + 38
ff1bdb14 _reaper (ff1dee30, ff1e4740, ff1e29e0, ff1dee08, 1, fe400000) + 38
ff1cb728 threadstart (0, 0, 0, 0, 0, 0) + 40

This is an update to the original message -
I have tried both HotSpot & Server JVMs but still see the
same behavior. I'm using 1.4 .
I'd like to provide more information to those who can help
me. I have a feeling there might be something wrong in my
CC options. Thus you will find below what my CC statement
looks like for one of the files in my project & for the
linking of the final shared library. I also have
provided the output of ldd on my shared library libaicd.so
& for comparison the output of ldd on libjvm.so as that
might provide some usefull information just incase
something looks suspecious & might ring a bell.
/opt/SUNWspro.cc6/bin/CC -c -KPIC -g -DDEBUG=DEBUG -
D_DEBUG -mt -DSOLARIS -DSTD_STREAM -
I/vob1/qwsrc/fw/include -I.-I/vob4/source/idl -
I/vob4/source/mttoolkit -I/vob4/source/mttoolkit/tools -
I/vob4/source/integrations/siebel/aicd -
I/vob4/source/include -I/vob1/qwsrc/fw/include -
I/vob4/source/source -I/vob4/source/mttoolkit -
I/vob1/external/platform_neutral/siebel/scapi/include -
I/external/sparc/Sun/jdk/1.3.1/include -
I/external/sparc/Sun/jdk/1.3.1/include/solaris -
I/vob4/source/idl -I/vob4/source/mttoolkit -
I/vob4/source/mttoolkit/tools -
I/vob4/source/mttoolkit/vnet -
I/vob4/source/mttoolkit/bool -DUNIX -
D_USE_MTTServerToolkit -D_JAVA_ WIAcceptTimeOut.cpp -
o /space/users/janak/buildoutput/sparc/debug/obj/integratio s/siebel/aicd/WIAcceptTimeOut.o
/opt/SUNWspro.cc6/bin/CC -G -
o /space/users/janak/buildoutput/sparc/debug/lib/fw/libaicd.so
/space/us
ers/janak/buildoutput/sparc/debug/obj/integrations/siebel/ai
cd/AgentService.o /space/users/janak/buildoutput/sparc/debug
/obj/integrations/siebel/aicd/AgentServiceCmds.o /space/user
s/janak/buildoutput/sparc/debug/obj/integrations/siebel/aicd
/AgentServiceEvents.o /space/users/janak/buildoutput/sparc/d
ebug/obj/integrations/siebel/aicd/AgentServiceICAReq.o /spac
e/users/janak/buildoutput/sparc/debug/obj/integrations/siebe
l/aicd/AgentServiceICEvents.o /space/users/janak/buildoutput
/sparc/debug/obj/integrations/siebel/aicd/AgentServiceUtilit
ies.o /space/users/janak/buildoutput/sparc/debug/obj/integra
tions/siebel/aicd/AvMc.o /space/users/janak/buildoutput/spar
c/debug/obj/integrations/siebel/aicd/InternationalStrings.o
/space/users/janak/buildoutput/sparc/debug/obj/integrations/
siebel/aicd/JEvent.o /space/users/janak/buildoutput/sparc/de
bug/obj/integrations/siebel/aicd/JMultipleEvents.o /space/us
ers/janak/buildoutput/sparc/debug/obj/integrations/siebel/ai
cd/JNIObject.o /space/users/janak/buildoutput/sparc/debug/ob
j/integrations/siebel/aicd/JObject.o /space/users/janak/buil
doutput/sparc/debug/obj/integrations/siebel/aicd/JSemaphore.
o /space/users/janak/buildoutput/sparc/debug/obj/integration
s/siebel/aicd/JWorkerThread.o /space/users/janak/buildoutput
/sparc/debug/obj/integrations/siebel/aicd/MultipleEvents.o /
space/users/janak/buildoutput/sparc/debug/obj/integrations/s
iebel/aicd/Param.o /space/users/janak/buildoutput/sparc/debu
g/obj/integrations/siebel/aicd/ParamQueue.o /space/users/jan
ak/buildoutput/sparc/debug/obj/integrations/siebel/aicd/RefC
ount.o /space/users/janak/buildoutput/sparc/debug/obj/integr
ations/siebel/aicd/SiebelDriver.o /space/users/janak/buildou
tput/sparc/debug/obj/integrations/siebel/aicd/SiebelEvent.o
/space/users/janak/buildoutput/sparc/debug/obj/integrations/
siebel/aicd/SiebelWorkItem.o /space/users/janak/buildoutput/
sparc/debug/obj/integrations/siebel/aicd/SingleEvent.o /spac
e/users/janak/buildoutput/sparc/debug/obj/integrations/siebe
l/aicd/SmartPtr.o /space/users/janak/buildoutput/sparc/debug
/obj/integrations/siebel/aicd/StdAfx.o /space/users/janak/bu
ildoutput/sparc/debug/obj/integrations/siebel/aicd/ThreadPoo
l.o /space/users/janak/buildoutput/sparc/debug/obj/integrati
ons/siebel/aicd/Utilities.o /space/users/janak/buildoutput/s
parc/debug/obj/integrations/siebel/aicd/WIAcceptTimeOut.o -
lnsl -lc -lCstd -
L/space/users/janak/buildoutput/sparc/debug/lib/cti -
lmttoolkit -
L/space/users/janak/buildoutput/sparc/debug/lib/fw -
lmttlogger -
L/space/users/janak/buildoutput/sparc/debug/lib/fw -
lqwlicmtt -
L/external/sparc/Sun/jdk/1.3.1/jre/lib/sparc/server -
Bdynamic -ljvm -mt -lpthread -lposix4
$ ldd /usr/j2se/jre/lib/sparc/libjvm.so
libCrun.so.1 => /usr/lib/libCrun.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libthread.so.1 => /usr/lib/libthread.so.1
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libm.so.1 => /usr/lib/libm.so.1
libw.so.1 => /usr/lib/libw.so.1
libc.so.1 => /usr/lib/libc.so.1
libmp.so.2 => /usr/lib/libmp.so.2
/usr/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1
$ ldd libaicd.so
libnsl.so.1 => /usr/lib/libnsl.so.1
libc.so.1 => /usr/lib/libc.so.1
libmttoolkit.so => ./libmttoolkit.so
libmttlogger.so => ./libmttlogger.so
libjvm.so => /usr/java/jre/lib/sparc/libjvm.so
libpthread.so.1 => /usr/lib/libpthread.so.1
librt.so.1 => /usr/lib/librt.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libCrun.so.1 => /usr/lib/libCrun.so.1
libthread.so.1 => /usr/lib/libthread.so.1
libsocket.so.1 => /usr/lib/libsocket.so.1
libm.so.1 => /usr/lib/libm.so.1
libaio.so.1 => /usr/lib/libaio.so.1
libw.so.1 => /usr/lib/libw.so.1
/usr/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1

How can I use a shared library made with the application builder?

Hi,
I am using LabVIEW 7.1 running on Slackware 10.1 (kernel 2.4.29) and I am trying to call a graph display from a C program that I use for debugging VME access from a VMIVME controler. So using the application builder I built the VI as a shared library (graph.vi -> graph.so) containing a function called "graph". In my main program the call to the dlopen fails with the error: "graph.so: undefined symbol: UninitLVClient". When I examin graph.so with nm I see that UninitLVClient and other LabVIEW functions are indeed undefined and using ldd shows that graph.so has dependencies only on libc.so.* and *linux*.so.* but not on LabVIEW related stuff. Those functions are defined in the liblv.so that's in the cintools directory but I have no idea if the user is supposed to use that.
So I think I am missing an important concept here. Can somebody help or direct me to some documentation (I found lots of information about how to link external code to LabVIEW but nothing about how to link LabVIEW code to an external program)?

Thanks Watermann,
your message has been very useful so now I am linking to the proper library but I still have problems when trying to load dynamically the shared library produced with LabVIEW. It is strange that I could successfully load the lvrt library at loading time but it does not work when I am loading the library at execution time.
I made a small LabVIEW program that prints a hello window and I am calling it from a C program. In the first program main.c I am linking to the lvrt library at loading time and it works but in the second one I am linking dynamically at execution time and it does not work. For my work I need to be able to load code done in LabVIEW at execution time. Any help is appreciated!
Program main.c:
// small program to call a LabVIEW shared library
#include
#include
#include "hello.h" // got this from the LabVIEW builder, i.e. when I made the hello.so
int main(void)
printf("Hello from C!\nLets call LabVIEW now\n");
hello();
printf("Bye ... \n");
return 0;
The command to compile main.c, i.e. linking shared library lvrt when loading main program:
gcc -Wall -I /usr/local/lv71/cintools/ -o main main.c hello.so -l lvrt
The LD_LIBRARY_PATH has been defined and exported:
$ LD_LIBRARY_PATH=$PWD
$ export LD_LIBRARY_PATH
IT WORKS!
Program main2.c:
// small program to call a LabVIEW shared library
#include
#include
#include
int main(void)
void * h_lvrt;
void * h_hello;
void (* hello)(void);
char * error;
printf("Hello from C!\nLets call LabVIEW now\n");
// open LabVIEW RunTime shared library
// in my computer located at /usr/local/lib/liblvrt.so
h_lvrt = dlopen("/usr/local/lib/liblvrt.so", RTLD_NOW);
// check for error
error = dlerror();
if (error) {
printf("error : could not open LabVIEW RunTime library\n");
printf("%s\n", error);
return 1;
// open hello shared library
// in my computer located at /home/darss/lv_call/hello.so
h_hello = dlopen("hello.so", RTLD_NOW);
// check for error
error = dlerror();
if (error) {
// close LabVIEW RunTime shared library
dlclose(h_lvrt);
printf("error : could not open hello library\n");
printf("%s\n", error);
return 1;
// get function hello from library hello.so
hello = dlsym(h_hello, "hello");
// check for error
error = dlerror();
if (error) {
// close hello shared library
dlclose(h_hello);
// close LabVIEW RunTime shared library
dlclose(h_lvrt);
printf("error : could not get the hello function\n");
printf("%s\n", error);
return 1;
// call hello function
hello();
// close hello shared library
dlclose(h_hello);
// close LabVIEW RunTime shared library
dlclose(h_lvrt);
printf("Bye ... \n");
return 0;
The command to compile main2.c, i.e. dynamically linking library lvrt at execution of main2 program:
gcc -Wall -o main2 main2.c -l dl
The LD_LIBRARY_PATH still defined and exported.
IT DOES NOT WORK!
Program output:
Hello from C!
Lets call LabVIEW now
error : could not open hello library
/home/darss/lv_call/hello.so: undefined symbol: WaitLVDLLReady

Failure to build LabVIEW application on Linux using "Shared library"

In order to create a LabVIEW application on linux without an X display, I complied the LabVIEW VI using the Linux Shared Library. I did this by right clicking on Build Specification and selecting New >> Shared Library, and in the Advanced section, checking the box labeled Use embedded version of run-time engine. At the end of the build process, a message came up informing that the build was unsuccessful, with the following message:
"Error 127 occurred at System Exec: sh: gcc: command not found
The error code is undefined. No one has provided a description for this code, or you might have wired a number that is not an error code to the error code input."
I had no compling the LabVIEW VI in the normal fashion, so am confused about what the problem is.
Solved!
Go to Solution.

Hi Julian,
gcc is a C and C++ compiler on Linux. An easy way to check if it is installed is to open a terminal and type "gcc", if the command is recognized then the package is already installed and the problem must lie elsewhere. If this distrobution of Linux has a package manager included then it should be displayed in there as well. If not then it could point to it being not installed or some dependency is missing making it not accessible from the command line. Here is a link that should hopefully step you through installing gcc with Redhat: http://www.cyberciti.biz/faq/centos-linux-install-gcc-c-c-compiler/ .
Justin D
Applications Engineer
National Instruments
http://www.ni.com/support/

NT DLL to Solaris Shared Library; C++ Exceptions

I have written a "plugin" DLL for a third party product that runs on NT. In my plugin I use C++ exception handling and it works wonderfully :-)
I am now trying to port my plugin so that it will work with the same third party product, but this time running on Solaris.
I knew I was going to have to port my DLL to Solaris and so made sure I did not use any Win32 specific anything. My code compiles & links fine on Solaris. For the most part it even works correctly.
The problem I have is that my code is not catching any of the exceptions it is throwing.
Section 5.14 of the C++ Programming Guide says that for exception handling to work in a shared library, it must be loaded with the RTLD_GLOBAL flag passed to the dlopen() function used to load the shared library.
Of course since the dlopen() function is in a third party product I have no way of knowing whether this parameter is being passed to the dlopen() function or not .. and more importantly I have no way of forcing it to be so.
So ultimately I guess the question for the more experienced shared library writers is .. do you just not use C++ exception mechanism because you can not force your shared library to be opened with the proper parameter to dlopen() .. or is there something else I can do to enable C++ exceptions in my shared library.

All works fine!...
$ mkdir /tmp/xxx
$ cat > dllfile.c
$ cat > dlluser.c
$ gcc -fPIC -c dllfile.c
$ gcc -shared -W1,-soname,libdllfile.so.1 -o libdllfile.so dllfile.o
$ gcc -o prog dlluser.c -ldl
$ ls -l
total 56
-rw-r--r-- 1 xxxxxx users 80 Апр 8 17:04 dllfile.c
-rw-r--r-- 1 xxxxxx users 908 Апр 8 17:15 dllfile.o
-rw-r--r-- 1 xxxxxx users 368 Апр 8 17:03 dlluser.c
-rwxr-xr-x 1 xxxxxx users 5260 Апр 8 17:15 libdllfile.so
-rwxr-xr-x 1 xxxxxx users 6412 Апр 8 17:16 prog
$
$ file *
dllfile.c:     c program text
dllfile.o:     ELF 32-bit MSB relocatable SPARC Version 1
dlluser.c:     c program text
libdllfile.so:     ELF 32-bit MSB dynamic lib SPARC Version 1, dynamically linked, not stripped
prog:          ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped
$
$ su
Password:
# mkdir -p /root/shared_library/
# cp libdllfile.so /root/shared_library/
# exit
$ ./prog
With the changes
library loaded
Inside function
$

Creating simple shared library using gcc under Solaris 10

Hi All:
I apologize if this is too newbie a question but have seen nothing that works for me yet.
I'm trying to create a shared library that contains a single object file using gcc (as installed on Solaris 10). I compiled the source code as follows:
gcc -c -fPIC x.cpp -o x.o
and got the x.o object file created and readable.
I then tried (from sample code on line):
gcc -shared -Wl,-soname,libMyLib.so.1 -o libMyLib.so.1.0.1 x.o
and get the following errors:
ld: warning: option -o appears more than once, first setting taken
ld: fatal: file libMyLib.so.1: open failed: No such file or directory
ld: fatal: File processing errors. No output written to x.o
collect2: ld returned 1 exit status

-soname is a GNU ld option. Use -h instead.
NB:
- you should use g++ not gcc to compile C++ code
- this forum is about the Oracle C++ compiler, not gcc. With it, you would do:
CC -c -KPIC x.cpp
CC -G -h libMyLib.so.1 -o libMyLib.so.1.0.1 x.o

Building 64bit shared library on Solaris 10

Similar Messages

Maybe you are looking for