Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #27270 > unrolled thread
| Started by | zyng <xsli2@yahoo.com> |
|---|---|
| First post | 2014-01-10 07:16 -0800 |
| Last post | 2014-01-10 16:34 -0800 |
| Articles | 3 — 3 participants |
Back to article view | Back to comp.lang.java.programmer
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
| From | zyng <xsli2@yahoo.com> |
|---|---|
| Date | 2014-01-10 07:16 -0800 |
| Subject | how 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]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2014-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]
| From | Roedy Green <see_website@mindprod.com.invalid> |
|---|---|
| Date | 2014-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