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

[Volker Simonis]

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.
>>
>>
>