extractpdfmark build failure on 10.6

[Ryan Schmidt]

Please don't do that. Please instead fix it in the affected compiler port(s).

https://trac.macports.org/ticket/57412


> On Oct 28, 2018, at 02:24, Ken Cunningham <ken.cunningham.webuse at gmail.com> wrote:
> 
> something like this from another port earlier today should do, until this issue finally gets fixed in the compiler run deps.
> 
> <https://github.com/macports/macports-ports/commit/c3b33c2df8abba42a855879b4097a17dee273fcc>
> 
> On Oct 27, 2018, at 23:55, Werner LEMBERG <wl at gnu.org> wrote:
> 
>> 
>> Folks,
>> 
>> 
>> please have a look at this build log
>> 
>>  https://build.macports.org/builders/ports-10.6_x86_64_legacy-builder/builds/83428
>> 
>> It fails with
>> 
>>  /usr/bin/ranlib: object:
>>    libextractpdfmark-poppler-core.a(libextractpdfmark_poppler_core_a-pagemode.o)
>>    malformed object (unknown load command 2)
>> 
>> Searching in the web, I've found a similar report w.r.t. ranlib:
>> 
>>  https://lists.macports.org/pipermail/macports-dev/2018-September/039282.html
>> 
>> It essentially says that `cctools' needs to be installed.  Is this a
>> dependency that I should add to extrapdfmark's Portfile?  Looking into
>> other Portfiles, maybe
>> 
>>  platform darwin 10 {
>>      depends_build-append       port:cctools
>>  }
>> 
>> is the right fix – is this sufficient to make macports use the newer
>> `ranlib' binary?
>> 
>> Another issue: extractpdfmark doesn't really need GhostScript for
>> compilation and execution; however, it will be optionally used for
>> some `make check' tests.  On the other hand, using the program makes
>> only sense if the calling Makefile (or whatever) feeds
>> extractpdfmark's output into GS.  Shall this be somehow reflected in
>> the Portfile, maybe an `optional dependency'?  If yes, how do I do
>> that?
>> 
>> 
>>    Werner