Bug 251283 - x11-toolkits/swt libjawt.so => not found (0) ; openjdk8 libraries not in ELF LD search path ; propose set rpath
Summary: x11-toolkits/swt libjawt.so => not found (0) ; openjdk8 libraries not in ELF...
Status: Closed Not A Bug
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Max Brazhnikov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-11-21 02:13 UTC by alt2600
Modified: 2020-11-22 01:04 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (makc)


Attachments
patch-make_freebsd.mak (3.76 KB, patch)
2020-11-21 02:13 UTC, alt2600
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description alt2600 2020-11-21 02:13:35 UTC
Created attachment 219847 [details]
patch-make_freebsd.mak

not sure it matters but I'm still running 12.1 amd64, the pending errata on zfs for 12.2 was a deal breaker for me for the time being and haven't checked it since 12.2 release. possibly its time to upgrade.

with the latest update swt builds and installs but 

|/usr/ports/x11-toolkits/swt|$} ldd /usr/local/lib/libswt-awt-gtk-411.so 
/usr/local/lib/libswt-awt-gtk-411.so:
        libjawt.so => not found (0)
        libc.so.7 => /lib/libc.so.7 (0x80024a000)

I checked and maybe its my system but openjdk8 is not included in the ELF LD search path on my system. So I added -Wl,-rpath,$(AWT_LIB_PATH) to AWT_LFLAGS to set the library path for libswt-awt-gtk-411.so during linking

not sure if openjdk8 is supposed to be in the elf search path or not, but reinstalling it didn't seem to fix anything even after a shutdown and returning to multi-user. ie restarting the ldconfig service. /usr/local/openjdk8 doesn't seem to be searched unless maybe forced with ldconfig_local_dirs

after building with the changed linker flags for AWT this is the output of ldd

|/usr/ports/x11-toolkits/swt|$} ldd /usr/local/lib/libswt-awt-gtk-411.so
/usr/local/lib/libswt-awt-gtk-411.so:
        libjawt.so => /usr/local/openjdk8/jre/lib/amd64/libjawt.so (0x800673000)
        libc.so.7 => /lib/libc.so.7 (0x80024a000)
        libawt.so => /usr/local/openjdk8/jre/lib/amd64/libawt.so (0x800677000)
        libawt_xawt.so => /usr/local/openjdk8/jre/lib/amd64/libawt_xawt.so (0x800749000)
        libjava.so => /usr/local/openjdk8/jre/lib/amd64/libjava.so (0x8007aa000)
        libjvm.so => not found (0)
        libjvm.so => not found (0)
        libm.so.5 => /lib/libm.so.5 (0x800e00000)
        libXext.so.6 => /usr/local/lib/libXext.so.6 (0x8007d5000)
        libX11.so.6 => /usr/local/lib/libX11.so.6 (0x800e32000)
        libXrender.so.1 => /usr/local/lib/libXrender.so.1 (0x8007ea000)
        libdl.so.1 => /usr/lib/libdl.so.1 (0x8007f7000)
        libXtst.so.6 => /usr/local/lib/libXtst.so.6 (0x800f7b000)
        libXi.so.6 => /usr/local/lib/libXi.so.6 (0x800f84000)
        libjvm.so => not found (0)
        libthr.so.3 => /lib/libthr.so.3 (0x800f96000)
        libjvm.so => not found (0)
        libverify.so => /usr/local/openjdk8/jre/lib/amd64/libverify.so (0x800fc2000)
        libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0x800ff6000)
        libjvm.so => not found (0)
        libXau.so.6 => /usr/local/lib/libXau.so.6 (0x8007fb000)
        libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x801023000)
Comment 1 Max Brazhnikov freebsd_committer 2020-11-21 19:38:11 UTC
It should not be a problem, because any java app needs $JAVA_HOME, so it knows where to find java libraries. Do you have any problem with app which uses swt after this upgrade?
Comment 2 alt2600 2020-11-22 01:04:22 UTC
(In reply to Max Brazhnikov from comment #1)

I actually noticed even my hack still was missing jvm.so too late to avoid posting. I mean jogamp-jogl seems to be happy during rebuilds, but I have nothing directly to test with java/swt. I've tried some sample code, but I couldn't get it to run likely due to my lack of knowledge on java compilation and building. I don't even recall what I put on that had jogamp-jogl other then misc jar's I might have been messing with. 

If this is normal behavior for the shared libraries dealing with java, then I'm thinking it is fine given jogamp-jogl compiles fine; it just felt odd. I so rarely do anything directly with java, I had never noticed this before. Sorry for the report.