jpackage Linux rpath

Alexey Semenyuk alexey.semenyuk at
Thu Mar 5 18:50:47 UTC 2020

Hi Andrew,

jpackage is providing similar functionality as javapackager, so I think 
you need to keep using patchelf with jpackage as you used it with 
I assume you use jpackage in two phases. The first phase creates 
application image and you use patchelf on launchers created by jpackage 
and then in the second phase you pack application image with modified 
launchers into rpm/deb package.
If this is the case and you would benefit from running jpackage in one 
phase, then I can think of adding to jpackage ability to run 3rd party 
script after application image creation. In this case you will need to 
create shell script using patchelf, place the script in resource 
directory so that jpackage can run the script after application image is 
created but before building rpm/deb package.

- Alexey

On 3/5/2020 9:42 AM, Auclair, Andrew wrote:
> Hi,
> We are in the process of upgrading to jpackage in Java 14 from javapackager in Java 10. So far the transition has been smooth and we're really liking jpackage.
> One question has come up regarding our Linux install. Currently we are using Patchelf on CentOS to set an rpath for the executables generated by javapackager. We have continued this with jpackage, but we were wondering if there's a way to set the rpath with jpackage to avoid using Patchelf.
> Thanks,
> Andrew Auclair
> Software Engineer
> Tactical Communications Group
> A Curtiss-Wright Company
> 2 Highwood Drive, Building 2, Suite 200
> Tewksbury, MA  01876-1157
> ----------------------------------------------------------------------
> This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have reason to believe that you have received this e-mail in error, please notify the sender and destroy this e-mail and any attached files. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the Curtiss-Wright Corporation or any of its subsidiaries. Documents attached hereto may contain technology subject to the U.S. Export Regulations. Recipient is solely responsible for ensuring that any re-export, transfer or disclosure of this information is in accordance with U.S. Export Regulations. The recipient should check this e-mail and any attachments for the presence of viruses. Curtiss-Wright Corporation and its subsidiaries accept no liability for any damage caused by any virus transmitted by this e-mail.

More information about the core-libs-dev mailing list