Re: Windows: Replace VisualStudio with gcc/clang?

[Stephen Colebourne]

On 12 March 2018 at 15:36, Erik Joelsson  wrote:
> On 2018-03-12 03:18, Magnus Ihse Bursie wrote:
> Just to comment on this. Microsoft has introduced standalone C++ build
> tools:
>
> http://landinghub.visualstudio.com/visual-cpp-build-tools
>
> I haven't looked into it yet, but it seems to be a much more lightweight
> alternative to installing Visual Studio if you just want to be able to build
> something. We should certainly make sure this works when full support for VS
> 2017 is in.

>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

Re: RFR: JDK-8199483 Clean up some non-standard LDFLAGS usage

[Erik Joelsson]

Right, explainable differences are fine of course. Thanks for the report!

/Erik


On 2018-03-13 03:27, Magnus Ihse Bursie wrote:

On 2018-03-12 21:44, Erik Joelsson wrote:

Looks good given that the comparison is clean (for the affected libs).


That depends on what you mean as "clean". Of course there is a 
difference in deps for libsaproc.so on solaris, since we add a new 
library to link with. As a side effect, the disassembly also changes 
somewhat.


The "file" command on Windows also reports a difference:
 other: ./bin/sawindbg.dll: PE32+ executable (DLL) (console) 
x86-64, for MS Windows
 this : ./bin/sawindbg.dll: PE32+ executable (DLL) (GUI) x86-64, 
for MS Windows
even though the documentation states that the subsystem selected does 
not matter for DLLs, just executables. (Possibly the PE format stores 
this information even if it not used, and "file" is not intelligent 
enough to discard this for DLLs).


Other than that, there are no reported differences.

/Magnus


/Erik


On 2018-03-12 13:03, Magnus Ihse Bursie wrote:
We have a few libraries that, for one reason or another, use 
non-standard LDFLAGS. There is typically no good reason for this, 
just historical accidents.


This patch fixes several places to remove odd or unneeded LDFLAGS, 
and to make them conform better to the prevailing standard. This 
will facilitate even more future cleanups in this area.


We still have some "snowflakes" left that have tricky LDFLAGS, but 
they require more research to figure out the best way to handle.


Some comments on the changes:
* -machine is not needed, it is autodetected by the linker.
* -subsystem:* has no meaning for dlls (and "windows" is default 
anyway)

* -map is always provided by SetupNativeCompilation
* -SAFESEH is provided by LDFLAGS_JDKLIB.
* The unknown symbols from libsaproc on Solaris was due to the 
missing link with libproc.
* In Windows DEF files, the HEAPSIZE command is equivalent to 
-heap:. But this is ignored for dlls. (We should not have any 
linker commands except EXPORTS in def files).


I'm running a COMPARE_BUILD set (it's 3/4 finished by now), to 
verify that there is no significant differences.


Bug: https://bugs.openjdk.java.net/browse/JDK-8199483
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8199483-simplify-LDFLAGS/webrev.01


/Magnus

Re: RFR: JDK-8199483 Clean up some non-standard LDFLAGS usage

[Magnus Ihse Bursie]

On 2018-03-12 21:44, Erik Joelsson wrote:

Looks good given that the comparison is clean (for the affected libs).


That depends on what you mean as "clean". Of course there is a 
difference in deps for libsaproc.so on solaris, since we add a new 
library to link with. As a side effect, the disassembly also changes 
somewhat.


The "file" command on Windows also reports a difference:
 other: ./bin/sawindbg.dll: PE32+ executable (DLL) (console) 
x86-64, for MS Windows
 this : ./bin/sawindbg.dll: PE32+ executable (DLL) (GUI) x86-64, 
for MS Windows
even though the documentation states that the subsystem selected does 
not matter for DLLs, just executables. (Possibly the PE format stores 
this information even if it not used, and "file" is not intelligent 
enough to discard this for DLLs).


Other than that, there are no reported differences.

/Magnus


/Erik


On 2018-03-12 13:03, Magnus Ihse Bursie wrote:
We have a few libraries that, for one reason or another, use 
non-standard LDFLAGS. There is typically no good reason for this, 
just historical accidents.


This patch fixes several places to remove odd or unneeded LDFLAGS, 
and to make them conform better to the prevailing standard. This will 
facilitate even more future cleanups in this area.


We still have some "snowflakes" left that have tricky LDFLAGS, but 
they require more research to figure out the best way to handle.


Some comments on the changes:
* -machine is not needed, it is autodetected by the linker.
* -subsystem:* has no meaning for dlls (and "windows" is default anyway)
* -map is always provided by SetupNativeCompilation
* -SAFESEH is provided by LDFLAGS_JDKLIB.
* The unknown symbols from libsaproc on Solaris was due to the 
missing link with libproc.
* In Windows DEF files, the HEAPSIZE command is equivalent to 
-heap:. But this is ignored for dlls. (We should not have any 
linker commands except EXPORTS in def files).


I'm running a COMPARE_BUILD set (it's 3/4 finished by now), to verify 
that there is no significant differences.


Bug: https://bugs.openjdk.java.net/browse/JDK-8199483
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8199483-simplify-LDFLAGS/webrev.01


/Magnus

Re: RFR: 8193017: Import freetype sources into OpenJDK source tree

[Thomas Stüfe]

On Mon, Mar 12, 2018 at 5:58 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

>
> On 2018-03-12 14:26, Thomas Stüfe wrote:
>
>> Yes, I am aware :( Long term I hope windows 32bit gets the same occasional
>> love as zero does. I can produce occasional patches if time allows.
>>
>> But in this case the error was in front of the computer, as Magnus
>> pointed,
>> I may just have a broken build env.
>>
> Actually, that was not what I was trying to say. I think there's a bug in
> the configure script, but one that perhaps only shows up on 32-bit Windows
> when it fails to locate the runtime dll in the "normal" places. Probably
> missing "" somewhere.
>
>
Sorry, then I misunderstood you. Yes, this may be. I'll recheck later.

..Thomas


> /Magnus
>
>
>
>
>> Thanks for your fix, btw! removing the freetypelib building hassle is a
>> huge step toward an easier windows build setup.
>>
>> ..thomas
>>
>> On Sat, Mar 10, 2018 at 5:35 PM, Philip Race 
>> wrote:
>>
>> This is a tricky one. Since Oracle no longer ships 32 bit JDKs for any
>>> platform for the new releases, then there aren't resources or effort
>>> being
>>> put into making sure it still builds. Our build systems might still
>>> support it, but for how long?
>>> It might effectively have to become a "port" that someone outside will
>>> step up to maintain.
>>> Not as different as AIX .. or as much effort perhaps .. but if someone
>>> will do that I expect patches would not be refused.
>>>
>>> -phil.
>>>
>>>
>>> On 3/9/18, 11:55 PM, Thomas Stüfe wrote:
>>>
>>> I attempted to test the 32bit build but that seems to have bitrotted, I
 ran into errors not having anything to do with your change.


>