Re: RFR(XXS): 8205916: [test] Fix jdk/tools/launcher/RunpathTest to handle both, RPATH and RUNPATH
Hi Martin, Erik, thanks for the reviews! Regards, Volker On Wed, Jun 27, 2018 at 5:53 PM, Erik Joelsson wrote: > Looks ok to me. > > /Erik > > > > On 2018-06-27 03:26, Volker Simonis wrote: >> >> Hi, >> >> can I please have a review for the following tiny test fix (I'm >> actually not sure which would be the appropriate mailing list for this >> fix so please redirect if necessary): >> >> http://cr.openjdk.java.net/~simonis/webrevs/2018/8205916/ >> https://bugs.openjdk.java.net/browse/JDK-8205916 >> >> The test currently only checks for RPATH in the dynamic section of the >> launcher, but some linkers / Linux distributions (notably SLES) use >> RUNPATH instead. >> >> Following are the gory details: >> >> The test jdk/tools/launcher/RunpathTest.java checks that the java >> launcher on Linux and Solaris has the correct RPATH path baked into >> the executable. >> >> Unfortunately, the situation with RPATH is a little weird: >> >>- in order to bake a runtime path into a dynamically linked library >> or executable one has to use the "-rpath " linker option (from >> the C/C++ compiler this is usually available as "-Wl,-rpath,"). >>- depending on the dynamic linker version and Linux distribution, >> the "-rpath" linker option adds either a "RPATH" entry (Ubuntu 16.04, >> RHEL 7.4) or a "RUNPATH" entry (SLES 12.1, SLES 15) or both entries >> together (SLES 11.3) to the dynamic section of the shared >> library/executable. >>- the semantics of "RPATH" and "RUNPATH" are slightly different: >> "RPATH" is evaluated at runtime before LD_LIBRARY_PATH (if "RUNPATH" >> isn't present) while "RUNPATH" is evaluated after LD_LIBRARY_PATH >> (i.e. RUNPATH can be overridden at runtime by setting >> LD_LIBRARY_PATH). >>- "RPATH" is considered obsolete and should be replaced by "RUNPATH" >> according to the man-page of "ld.so (8)". >>- the linker option "--enable-new-dtags"/"--disable-new-dtags" (or >> the corresponding compiler flags >> "-Wl,--enable-new-dtags"/"-Wl,--disable-new-dtags") can be used to >> enforce the generation of "RUNPATH"/"RPATH" respectively (except for >> systems like SLES 11.3 where "--enable-new-dtags" generates both >> "RPATH" and "RUNPATH" while "--disable-new-dtags" only generates >> "RPATH"). >> >> But this issue is not about fixing the build so to cut a long story >> short - the test RunpathTest.java should be able to handle both >> runtime path variants equally well. This can be easily achieved by >> extending the match pattern from ".*RPATH.*\\$ORIGIN/../lib.*" to >> ".*R(UN)?PATH.*\\$ORIGIN/../lib.*" >> >> Thank you and best regards, >> Volker > >
Re: RFR(XXS): 8205916: [test] Fix jdk/tools/launcher/RunpathTest to handle both, RPATH and RUNPATH
Looks ok to me. /Erik On 2018-06-27 03:26, Volker Simonis wrote: Hi, can I please have a review for the following tiny test fix (I'm actually not sure which would be the appropriate mailing list for this fix so please redirect if necessary): http://cr.openjdk.java.net/~simonis/webrevs/2018/8205916/ https://bugs.openjdk.java.net/browse/JDK-8205916 The test currently only checks for RPATH in the dynamic section of the launcher, but some linkers / Linux distributions (notably SLES) use RUNPATH instead. Following are the gory details: The test jdk/tools/launcher/RunpathTest.java checks that the java launcher on Linux and Solaris has the correct RPATH path baked into the executable. Unfortunately, the situation with RPATH is a little weird: - in order to bake a runtime path into a dynamically linked library or executable one has to use the "-rpath " linker option (from the C/C++ compiler this is usually available as "-Wl,-rpath,"). - depending on the dynamic linker version and Linux distribution, the "-rpath" linker option adds either a "RPATH" entry (Ubuntu 16.04, RHEL 7.4) or a "RUNPATH" entry (SLES 12.1, SLES 15) or both entries together (SLES 11.3) to the dynamic section of the shared library/executable. - the semantics of "RPATH" and "RUNPATH" are slightly different: "RPATH" is evaluated at runtime before LD_LIBRARY_PATH (if "RUNPATH" isn't present) while "RUNPATH" is evaluated after LD_LIBRARY_PATH (i.e. RUNPATH can be overridden at runtime by setting LD_LIBRARY_PATH). - "RPATH" is considered obsolete and should be replaced by "RUNPATH" according to the man-page of "ld.so (8)". - the linker option "--enable-new-dtags"/"--disable-new-dtags" (or the corresponding compiler flags "-Wl,--enable-new-dtags"/"-Wl,--disable-new-dtags") can be used to enforce the generation of "RUNPATH"/"RPATH" respectively (except for systems like SLES 11.3 where "--enable-new-dtags" generates both "RPATH" and "RUNPATH" while "--disable-new-dtags" only generates "RPATH"). But this issue is not about fixing the build so to cut a long story short - the test RunpathTest.java should be able to handle both runtime path variants equally well. This can be easily achieved by extending the match pattern from ".*RPATH.*\\$ORIGIN/../lib.*" to ".*R(UN)?PATH.*\\$ORIGIN/../lib.*" Thank you and best regards, Volker
Re: RFR(XXS): 8205916: [test] Fix jdk/tools/launcher/RunpathTest to handle both, RPATH and RUNPATH
Looks good to me! On Wed, Jun 27, 2018 at 3:26 AM, Volker Simonis wrote: > Hi, > > can I please have a review for the following tiny test fix (I'm > actually not sure which would be the appropriate mailing list for this > fix so please redirect if necessary): > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8205916/ > https://bugs.openjdk.java.net/browse/JDK-8205916 > > The test currently only checks for RPATH in the dynamic section of the > launcher, but some linkers / Linux distributions (notably SLES) use > RUNPATH instead. > > Following are the gory details: > > The test jdk/tools/launcher/RunpathTest.java checks that the java > launcher on Linux and Solaris has the correct RPATH path baked into > the executable. > > Unfortunately, the situation with RPATH is a little weird: > > - in order to bake a runtime path into a dynamically linked library > or executable one has to use the "-rpath " linker option (from > the C/C++ compiler this is usually available as "-Wl,-rpath,"). > - depending on the dynamic linker version and Linux distribution, > the "-rpath" linker option adds either a "RPATH" entry (Ubuntu 16.04, > RHEL 7.4) or a "RUNPATH" entry (SLES 12.1, SLES 15) or both entries > together (SLES 11.3) to the dynamic section of the shared > library/executable. > - the semantics of "RPATH" and "RUNPATH" are slightly different: > "RPATH" is evaluated at runtime before LD_LIBRARY_PATH (if "RUNPATH" > isn't present) while "RUNPATH" is evaluated after LD_LIBRARY_PATH > (i.e. RUNPATH can be overridden at runtime by setting > LD_LIBRARY_PATH). > - "RPATH" is considered obsolete and should be replaced by "RUNPATH" > according to the man-page of "ld.so (8)". > - the linker option "--enable-new-dtags"/"--disable-new-dtags" (or > the corresponding compiler flags > "-Wl,--enable-new-dtags"/"-Wl,--disable-new-dtags") can be used to > enforce the generation of "RUNPATH"/"RPATH" respectively (except for > systems like SLES 11.3 where "--enable-new-dtags" generates both > "RPATH" and "RUNPATH" while "--disable-new-dtags" only generates > "RPATH"). > > But this issue is not about fixing the build so to cut a long story > short - the test RunpathTest.java should be able to handle both > runtime path variants equally well. This can be easily achieved by > extending the match pattern from ".*RPATH.*\\$ORIGIN/../lib.*" to > ".*R(UN)?PATH.*\\$ORIGIN/../lib.*" > > Thank you and best regards, > Volker >
RFR(XXS): 8205916: [test] Fix jdk/tools/launcher/RunpathTest to handle both, RPATH and RUNPATH
Hi, can I please have a review for the following tiny test fix (I'm actually not sure which would be the appropriate mailing list for this fix so please redirect if necessary): http://cr.openjdk.java.net/~simonis/webrevs/2018/8205916/ https://bugs.openjdk.java.net/browse/JDK-8205916 The test currently only checks for RPATH in the dynamic section of the launcher, but some linkers / Linux distributions (notably SLES) use RUNPATH instead. Following are the gory details: The test jdk/tools/launcher/RunpathTest.java checks that the java launcher on Linux and Solaris has the correct RPATH path baked into the executable. Unfortunately, the situation with RPATH is a little weird: - in order to bake a runtime path into a dynamically linked library or executable one has to use the "-rpath " linker option (from the C/C++ compiler this is usually available as "-Wl,-rpath,"). - depending on the dynamic linker version and Linux distribution, the "-rpath" linker option adds either a "RPATH" entry (Ubuntu 16.04, RHEL 7.4) or a "RUNPATH" entry (SLES 12.1, SLES 15) or both entries together (SLES 11.3) to the dynamic section of the shared library/executable. - the semantics of "RPATH" and "RUNPATH" are slightly different: "RPATH" is evaluated at runtime before LD_LIBRARY_PATH (if "RUNPATH" isn't present) while "RUNPATH" is evaluated after LD_LIBRARY_PATH (i.e. RUNPATH can be overridden at runtime by setting LD_LIBRARY_PATH). - "RPATH" is considered obsolete and should be replaced by "RUNPATH" according to the man-page of "ld.so (8)". - the linker option "--enable-new-dtags"/"--disable-new-dtags" (or the corresponding compiler flags "-Wl,--enable-new-dtags"/"-Wl,--disable-new-dtags") can be used to enforce the generation of "RUNPATH"/"RPATH" respectively (except for systems like SLES 11.3 where "--enable-new-dtags" generates both "RPATH" and "RUNPATH" while "--disable-new-dtags" only generates "RPATH"). But this issue is not about fixing the build so to cut a long story short - the test RunpathTest.java should be able to handle both runtime path variants equally well. This can be easily achieved by extending the match pattern from ".*RPATH.*\\$ORIGIN/../lib.*" to ".*R(UN)?PATH.*\\$ORIGIN/../lib.*" Thank you and best regards, Volker
