On Feb 2, 2016, at 7:27 PM, Scott Palmer <swpal...@gmail.com> wrote: > > Note that this is a RPM-based system, apt-get is not available, yum is. > > yum install libX11
What is the Linux system you are running? > … > Package libX11-1.6.0-2.1.el7.x86_64 already installed and latest version > > I get a similar message for the other dependencies. > > Examining the .rpm file I can see that the bundled runtime contains a > lib/amd64 folder, so I’m pretty sure everything it did was 64-bit. > > If I run: > > yum install libX11.so.6 > > it wants to install the i686 architecture. > > So I went ahead an used yum to install the dependencies that way, but it > failed on the last one (of course): > $ sudo yum install libasound.so.2 > Resolving Dependencies > --> Running transaction check > ---> Package alsa-lib.i686 0:1.0.28-2.el7 will be installed > --> Finished Dependency Resolution > Error: Multilib version problems found. > … > ...you can also use --setopt=protected_multilib=false to remove > this checking, however this is almost never the correct thing to > do as something else is very likely to go wrong (often causing > much more problems). > > Protected multilib versions: alsa-lib-1.0.28-2.el7.i686 != > alsa-lib-1.0.27.2-3.el7.x86_64 > > > It seems to be that javapackager has made a mistake and is claiming to depend > on the 32-bit packages even though it really requires the 64-bit packages. That’s what it’s sounding like to me. Looking at the code for the RPM bundler there isn’t anything I can find offhand that would suggest this. Bundling with 32/64-bit is triggered off the JDK used. Note that you have to bundle the same bitness JRE as the JDK. It should fail if it isn’t but that isn’t the case yet and that isn’t your problem. It appears the RPM generated is 32-bit. Unless you are bundling a 32-bit JRE and the RPM bundler keys off the native libraries used. Can you check the launcher executable? I think it’d be: $ file myserver-1.0-1.x86_64/app/myserver Can you file a minimum test case along with the Linux system used so we can prioritize with other bugs and find a solution? Chris > Scott > > >> On Feb 2, 2016, at 7:03 PM, Chris Bensen <chris.ben...@oracle.com> wrote: >> >> This list or the Deployment blog >> (https://blogs.oracle.com/talkingjavadeployment/) are the best places to get >> help with the javapackager. >> >> Is your app built with the 64-bit or 32-bit packager? I noticed “x86_64” >> appended to the name. If it’s 32-bit you could try running: >> >> sudo apt-get install libx11-6:i386 >> >> Chris >> >> >>> On Feb 2, 2016, at 1:49 PM, Scott Palmer <swpal...@gmail.com> wrote: >>> >>> What's the best place to go to get help with using the javapackager ? >>> >>> I've read the docs, but things aren't working smoothly and it would be >>> helpful if there were some known working examples to base things on. I'm >>> not finding any examples that use the -daemon or -BserviceHint=true >>> options, for example. >>> >>> I attempted to make a .rpm that installs a service/daemon but when I try to >>> install it, it fails claiming the following dependencies cannot be met: >>> >>> libX11.so.6 is needed by myserver-1.0-1.x86_64 >>> libXext.so.6 is needed by myserver-1.0-1.x86_64 >>> libXi.so.6 is needed by myserver-1.0-1.x86_64 >>> libXrender.so.1 is needed by myserver-1.0-1.x86_64 >>> libXtst.so.6 is needed by myserver-1.0-1.x86_64 >>> libasound.so.2 is needed by myserver-1.0-1.x86_64 >>> >>> Considering the app already runs fine on this same system, I'm a bit >>> confused that it is complaining of missing dependencies. >>> >>> Scott >> >
