Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #27270 > unrolled thread

how to understand the java code wrapping around C or other dependency libraries?

Started byzyng <xsli2@yahoo.com>
First post2014-01-10 07:16 -0800
Last post2014-01-10 16:34 -0800
Articles 3 — 3 participants

Back to article view | Back to comp.lang.java.programmer


Contents

  how to understand the java code wrapping around C or other dependency libraries? zyng <xsli2@yahoo.com> - 2014-01-10 07:16 -0800
    Re: how to understand the java code wrapping around C or other dependency libraries? Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-10 20:41 +0000
    Re: how to understand the java code wrapping around C or other dependency libraries? Roedy Green <see_website@mindprod.com.invalid> - 2014-01-10 16:34 -0800

#27270 — how to understand the java code wrapping around C or other dependency libraries?

Fromzyng <xsli2@yahoo.com>
Date2014-01-10 07:16 -0800
Subjecthow to understand the java code wrapping around C or other dependency libraries?
Message-ID<af88f0eb-c88a-4767-88dc-66deb793a81c@googlegroups.com>
Our java program(running on linux) needs calling a C program installed on our linux machine. It works fine! 

The thing I don't understand is when we deliver our product(the Java program) to our clients, who are using the same version Red Hat linux machines as us, but don't have that C program installed(it's very painful to install that C program for us due to the fact that the Red Hat version was old and the dependency library files are either out-of-dated or just not there. It took us a great amount of effort to install that C program. So we cannot assume or require our clients to install that program)

I sort of know that no need to ask the clients to install the C program on their linux machine. We can wrap all the needed *.o library files in the delivered JAR files and in our Java code, use this code:
System.load("the_c_program")
and set environment variable "LD_LIBRARY_PATH" to point to the location of those *.o files within the JAR file

But I just feel unclear about this procedure. If you know this and willing to explain to me all this is doing, I will greatly appreciate it.

This C program has its library files and its library files needs other library files on the system. So, which library files needs to be selected and packed inside our JAR is unclear for me right now.

Thank you very much.

[toc] | [next] | [standalone]


#27271

FromMartin Gregorie <martin@address-in-sig.invalid>
Date2014-01-10 20:41 +0000
Message-ID<lapltb$hvt$1@dont-email.me>
In reply to#27270
On Fri, 10 Jan 2014 07:16:20 -0800, zyng wrote:

> Our java program(running on linux) needs calling a C program installed
> on our linux machine. It works fine!
> 
> The thing I don't understand is when we deliver our product(the Java
> program) to our clients, who are using the same version Red Hat linux
> machines as us, but don't have that C program installed(it's very
> painful to install that C program for us due to the fact that the Red
> Hat version was old and the dependency library files are either
> out-of-dated or just not there. It took us a great amount of effort to
> install that C program. So we cannot assume or require our clients to
> install that program)
>
Try statically linking the C program and releasing it as a single 
executable. I have a number of C programs that I run under the Fedora 
distro that are compiled this way and run without problems, e.g.

hexdisp (compiled 2001), Bonnie and strproc (compiled 2003)

The hexdisp program looks too old to have been compiled under Fedora: it 
may have been last compiled under RedHat 7.2. 

IME statically linked programs pretty much 'just run' after a distro 
upgrade, but this isn't always the case for dynamically linked code.

> This C program has its library files and its library files needs other
> library files on the system. So, which library files needs to be
> selected and packed inside our JAR is unclear for me right now.
>
None of these executables are particularly big (14855, 22850, 21031 
respectively) so the overheads of this aren't big. The same has applied 
to the microEmacs editor (160KB, but recently recompiled for other 
reasons).


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]


#27272

FromRoedy Green <see_website@mindprod.com.invalid>
Date2014-01-10 16:34 -0800
Message-ID<7a41d99kft3tho779qft9ted1t01gkoip4@4ax.com>
In reply to#27270
On Fri, 10 Jan 2014 07:16:20 -0800 (PST), zyng <xsli2@yahoo.com>
wrote, quoted or indirectly quoted someone who said :

>This C program has its library files and its library files needs other libr=
>ary files on the system. So, which library files needs to be selected and p=
>acked inside our JAR is unclear for me right now.

The easier way to do it is to use Java Web Start.  It will install the
C programs for you.  Another way is to use an installer.

see http://mindprod.com/jgloss/javawebstart.html
http://mindprod.com/jgloss/installer.html
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Unlike many machines, computers require no water once they are
manufactured.

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.java.programmer


csiph-web