I forgot to add the client mailing lists as recipients. Sorry. (Not sure
if "sounds" belong to "awt" or "2d".)
/Magnus
On 2018-03-15 02:07, Magnus Ihse Bursie wrote:
From the bug description:
Moving this to a separate bug from JDK-8055190. In SoundLibraries.gmk,
the source code splitting is
From the bug description:
Moving this to a separate bug from JDK-8055190. In SoundLibraries.gmk,
the source code splitting is not complete. The directory libjsound is
used to build not only libjsound but libjsoundalsa and libjsoundds, and
thus needs a complex include/exclude system like before
On 2018-03-15 00:51, Erik Joelsson wrote:
Hello,
The diff in sawindbg is likely that it now has RC_FLAGS. Should it? I
would guess yes, it should be treated just as all the others.
Of course! Yes, it should definitely have them. It's the historical
baggage for sawindbg that has caused it not t
Hello,
The diff in sawindbg is likely that it now has RC_FLAGS. Should it? I
would guess yes, it should be treated just as all the others.
Otherwise this looks good.
/Erik
On 2018-03-14 16:34, Magnus Ihse Bursie wrote:
We have a lot of code duplication in all our calls to
SetupNativeCompil
We have a lot of code duplication in all our calls to
SetupNativeCompilation. This patch introduces a pair of functions,
SetupJdkLibrary and SetupJdkExecutable, which wraps
SetupNativeCompilation and sets up typical default values for our JDK
libraries.
The long-term idea here is that even mo
Looks good.
/Erik
On 2018-03-14 16:18, Magnus Ihse Bursie wrote:
BUILD_LIBKRB5 is currently a strange chimera between compiling
w2k_lsa_auth on windows, and osxkrb5 on macos. They do not share
source code, name or compilation options.
This patch separates them into two separate compilations
Looks good.
/Erik
On 2018-03-14 14:50, Magnus Ihse Bursie wrote:
For some odd reason, the native library compiled for jdk.security.auth
is called jaas_unix on unix and jaas_nt on windows. There's no good
reason for this, and it breaks with the common practice in OpenJDK.
This patch renames
BUILD_LIBKRB5 is currently a strange chimera between compiling
w2k_lsa_auth on windows, and osxkrb5 on macos. They do not share source
code, name or compilation options.
This patch separates them into two separate compilations, one for each
platform, so that they then can follow the normal JDK
For some odd reason, the native library compiled for jdk.security.auth
is called jaas_unix on unix and jaas_nt on windows. There's no good
reason for this, and it breaks with the common practice in OpenJDK.
This patch renames both libraries to the basename "jaas" (that is,
libjaas.so, libjaas.
On 2018-03-14 22:05, Phil Race wrote:
>I see we used to link with libawt_headless for solaris, but removed
it in >JDK-8194870. Phil remarked in that bug: "We linked against
headless before then >but allowed undefined symbols JDK 9 switched
this to libawt_headless when >headless apps failed."
>I see we used to link with libawt_headless for solaris, but removed it
in >JDK-8194870. Phil remarked in that bug: "We linked against headless
before then >but allowed undefined symbols JDK 9 switched this to
libawt_headless when >headless apps failed." but I'm not sure I
understand what thi
On 2018-03-14 21:44, Erik Joelsson wrote:
On 2018-03-14 13:22, Magnus Ihse Bursie wrote:
On 2018-03-14 15:59, Erik Joelsson wrote:
This change is unfortunately not correct for Linux and Solaris. We
cannot link libfontmanager explicitly against either libawt_xawt or
libawt_headless. See
https:
On 2018-03-14 13:22, Magnus Ihse Bursie wrote:
On 2018-03-14 15:59, Erik Joelsson wrote:
This change is unfortunately not correct for Linux and Solaris. We
cannot link libfontmanager explicitly against either libawt_xawt or
libawt_headless. See https://bugs.openjdk.java.net/browse/JDK-8196516
On 2018-03-14 15:59, Erik Joelsson wrote:
This change is unfortunately not correct for Linux and Solaris. We
cannot link libfontmanager explicitly against either libawt_xawt or
libawt_headless. See https://bugs.openjdk.java.net/browse/JDK-8196516
for my suggestion on a better fix than we curren
On 2018-03-14 17:23, Phil Race wrote:
I suppose you re-applied this patch after merging with my freetype
changes
but have not fixed up that new section since I still see ..
612 LIBS_solaris := -lc, \
.. which I had to add .. to my surprise .. so this patch is welcome
but it presumably ca
I suppose you re-applied this patch after merging with my freetype changes
but have not fixed up that new section since I still see ..
612 LIBS_solaris := -lc, \
.. which I had to add .. to my surprise .. so this patch is welcome
but it presumably can remove line 612 too ?
-phil.
On 03/1
Looks okay.
Mandy
On 3/14/18 5:56 AM, Chris Hegarty wrote:
This is a review request to remove remaining vestiges of
Java_sun_reflect_Reflection_getCallerClass.
JDK-8179424 removed terminally deprecated
jdk.unsupported/sun.reflect.Reflection.getCallerClass(int), these
references are to the no
This change is unfortunately not correct for Linux and Solaris. We
cannot link libfontmanager explicitly against either libawt_xawt or
libawt_headless. See https://bugs.openjdk.java.net/browse/JDK-8196516
for my suggestion on a better fix than we currently have. I was hoping
for Severin to chec
Hello,
Nice to see this cleaned up!
The differences you mention were the reason I meticulously kept all the
-lc in the exact same places as the old build did way back when we
rewrote the build system. I highly doubt they matter, but they needed to
be eliminated for a clean switch of build sys
On 14/03/18 13:08, Alan Bateman wrote:
On 14/03/2018 12:56, Chris Hegarty wrote:
This is a review request to remove remaining vestiges of
Java_sun_reflect_Reflection_getCallerClass.
JDK-8179424 removed terminally deprecated
jdk.unsupported/sun.reflect.Reflection.getCallerClass(int), these
ref
On 14/03/2018 12:56, Chris Hegarty wrote:
This is a review request to remove remaining vestiges of
Java_sun_reflect_Reflection_getCallerClass.
JDK-8179424 removed terminally deprecated
jdk.unsupported/sun.reflect.Reflection.getCallerClass(int), these
references are to the no-args getCallerClas
Looks good, Chris.
> -Original Message-
> From: core-libs-dev [mailto:[email protected]] On
> Behalf Of Chris Hegarty
> Sent: Mittwoch, 14. März 2018 13:57
> To: build-dev ; Core-Libs-Dev [email protected]>
> Subject: RFR 8199464 [11] Remove remaining vestiges of
This is a review request to remove remaining vestiges of
Java_sun_reflect_Reflection_getCallerClass.
JDK-8179424 removed terminally deprecated
jdk.unsupported/sun.reflect.Reflection.getCallerClass(int), these
references are to the no-args getCallerClass that was removed a long
time ago. These
>>
>> From my perspective, something needs to change, as I found it
>> completely impossible to install the old Visual Studio releases the
>> JDK demands (and it took ages just to find them). Requiring outdated
>> tooling to build the JDK really isn't great.
>>
>> Stephen
>>
>
> I agree. This i
This is the final LDFLAGS cleanup, which required some more work to resolve.
Libfontmanager had previously explicitely disabled -z defs, with the
result that linking did not complain about missing libraries. To fix
this, I had to provide the proper libraries to link with. For linux and
solaris
We should always use -lc when linking with solstudio. All other
toolchains do this automatically. This also means that -lc is
unnecessary for other platforms, where it has been set in some cases
(due to the old confusion where "solaris" really meant "unix").
I have tested this using COMPARE_BU
26 matches
Mail list logo
