Prepare for version 0.1.0 release#51
Open
billdenney wants to merge 10 commits into
Open
Conversation
CRAN reviewer asked: "Please single quote software names in both Title and Description fields of the DESCRIPTION file such as 'PDFium'." Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
CRAN reviewer asked: "Please only download if no system installation
is found by configure."
POSIX `configure` now selects libpdfium in this order:
1. PDFIUM_HOME env var pointing at an existing install
(include/fpdfview.h + lib/libpdfium.{so,dylib})
2. pkg-config --exists libpdfium
3. Standard prefixes: /usr/local, /usr, /opt/homebrew, /opt/local
A system match writes src/Makevars pointing at the system paths
without an RPATH (ld.so.cache / macOS fallback paths resolve
libpdfium at load time). Only if nothing is found do we fall back
to tools/download-pdfium.R.
`configure.win` honors PDFIUM_HOME when it contains a pre-built
Mingw-compatible distribution (include/, lib/libpdfium.dll.a,
bin/libpdfium.dll); the files are staged into inst/ so the rest of
the build pipeline is unchanged. Windows has no canonical system
install location, so we do not guess.
Pin shell scripts (configure, configure.win, *.sh) to LF in
.gitattributes so a Windows checkout with core.autocrlf=true does
not break sh on POSIX.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
CRAN reviewer asked: "If the exit/about calls are not needed, please
omit them before compiling the dll."
Added `-ffunction-sections -fdata-sections -Wl,--gc-sections` to
src/Makevars.win so the linker discards unreferenced sections from
the package's own compilation units. Verified the package still
builds and loads after the change.
The residual `_exit` / `abort` / `exit` imports cannot be removed
at our layer. `objdump -p src/pdfium.dll` shows they are imports of
`api-ms-win-crt-runtime-l1-1-0.dll` (the Windows Universal CRT),
pulled in by Rtools' own static MinGW startup libraries:
libmingw32.a references abort
libmingwex.a references _exit
libucrt.a references _exit
Our own C/C++ source contains zero direct calls to these symbols
(all error paths route through Rcpp::stop()); removing them would
require rebuilding Rtools/MinGW itself. cran-comments.md spells
this out with the supporting evidence for the next reviewer.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…iles
The previous explanation in cran-comments.md was wrong. Empirical
testing shows:
* Our production .o files (R CMD INSTALL with -DNDEBUG, no
-UNDEBUG) contain zero references to _exit / abort / exit.
* Every Rtools/MinGW-built Windows DLL on this system imports
_exit / abort / exit from the Universal CRT (verified across
Rcpp, tibble, vctrs, cli, stringi, rlang, openssl, curl, ps,
fs, digest). Those imports come from libgcc / libstdc++ /
libmingw32.a runtime startup machinery; they are universal,
not specific to this package.
The real reason CRAN NOTEd us and not those other packages:
tools::check_compiled_code() reads libs/<arch>/symbols.rds when
_R_SHLIB_BUILD_OBJECTS_SYMBOL_TABLES_=TRUE (which CRAN sets) and
uses it to filter the DLL's symbols against what was actually in
the .o files. Without symbols.rds, it falls back to scanning the
DLL alone and trips on the runtime imports.
R CMD INSTALL writes src/symbols.rds when that env var is set,
and its default install logic copies it into libs/<arch>/. This
package ships an install.libs.R that replaces that default logic
(to handle the bundled libpdfium copy) and did not propagate
symbols.rds. Now it does.
Verified: with the fix, tools:::check_compiled_code() returns
NULL on the installed package both with and without
_R_SHLIB_BUILD_OBJECTS_SYMBOL_TABLES_=TRUE.
Also reverted the -ffunction-sections -fdata-sections -Wl,--gc-sections
flags I added speculatively in the previous commit — they did not
remove the runtime imports (the real fix is symbols.rds) and they
actually grow pdfium.dll by ~27 KB on this toolchain because the
per-section header overhead exceeds the dead-code savings.
cran-comments.md is updated to reflect the correct diagnosis.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
README's Installation section and ?pdfium-package now spell out the
order configure uses to pick a libpdfium:
1. PDFIUM_HOME env var pointing at an existing install
2. pkg-config --exists libpdfium (POSIX only)
3. /usr/local, /usr, /opt/homebrew, /opt/local (POSIX only)
4. Download from bblanchon/pdfium-binaries (offline opt-out via
PDFIUM_OFFLINE=1 with a vendored archive)
The README lists the required file layout under $PDFIUM_HOME per
platform so users with a hand-built or vendored libpdfium can wire
it in without guessing.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.