Hi Greg, I'm not following what you're suggesting here.
The plugin I'm building is for another vendor's software and they don't use GDAL or PROJ already in their main program. But they do use (an older version of ) libcurl. Our normal PROJ and GDAL depend on an up-to-date libcurl. I've called my minimal (w/o curl) versions of PROJ and GDAL "proj_9_3-minimal.dll" and "gdal-minimal.dll." We haven't had a problem with the approach I've described. What problem am I flirting with here, or what should I do differently? Sorry to be dense! Thanks a lot, carl On Tue, Jun 25, 2024 at 9:07 AM Greg Troxel via PROJ <[email protected]> wrote: > Carl Godkin via PROJ <[email protected]> writes: > > > On Tue, Jun 25, 2024 at 7:27 AM Javier Jimenez Shaw <[email protected]> > > wrote: > > > >> One question > >> > >> Are you linking the same GDAL (or final binary) with both versions of > >> PROJ? If that is the case, I think it would be undefined behaviour. > >> > >> > >>> > >>> > > No, I am not linking anything to both versions of PROJ. > > > > Our main apps link to both GDAL and PROJ (i.e., the "full" versions of > > both). > > > > This plugin links to GDAL (the minimal one) and PROJ (minimal also, and > the > > version the minimal GDAL was built with). > > Plugins are generally dynamically loaded, so there really needs to be > library compat with the host/main program. > > I would recommend having an entirely separate prefix for older/different > versions, and to build everything within each prefix, not crossing. > > > use. > _______________________________________________ > PROJ mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/proj >
_______________________________________________ PROJ mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/proj
