Carl Godkin via PROJ <[email protected]> writes: > I'm not following what you're suggesting here.
I am suggesting keeping the two worlds totally separate. > 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! Having read that, I think you are ok. I am assuming: Your gdal-minimal.dll links to proj_9_3-minimal the plugin links to $other_vendor's libs and gdal-minimal.dll there are no programs on the computer that link to both gdal.dll and gdal-minimal.dll I would tend to separate these by prefix, rather than name, but I don't use windows and I gather the windows dll world is very difficult to deal with. >From my experience in packaging, I see situations where the base system has one version of a library; let's call it sqlite3 :-) But that base version is either too old, or lacks rtree, and some package wants the better one. But the package also wants heimdal (kerberos), which is from base, and that links to base sqlite. This is the sort of problem that is all too easy to run into. But it sounds like you are aware of it and avoiding it, and for now I think you are. You are though, on thin ice, and the next wrinkle may push you over the edge. _______________________________________________ PROJ mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/proj
