On Fri, 14 Mar 2025 15:41:56 GMT, Joachim Kern wrote:
> After "JDK-8339480: Build static-jdk image with a statically linked launcher"
> AIX was not able to build the new target. Therefore with "JDK-8345590 AIX
> 'make all' fails after JDK-8339480" the
On Fri, 21 Mar 2025 10:33:10 GMT, Magnus Ihse Bursie wrote:
>> Joachim Kern has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> added needed include
>
> make/StaticLibs.gmk line 117:
>
>> 115:
On Mon, 17 Mar 2025 10:02:12 GMT, Joachim Kern wrote:
>> make/StaticLibs.gmk line 116:
>>
>>> 114: #DEPS := $(STATIC_LIB_FILE), \
>>> 115: #OUTPUT_FILE := $(STATIC_LIB_EXPORT_FILES), \
>>> 116: #COMMAND := $(AR) $(ARFLAGS) -w $(patsubst %.exp,
On Fri, 14 Mar 2025 15:41:56 GMT, Joachim Kern wrote:
> After "JDK-8339480: Build static-jdk image with a statically linked launcher"
> AIX was not able to build the new target. Therefore with "JDK-8345590 AIX
> 'make all' fails after JDK-8339480" the
ortunately I
> was not able to make it function. So I still have my "raw" solution in place,
> but my last try with `SetupExecute` as comment beneath. Help is welcome.
Joachim Kern has updated the pull request incrementally with one additional
commit since the last revision:
foll
ortunately I
> was not able to make it function. So I still have my "raw" solution in place,
> but my last try with `SetupExecute` as comment beneath. Help is welcome.
Joachim Kern has updated the pull request incrementally with one additional
commit since the last revision:
foll
ortunately I
> was not able to make it function. So I still have my "raw" solution in place,
> but my last try with `SetupExecute` as comment beneath. Help is welcome.
Joachim Kern has updated the pull request incrementally with one additional
commit since the last revision:
ad
On Thu, 20 Mar 2025 14:30:58 GMT, Joachim Kern wrote:
>> After "JDK-8339480: Build static-jdk image with a statically linked
>> launcher" AIX was not able to build the new target. Therefore with
>> "JDK-8345590 AIX 'make all' fails after JDK-833
ortunately I
> was not able to make it function. So I still have my "raw" solution in place,
> but my last try with `SetupExecute` as comment beneath. Help is welcome.
Joachim Kern has updated the pull request incrementally with one additional
commit since the last revision:
fo
On Mon, 17 Mar 2025 15:01:10 GMT, Joachim Kern wrote:
>> Looks like this variable is misspelled (missing "S").
>>
>> DEPS := $(STATIC_LIB_FILE), \
>>
>> Also note that by default log level INFO is not printed. You would need to
>> run the build wi
On Mon, 17 Mar 2025 13:14:44 GMT, Erik Joelsson wrote:
>> The problem seems to be that `$(generate_export_list)` is empty and I do not
>> know why.
>
> Looks like this variable is misspelled (missing "S").
>
> DEPS := $(STATIC_LIB_FILE), \
>
> Also note that by default log level INFO is not pr
On Fri, 14 Mar 2025 17:35:02 GMT, Erik Joelsson wrote:
>> After "JDK-8339480: Build static-jdk image with a statically linked
>> launcher" AIX was not able to build the new target. Therefore with
>> "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was
>> disabled again.
>>
After "JDK-8339480: Build static-jdk image with a statically linked launcher"
AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make
all' fails after JDK-8339480" the new target was disabled again.
Now with this change we can enable the statically linked launcher target
On Wed, 22 Jan 2025 15:34:36 GMT, Joachim Kern wrote:
> We (SAP) try to introduce the ‘IBM Open XL C/C++ for AIX 17.1.2’ (based on
> clang 17) as a feasible compiler for jdk25, because in combination with the
> 17.1.3 runtime this would enable the support for ubsan.
> Unfortunat
On Thu, 23 Jan 2025 20:31:03 GMT, Phil Race wrote:
>> Joachim Kern has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> remove old solution
>
> If absolutely nothing else needs fp_pipewire.h I guess that oug
36:20
>36 extern jfieldID g_BImgRasterID;
> and the corresponding c-File
>jfieldID g_BImgRasterID;
>
> The other possible solution would be to compile everything with
> -Wno-tentative-definitions
> which could be set in flags-cflags.m4, if compiling with clang 17.
On Tue, 12 Mar 2024 15:27:29 GMT, Magnus Ihse Bursie wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>>
On Mon, 11 Mar 2024 08:59:03 GMT, Joachim Kern wrote:
>> make/autoconf/flags-cflags.m4 line 687:
>>
>>> 685: PICFLAG="-fPIC"
>>> 686: PIEFLAG="-fPIE"
>>> 687: elif test "x$TOOLCHAIN_TYPE" = xclang && tes
On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> T
On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> T
On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> T
On Fri, 8 Mar 2024 15:31:18 GMT, Magnus Ihse Bursie wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert SEARCH_PATH changes
>
> make/autoconf/flags-cflags.m4 line 687:
>
>> 685: PICFLAG="-fPIC"
>> 686
On Thu, 8 Feb 2024 14:47:26 GMT, Joachim Kern wrote:
>> And also `#define statvfs statvfs64` is not necessary with the same
>> explanation as for the `opendir` defines above -- sorry again.
>> The very only difference between statvfs and statvfs64 is that the
>> filesy
On Thu, 8 Feb 2024 09:03:10 GMT, Joachim Kern wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Once more, remove AIX dirent64 et al defines
>
> And also `#define statvfs statvf
On Thu, 8 Feb 2024 07:44:18 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request increme
On Tue, 6 Feb 2024 08:18:14 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request increme
On Mon, 5 Feb 2024 12:07:45 GMT, Matthias Baesken wrote:
> Current commit compiles nicely on AIX. One issue we might still have
> statvfs/statvfs64 is not mentioned here in the table of functions/structs
> redefined on AIX
> https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-th
27 matches
Mail list logo
