svn commit: r335189 - in head/print/pdftk: . files

[Kozlov Sergey]

On 02.12.2013 12:08, Mathieu Arnold wrote:
> +--On 1 décembre 2013 23:21:51 +0100 Gerald Pfeifer <gerald at pfeifer.com>
> wrote:
> | On Fri, 29 Nov 2013, Mathieu Arnold wrote:
> |> Log:
> |>   Updated port to pdftk-2.02
> | :
> |>    - Added LIB_DEPENDS. Libraries provided by gcc required to run the
> |>    binary, but gcc is registered only as build dependency. Removing the
> |>      gcc after installation of pdftk is permitted but breaks pdftk
> |
> | This looks quite dubious since USE_GCC already takes care of
> | registering this run-time dependency.
> |
> | USE_GCC also takes care of the BUILD_DEPENDency, so the pre-existing
> | entry there also is unnecessary.
>
> Hum, does GCC always come with gcj ? I thought it did not, that's why there
> was an explicit dependency on it.
1. GCC does not always come with gcj, user can compile the port without 
it. So pdftk needs both gcc and gcj to build, and they are added 
explicitly as build dependencies.
2. USE_GCC register GCC (and not gcj) only as build dependency, so 
additional lib-dependencies are required.
> |>   maintainer timeout.
> |
> | This reminds me, I had submitted another patch in August 2012 (per
> | mail, not PR).  The -Wl,-path magic is not necessary and manually
> | constructing the path to the GCC run-time libraries is A Bad Idea[TM].
> | This is what ${LDFLAGS} is there for, and what the second, and more
> | important hunk, in my patch below does.
> |
> | Can you guys please give the patch below a spin and review?
>
> The patch looks ok to me, but I don't know a lot about how all that dark
> magic works :-p
>
3. Just as mat, I don't know a lot about all the dark magic, so while 
preparing the patch I just left these parts be, and tested the build and 
resulting binary.

Thanks,
Kozlov Sergey.