[OpenJDK 2D-Dev] RFR(L): 8024854: Basic changes and files to build the class library on AIX

Volker Simonis volker.simonis at gmail.com
Thu Oct 17 13:42:34 UTC 2013

Hi Phil,

thanks a lot for the review. Please see my comments inline:

On Wed, Oct 16, 2013 at 12:48 AM, Phil Race <philip.race at oracle.com> wrote:
> Hello Volker,
> I just remembered & got back to these changes - my email inbox isn't a very
> good reminder system.
> I am OK with everything I see in the client areas except as below :-
>  /* Very basic start for AIX -  feel free to complete ..
>  169  */
> We should remove this comment. If that means first getting
> any necessary completion from IBM folks, please ask them.
> Given the lack of fontconfig on AIX as standard its probably
> more important for AIX than any other OS so I suggest the latter.

I've just checked with a colleague and the two paths seem to be the
correct (and only standard) locations for Type1 and TrueType fonts on

So I'll remove the comment and change to code to:

#elif defined(AIX)
static char *fullAixFontPath[] = {
    "/usr/lpp/X11/lib/X11/fonts/Type1",    /* from X11.fnt.iso_T1  */
    "/usr/lpp/X11/lib/X11/fonts/TrueType", /* from X11.fnt.ucs.ttf */
    NULL, /* terminates the list */

because "/usr/lib/X11/fonts/" are actually just symlinks to the real
location under "/usr/lpp".
The comment also names the filesets (i.e. the default AIX packages)
which contain the corresponding fonts.

>   * insted it has to be installed from the "AIX Toolbox for Linux
> Applications"
> insted -> instead


> X11SurfaceData.c:
>  #ifndef MAX
> and
>  #ifndef MIN
> I found that re-definition warnings are seen at least on
> 64 bit linux. Maybe you should rename these too generically
> named macros to  XSD_MAX and XSD_MIN.

That's a good idea. Done.

>> extern int dladdr(void *addr, Dl_info  *info); // use the HotSpot
>> implementation from libjvm.so
> Did you ever get an opinion on this from the libraries or hotspot teams ?

No, I didn't got any opinions on that topic.

I'm currently preparing a new webrev for the second review round where
we can then hopefully clarify that point.

Thank you and best regards,

> -phil.
> On 9/19/2013 7:28 AM, Volker Simonis wrote:
>> Hi Phil,
>> I'm open to any good ideas.
>> The current solution is pragmatic, simple and it has no impact on
>> existing platforms.
>> The other possibility I see is to put the 'dladdr' implantation into
>> its own library (something equivalent to "libjli") and link that
>> library to "libawt". But I currently don't see any existing library I
>> could put the implementation into.
>> Notice that the change I propose already contains an extra
>> implementation of 'dladdr' for AIX in
>> "src/solaris/demo/jvmti/hprof/hprof_md.c" because "libhprof" is not
>> linked against libjvm and we therefore can not use the 'extern'-trick
>> there.
>> Of course it would be nice if there would be a small library which
>> contains 'dladdr' and which could be linked against both, "libawt" and
>> "libhprof". But I think that would require bigger shared changes (with
>> possible empty implementations on the current platforms).
>> What do other think?
>> Regards,
>> Volker
>> On Thu, Sep 19, 2013 at 3:53 PM, Phil Race <philip.race at oracle.com> wrote:
>>> Hi,
>>> w.r.t the one issue below : is the awt load library code the only place
>>> you
>>> need/are doing this ? If someone else (hotspot, core-libs) already
>>> assented
>>> to this
>>> then I guess I could too but I'd like to hear for sure that hotspot and
>>> core-libs
>>> teams both agree to this approach and whether there is an alternative.
>>> -phil.
>>> On 9/19/13 4:29 AM, Volker Simonis wrote:
>>> Hi Phil,
>>> thank you for looking at the changes. Please find my answers inline:
>>>> /* AIX does not provide the 'dladdr' function. But fortunately, we've
>>>>    42  * already implemented it in the HotSpot, because we need it there
>>>> as
>>>>    43  * well (see hotspot/src/os/aix/vm/porting_aix.{hpp,cpp}).
>>>> Whilst this is in "ifdef AIX" this reliance on an exported hotspot
>>>> function sounds hacky. What actual requirement is there that the
>>>> AIX class libraries be so tightly-coupled with that VM?
>>>> There is no contract there.
>>> You're right, there is no contract. It's just pragmatic solution and I
>>> think
>>> it should always work because the libjvm will always be loaded at the
>>> point
>>> in AWT where it is used. Another solution would be to re-implement the
>>> functionality in the class library and I don't like code duplication
>>> either.
>>>> -phil.

More information about the 2d-dev mailing list