When a bundled php extension (with custom PHP_EXT_S) has symlinks pointing outside the extension directory (e.g. "../foo/bar.c"), such symlinks become broken after they are copied to a slot workdir. Fix: use "cp --dereference" in eclass/php-ext-source-r3.eclass: @@ -165,7 +165,7 @@ popd > /dev/null || die fi for slot in $(php_get_slots); do - cp --recursive --preserve "${orig_s}" "${WORKDIR}/${slot}" || \ + cp --recursive --preserve --dereference "${orig_s}" "${WORKDIR}/${slot}" || \ die "failed to copy sources from ${orig_s} to ${WORKDIR}/${slot}" php_init_slot_env "${slot}" php-ext-source-r3_phpize
Why would the source code for an extension try to reference a relative path outside of the working directory? My initial reaction is that they shouldn't know or care where they're being built, but maybe it's a lack of imagination on my part.
The files are still within the working directory, but outside of the extension directory. For example: https://github.com/VerizonDigital/ectoken/tree/master/php-ectoken base64.* and ectoken_v3.* are symlinks pointing to the corresponding files in ../c-ectoken/ecencrypt.
(In reply to Slava from comment #2) > The files are still within the working directory, but outside of the > extension directory. > They should be building one shared library that is used by both c-ectoken and php-ectoken, rather than copy/pasting the implementation into both programs... But, I see the problem and we might want to support this. I wonder if there's a way to ensure that the symlinks point within WORKDIR, even if they're outside of PHP_EXT_S?
Something quick and dirty: if find -L "${WORKDIR}" -print0 2>/dev/null | xargs -0 realpath -z 2>/dev/null | grep -qzv "${PHP_EXT_S}"; ... (it seems find doesn't get SIGPIPE if using -exec, hence xargs) But I'm not sure if such sort of checks is a responsibility of an eclass. If someone wants to shot himself in the leg, he'll find a way even without symlinks, e.g. #include <outside of WORKDIR>.
Oops, missing ^ in grep, should be: grep -qzv "^${PHP_EXT_S}"
After thinking about this for a bit, we should probably just be duplicating the entire source tree, and not only the PHP_EXT_S portion of it. That way we guard against whatever other weird things people might want to do in the future, and don't have to dereference any symlinks. Dereferencing the symlinks (which might affect timestamps or pull in things from outside of ${S}) gives me a funny feeling, even though I haven't come up with any concrete problems that would result.
Sounds reasonable to me. With dereferencing one can make you experience a truly funny feeling by symlinking to / :)
