This looks good, hopefully for the last time. :)
Thanks for hanging in there!
/Erik
On 2018-04-05 02:16, Magnus Ihse Bursie wrote:
On 2018-04-04 17:25, Erik Joelsson wrote:
On 2018-04-04 00:42, Magnus Ihse Bursie wrote:
On 2018-04-03 23:16, Erik Joelsson wrote:
Looks good to me at least. E
On 2018-04-04 17:25, Erik Joelsson wrote:
On 2018-04-04 00:42, Magnus Ihse Bursie wrote:
On 2018-04-03 23:16, Erik Joelsson wrote:
Looks good to me at least. Exporting symbols from executables seems
wrong so applying hidden as default seems good to me.
Unfortunately, it was not this easy. :-(
On Tue, Apr 3, 2018 at 1:42 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> Here's an updated webrev that uses the same pattern as for native shared
> libraries to hide non-exported symbols, for executables as well.
>
> I hope you're happy now :-)
>
>
Thanks for your efforts! I k
On 2018-04-04 00:42, Magnus Ihse Bursie wrote:
On 2018-04-03 23:16, Erik Joelsson wrote:
Looks good to me at least. Exporting symbols from executables seems
wrong so applying hidden as default seems good to me.
Unfortunately, it was not this easy. :-(
Out of paranoia, I also started a test ru
On 2018-04-03 23:16, Erik Joelsson wrote:
Looks good to me at least. Exporting symbols from executables seems
wrong so applying hidden as default seems good to me.
Unfortunately, it was not this easy. :-(
Out of paranoia, I also started a test run on Windows, even though it
should not have bee
Looks good to me at least. Exporting symbols from executables seems
wrong so applying hidden as default seems good to me.
/Erik
On 2018-04-03 13:42, Magnus Ihse Bursie wrote:
Here's an updated webrev that uses the same pattern as for native
shared libraries to hide non-exported symbols, for e
Here's an updated webrev that uses the same pattern as for native shared
libraries to hide non-exported symbols, for executables as well.
I hope you're happy now :-)
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8200358-remove-launcher-mapfiles/webrev.02
I know there's a bit of redundancy now
On 28/03/2018 22:48, Magnus Ihse Bursie wrote:
2) The exported symbols from executables are a public API and the
change therefore require a CSR.
I don't think there are any supported/documented interfaces here. It
would be nice if the launchers were linked without any exported symbols,
that
>From https://gcc.gnu.org/wiki/Visibility
Why is the new C++ visibility support so useful?
Put simply, it hides most of the ELF symbols which would have previously
(and unnecessarily) been public. This means:
-
*It very substantially improves load times of your DSO (Dynamic Shared
Obje
On Wed, Mar 28, 2018 at 2:48 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> On 2018-03-28 22:39, Martin Buchholz wrote:
>
>
>
> On Wed, Mar 28, 2018 at 12:07 PM, Magnus Ihse Bursie <
> magnus.ihse.bur...@oracle.com> wrote:
>
>>
>> Anyway, with this patch all symbols in executable
On 2018-03-28 22:39, Martin Buchholz wrote:
On Wed, Mar 28, 2018 at 12:07 PM, Magnus Ihse Bursie
mailto:magnus.ihse.bur...@oracle.com>>
wrote:
Anyway, with this patch all symbols in executables will be
visible, so there should be no problem anyway.
The symbols visible in the main
On Wed, Mar 28, 2018 at 12:07 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
>
> Anyway, with this patch all symbols in executables will be visible, so
> there should be no problem anyway.
>
The symbols visible in the main executable are a sort-of-public interface.
The difference
Looks good from a build perspective.
/Erik
On 2018-03-28 04:08, Magnus Ihse Bursie wrote:
This patch removes mapfiles for the JDK executables (launchers).
There's really no reason to have mapfiles in the first place for
executables. Since no-one is linking to them, what symbols they export
i
On 2018-03-28 14:19, Martin Buchholz wrote:
I'm not sure about this.
IIRC the AIX linker is able to use executables as a build-time input.
Maybe our AIX maintainers have some expertise here.
As you heard from Thomas, this does not seem to be a problem.
I think the _dynamic_ linker will see
On Wed, Mar 28, 2018 at 2:19 PM, Martin Buchholz
wrote:
> I'm not sure about this.
>
> IIRC the AIX linker is able to use executables as a build-time input.
> Maybe our AIX maintainers have some expertise here.
>
>
I am quite sure we do not do that in the VM. I'm running a test build with
your pa
I'm not sure about this.
IIRC the AIX linker is able to use executables as a build-time input.
Maybe our AIX maintainers have some expertise here.
I think the _dynamic_ linker will see symbols in the executable. Resolving
them is likely to be strictly more work at startup, and it is likely that
This patch removes mapfiles for the JDK executables (launchers). There's
really no reason to have mapfiles in the first place for executables.
Since no-one is linking to them, what symbols they export is immaterial.
Bug: https://bugs.openjdk.java.net/browse/JDK-8200358
WebRev:
http://cr.openjd
17 matches
Mail list logo
