duplicate symbols in static libraries

Kevin Rushforth kevin.rushforth at oracle.com
Mon Oct 21 17:44:06 UTC 2019


Removing Pisces will completely remove almost all of the native code in 
prism-sw (it isn't used at all by Marlin). What I meant is that the 
prism-sw library also contains native functions that have nothing to do 
with rasterization. Thus the library will still remain after the removal 
of Pisces, it will just be much smaller.

-- Kevin


On 10/21/2019 10:33 AM, Johan Vos wrote:
> Hi Kevin,
>
> Marlin is already used in com.sun.prism.sw classes, so it seems to me 
> we can just use Marlin in prism-sw (instead of Pisces), unless I'm 
> missing something?
>
> - Johan
>
> Op ma 21 okt. 2019 om 17:59 schreef Kevin Rushforth 
> <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>>:
>
>     Actually, I did a quick check and there is more than just Pisces
>     in the
>     native prism_sw library, so removing Pisces isn't sufficient to
>     remove
>     prism_sw.
>
>     -- Kevin
>
>
>     On 10/21/2019 5:54 AM, Kevin Rushforth wrote:
>     > This approach seems fine to me. Worth noting is that prism-sw
>     will be
>     > removed as part of the Pisces removal by JDK-8196079 [1], which is
>     > targeted for 14. If your proposed change helps in the mean time,
>     then
>     > I see no problem with getting it in.
>     >
>     > -- Kevin
>     >
>     > [1] https://bugs.openjdk.java.net/browse/JDK-8196079
>     >
>     > On 10/21/2019 4:26 AM, Johan Vos wrote:
>     >> Hi,
>     >>
>     >> When creating static libraries for the native parts of JavaFX,
>     I ran
>     >> into
>     >> an issue with symbols exposed in more than 1 library:
>     >> checkAndClearException() is declared and used in both
>     >> libjavafx_font.a and
>     >> in libprism_sw.a
>     >>
>     >> I have a simple fix for this that adds a prefix to the symbol
>     in the
>     >> prism-sw code:
>     >>
>     https://github.com/johanvos/jfx/commit/9180a73b51f60b0c6fe6e89184c4cba88fcf1696
>
>     >>
>     >>
>     >> However, I'm not sure this is the generally agreed approach.
>     Are there
>     >> opinions/guidelines for this?
>     >>
>     >> - Johan
>     >
>



More information about the openjfx-dev mailing list