Re: glibc 2.12 support

* erik joelsson: > Hello Florian, > > We still build with glibc 2.12 in the sysroot at Oracle as we still > support Oracle Linux 6 (which uses glibc 2.12), so I'm afraid we still > need it. Fair enough. I will tack another thing to the side of this then. 8-> Thanks, Florian

glibc 2.12 support

It seems that building against glibc 2.12 is still supported. Is this something that is still needed? I'm mostly concerned with this fallback code on x86-64: // Unfortunately we have to bring all these macros here from vsyscall.h // to be able to compile on old linuxes. #define __NR_vgetcpu 2

Re: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection for Linux/AArch64 [v10]

On Sat, 11 Dec 2021 14:05:12 GMT, Andrew Haley wrote: >> Alan Hayward has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove BSD/Apple specific code > > src/hotspot/cpu/aarch64/globals_aarch64.hpp line 122: > >> 120: "It

Re: RFR: 8264130: PAC-RET protection for Linux/AArch64 [v2]

On Thu, 11 Nov 2021 18:07:37 GMT, Andrew Haley wrote: > > > Am I right is saying that for Macos, all generated code is remapped RO > > > before execution? > > > > > > Ah, no, it seems the code cache is not RWX all the time as far as Java > > threads are concerned. The Macos/AArch64 code is

Re: RFR: 8264130: PAC-RET protection for Linux/AArch64 [v2]

