
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>

<p>Hi Even,</p>

<p>Thanks for the clarification. In that case I don't need to build it as a plugin, since this build will only end up on my own local machine.</p>

<p>Andreas</p>

<p id="reply-intro">On 2019-11-20 11:08, Even Rouault wrote:</p>

<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Andreas,<br /><br />

<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">I wonder what exactly the build option "--enable-pdf-plugin enable PDF<br />driver as a plugin (included in libgdal by default)" means?</blockquote>

<br />Plugin here means as a separate .so/.dll : gdal_PDF.so/dll<br />Mostly for licensing concerns if using the Poppler backend since Poppler is <br />subject to the GPL. So you can make a libgdal build mostly subject to X/MIT or <br />similar licenses, and in case you need it, use a gdal_PDF plugin subject to <br />GPL<br /><br />

<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">How does this relate to the other options of building against<br />poppler/podofo/pdfium ?</blockquote>

<br />It is orthogonal to the poppler/podofo/pdfium backend(s) used.<br />For the pdfium backend, which is a bit involved to build (pdfium actually), <br />there were also issues with symbol clashes between embedded libraries in <br />pdfium and others used by GDAL, and making a plugin instead of linking in core <br />GDAL library seemed to "solve" (workaround) issues. Was at least true on Linux <br />with pdfium of a few years ago. I don't remember having had such issues with <br />the recent upgrade I did in GDAL master.<br /><br />Even</div>

</blockquote>

<p><br /></p>


</body></html>