Re: [Plplot-devel] dyn-drivers linking -- again!

[Geoffrey F. <fu...@ga...>]

Jo=E3o Cardoso writes:
 > Sorry, I meant, using=20
 >=20
 > =09driverlibs :=3D -L. -l$(PLLIB_NAME)$(LIB_TAG)
 >=20
 > Well, I followed your recipe and build java (jdk-1.1.8). Python=20
 > demos, Java demos and Octave demos all run OK with the png device (a=
s=20
 > well as other fiole devices), using only the above driverslibs.

Hi all,

Sorry for my unresponsiveness.  I'm totally overwhelmed with other
stuff.

A quick comment on this business.  I have not been confused by the
behavior that has been reported.  I think a sufficiently careful study
of the emails that were exchanged earlier this fall, would make it all
make sense.  But it is certainly frustrating, no argument there.

The fix mentioned above should work.  Drivers should only depend on
libplplot.so, plus whatever driver specific support libs they might
need.  The dyndrv.in currently makes no effort to figure out exactly
and only which libs are appropriate to each driver.  It would be great
to fix that, although also laborious, which is why I never did it.

The best fix, however, is to do some code development to break even
the dependence upon libplplot.so, leaving only the (potential)
dependence of a driver upon some external libs (gd, X11, whatever). =20=


The way to do this is to embellish the driver interface so that when a
driver is inited, you pass in a struct, which contains members that
are function pointers:

struct plenv {

    void (*plapi_xyzcall)( PLINT x, ... );
    ...
 };

So, plcore would make one of thiese, fill in the function pointers
with the values of (addresses of) the various PLplot API function
entry points that might be conceivably needed by drivers, and then
pass this struct into the driver when init'ing it.  Then the drivers
store this, and make all their calls to the PLplot API via:

    plenv->plapi_xyzcall( x, ... );

etc.

This breaks the linkage requirement of drivers upon libplplot.so. =20

Doing it this way would follow in the footsteps of the Java Native
Interface, and, I think Vince said earlier, the TEA model.

At this point I can only offer this sketch, I cannot commit to
implement anytime soon.

--=20
Geoffrey Furnish         fu...@ga...