On Thu, 11 Nov 2021 14:43:59 GMT, Andrew Dinn wrote: >> src/hotspot/cpu/aarch64/globals_aarch64.hpp line 115: >> >>> 113: range(-1, 4096) >>> \ >>> 114: product(bool, UseROPProtection, false, >>> \ >>>

Re: RFR: 8264130: PAC-RET protection for Linux/AArch64 [v2]

On Thu, 11 Nov 2021 08:48:07 GMT, Alan Hayward wrote: >> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One >> of its uses is to protect against ROP based attacks. This is done by >> signing the Link Register whenever it is stored on the stack, and >> authenticating the value

Re: [OpenJDK 2D-Dev] RFR: 8261169: Upgrade HarfBuzz to the latest 2.8.0

* Phil Race: > Upgrade to harfbuzz 2.8 I believe this causes a build failure with GCC 8.3 (from Debian buster): * For target support_native_java.desktop_libfontmanager_hb-ot-shape-complex-use.o: In file included from

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

On Fri, 12 Feb 2021 12:22:44 GMT, Vladimir Kempik wrote: >> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 435: >> >>> 433: //||\ Java thread created by VM does not >>> have glibc >>> 434: //|glibc guard page| - guard, attached Java thread

Re: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2

* Philip Race: > There is more code in the newer version but not 4 times as much ! > Harfbuzz now requires c++11 features (-std=c++11) > Possibly the C++ compiler you are using (you don't mention platform) is > slower in this mode. It's GCC 8 on Debian buster, which defaults to C++14. And it's

Re: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2

* Phil Race: > This upgrades JDK to import the current 2.7.2 version of harfbuzz - > an OpenType text shaping library > > https://bugs.openjdk.java.net/browse/JDK-8247872 > > This has passed building and headless and headful automated tests on > all platforms. Is it just me, or does the new

Re: [8u] RFR(XS): 8233880: Support compilers with multi-digit major version numbers

* Andrew Haley: > On 5/11/20 8:58 AM, Florian Weimer wrote: >> * Severin Gehwolf: >> >>> Thanks for the review! Yes, generated-configure.sh changes are due to >>> version skew of autoconf being used. I'll try to generate configure on >>> an older machin

Re: [8u] RFR(XS): 8233880: Support compilers with multi-digit major version numbers

* Severin Gehwolf: > Thanks for the review! Yes, generated-configure.sh changes are due to > version skew of autoconf being used. I'll try to generate configure on > an older machine so as to avoid this before pushing. Does that sound > ok? THe runstatedir changes come and go (even in the

Re: RFR: JDK-8244210: The javac server is never used

* Erik Joelsson: > A minor mistake in JDK-8244036 is causing the javac server to never be > used, which is rather severly increasing build times. > > Before that change, the global variable ENABLE_SJAVAC was used to > determine if the server should be activated. After the change, the > global

Re: RFR: JDK-8244036 Refresh SetupJavaCompilation, and remove support for sjavac

* Magnus Ihse Bursie: > On 2020-04-30 15:50, Florian Weimer wrote: >> * Magnus Ihse Bursie: >> >>> I made sure that no build performances were measured on my system, and >>> since I saw no such indication, I did not make any more systematic analysis. >>

Re: RFR: JDK-8244036 Refresh SetupJavaCompilation, and remove support for sjavac

* Magnus Ihse Bursie: > I made sure that no build performances were measured on my system, and > since I saw no such indication, I did not make any more systematic analysis. > > What is the difference if you run with or without the javac server? Thanks. Which configure flags do you want me to

Re: RFR: JDK-8244036 Refresh SetupJavaCompilation, and remove support for sjavac

* Magnus Ihse Bursie: > The code for setting up Java compilation has long been quite hard to > understand, and has a tricky API. Part of this is due to the support for > the sjavac ("smart javac") system. We do not use sjavac anymore, and it > has not been tested for long. Part of the sjavac

Re: RFR: (T) 8241144 Javadoc is not generated for new module jdk.nio.mapmode

* Magnus Ihse Bursie: > On 2020-03-24 09:59, Andrew Dinn wrote: >> On 23/03/2020 18:38, Erik Joelsson wrote: >>> Looks good. >> Thanks for the review, Erik. >> >> I'm assuming that also implies it is trivial (because, copyright update >> a side, it really is a 1-liner :-). > > For code in the

Re: RFR: 8239563 - Reduce public exports in dynamic libraries built from static JDK libraries

* Bob Vandette: > CSR: > > https://bugs.openjdk.java.net/browse/JDK-8239791 For ELF (at least in the GNU incarnation), a change to the installed jni.h is not required to make the symbols hidden; a hidden definition would be sufficient for that. The declaration may however allow the compiler to

Re: Regression for Native Library Loading in 11.0.5 on Linux

* David Holmes: > In JDK 11 we stopped using mapfiles: > > https://bugs.openjdk.java.net/browse/JDK-8200178 > > which is where the SUNWprivate_1.1 label previously came from. This is not a backwards-compatible change under the GNU implementation of symbol versioning. If there are external

Re: RFR [XS] 8234809: set relro in linker flags when building with gcc - was RE: binary Hardening on linux using Relocation Read-Only (relro)

* Matthias Baesken: > Florian, may I add you as reviewer ? Sure, but I don't have a formal reviewer role. Thanks, Florian

Re: binary Hardening on linux using Relocation Read-Only (relro)

* Matthias Baesken: > If I understand > https://bugzilla.redhat.com/show_bug.cgi?id=1571359 > correct, RedHat is setting those flags already via the build system . BFD ld in binutils defaults to relro, except perhaps on s390x where your version might not implement the partial RELRO variant

Re: binary Hardening on linux using Relocation Read-Only (relro)

* Claes Redestad: > On 2019-11-25 18:30, Florian Weimer wrote: >> That being said, relocation processing for libjvm.so adds a couple of >> milliseconds to startup, and it looks like their number is growing with >> each release. > > This piqued my interest, so I too

Re: binary Hardening on linux using Relocation Read-Only (relro)

* Matthias Baesken: > For "-Wl,-z,now" some startup performance hits are mentioned in > articles/blogs - any experiences / performance-measurements with this > in the OpenJDK context ? While libjvm.so needs a staggering amount of relocations, most of them are relative. They are not eligible for

Re: RFR 8233880: Support compilers with multi-digit major version numbers

* Tim Bell: > Florian: > >> The current regular expression only matches one digit before the first >> dot. >> >> Bug: >> Webrev: >> >> Tested against GCC 10.0.0. configure no longer prints

RFR 8233880: Support compilers with multi-digit major version numbers

The current regular expression only matches one digit before the first dot. Bug: Webrev: Tested against GCC 10.0.0. configure no longer prints a C/C++ version mismatch warning. Thanks,

Re: Closed vs open builds

* Magnus Ihse Bursie: >> I want to fix some oversight in building the documentation (where >> content derived from open builds is incorrectly labeled as closed), >> and it would be nice to control the new behavior with such a flag. > Hm? I'm not sure what this means, but that sounds like a

Closed vs open builds

Is there a makefile flag to distinguish between closed (Oracle-internal/proprietary) and open builds? I want to fix some oversight in building the documentation (where content derived from open builds is incorrectly labeled as closed), and it would be nice to control the new behavior with such a

Re: RFR: 8227397: Add --with-extra-asflags configure option

* Severin Gehwolf: > Hi Martin, > > On Mon, 2019-07-08 at 10:42 -0700, Martin Buchholz wrote: >> (not really a review ...) >> >> I'm confused because the assembler is invoked when compiling any sort of >> source file - C, C++, or .s/.S. >> Wouldn't we want assembler flags passed uniformly, no

Re: [8u] 8226392: Launcher should not enable legacy stdio streams on GNU/Linux (glibc)

* Andrew John Hughes: > On 24/06/2019 14:54, Florian Weimer wrote: >> * Severin Gehwolf: >> >>> Could I please get reviews for this 8u only change? The JDK 8u build >>> logic for launcher files includes linker version script files (a.k.a >>> mapfil

Re: [8u] 8226392: Launcher should not enable legacy stdio streams on GNU/Linux (glibc)

* Severin Gehwolf: > Could I please get reviews for this 8u only change? The JDK 8u build > logic for launcher files includes linker version script files (a.k.a > mapfiles). The script file for x86 (32bit) marks symbol _IO_stdin_used > as local. When the symbol is not visible to the dynamic

Re: gcc FORTIFY_SOURCE application security flags

* Matthias Baesken: > I would prefer to get a hs_err file, do you know a way to get this in > context of the gcc flag _FORTIFY_SOURCE ? __fortify_fail should eventually raise SIGABRT. So if you install a handler for that signal, you should be able to generate hs_err file. __fortify_fail is

Re: RFR: 8220784: hsdis cannot be built with MinGW64

* David Holmes: > I'm unclear whether MINGW is only an issue on Linux when building for > Windows or whether also of use on Windows itself? I suspect it depends on how binutils has been configured. If you have enabled the shared libbfd, you won't need to specify -lz because libbfd loads it

Re: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain

* Martin Buchholz: > Here's an experiment using the 3 competing open source linkers to link > hotspot. This confirms that lld is faster than gold is faster than > bfd, but is the one second saving worth the engineering effort? > > $ (BUILDDIR=$HOME/ws/jdk/build/linux-x86_64-server-release; for

Re: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain

* Magnus Ihse Bursie: > The default binutils linker used by gcc, the bfd linker, is slow. The > new replacement, gold, has been distributed alongside gcc for several > years now, and is a well mature, and much faster, replacement. The gold linker is an optional component of binutils, not

Re: jdk build fails due to "warning: ‘readdir_r’ is deprecated"

On 04/05/2018 03:14 PM, David Holmes wrote: Sure, but "generally unnecessary in multithreaded programs" doesn't quite cut it when it comes to correctness. So we have a couple of obscure cases where readdir_r may do the wrong thing and we have a subset of cases where readdir may be thread-safe

Re: Building hsdis?

On 01/03/2018 02:58 PM, Andrew Haley wrote: On 03/01/18 13:35, Florian Weimer wrote: On 12/25/2017 11:58 PM, Andrew Haley wrote: IANAL, but AFAIK It would not help. The incompatibility is because you can't link pure GPLv2 code (HotSpot) and pure GPLv3 code (binutils) together, even via

Re: Building hsdis?

On 12/25/2017 11:58 PM, Andrew Haley wrote: IANAL, but AFAIK It would not help. The incompatibility is because you can't link pure GPLv2 code (HotSpot) and pure GPLv3 code (binutils) together, even via dynamic linkage. Changing the licences of hsdis.{c,h}) won't solve that problem. But

Re: Cross-building Windows binaries using the mingw toolchain

need building on 64 bit. Thanks. -- Florian Weimer / Red Hat Product Security Team

Re: Cross-building Windows binaries using the mingw toolchain

know at this point. -- Florian Weimer / Red Hat Product Security Team

Re: Cross-building Windows binaries using the mingw toolchain

to build supported binaries. At some level, this sucks, but that's life with heavily patched or proprietary downstreams. -- Florian Weimer / Red Hat Product Security Team

Cross-building Windows binaries using the mingw toolchain

system, would you be interested in integrating patches and carry them forward? Cross-build support would make it easier for GNU/Linux developers to work on features that should have parity on Windows, but lack shared native sources (e.g. networking-related features). -- Florian Weimer / Red Hat

Re: Cross-building Windows binaries using the mingw toolchain

interest in that. -- Florian Weimer / Red Hat Product Security Team

Re: [OpenJDK 2D-Dev] RFR: Allow using a system-installed lcms2

* Omair Majid: Basically, there is one file there (LCMS.c) that I want to make sure that does not get compiled against the headers located in the same directory. One way to be absolutely certain is to move the files out of that directory into another. `#include ..` rather than `#include ...`

Re: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so

eventually triggered loading the system zlib. This might still be relevant on stock OpenJDK 7. IcedTea avoids this by linking against system zlib. -- Florian Weimer / Red Hat Product Security Team

Re: Xm/Motif for OpenJDK build?

, openjdk-drops, procps, unzip, x11proto-input-dev, zip, This list is for building OpenJDK 7 on a derivative of Debian squeeze, but Ubuntu is probably similar. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel

Re: Project Proposal: Build Infrastructure Changes

* Julien Ponge: Did you consider using a tool like cmake to manage the build? Isn't the documentation a bit hard to get? IIRC, it is a self-published book which is not available from many book stores. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http

Re: package org.omg.CORBA_2_3.portable does not exist

* Kelly O'Hair: Try the attached patch. There was more to change that I thought. If you have other corba changes you should save them. So may need to: cd corba hg diff ~/saved.corba.patch hg update -C hg import corba.patch quit editor I'm on MASTER, so I had to pick

Re: package org.omg.CORBA_2_3.portable does not exist

* Kelly O'Hair: I'm not seeing that problem at all. And this failure looks very different. Are you sure you started with a fresh build, e.g. rm -f -r /home/fw/src/java/jdk7/build ??? Yes, I've just checked it again.