Re: extractpdfmark build failure on 10.6

[Werner LEMBERG]

>> something like this from another port earlier today should do, until
>> this issue finally gets fixed in the compiler run deps.
>> 
>> > >
> 
> Small comment, but cctools works fine on all OSes versions, so there
> is really no need to put it inside a Darwin version check. In fact,
> for all OSes using Xcode 7 or older it provides a newer toolchain. I
> would just remove the Darwin version check..

I think the version check makes sense, since it is a reminder why the
code is there at all.  It is a gentle reminder that it should be
removed as soon the problem gets fixed at a higher level.

Apropos higher level & extractpdfmarks' Portfile: Shall I simply wait
until the c++11 portgroup file has been fixed?  I've already submitted

  https://github.com/macports/macports-ports/pull/2893

which would be unnecessary then.


Werner

Re: extractpdfmark build failure on 10.6

[Christopher Jones]

> On 28 Oct 2018, at 7:24 am, Ken Cunningham  
> wrote:
> 
> something like this from another port earlier today should do, until this 
> issue finally gets fixed in the compiler run deps.
> 
>   
> >

Small comment, but cctools works fine on all OSes versions, so there is really 
no need to put it inside a Darwin version check. In fact, for all OSes using 
Xcode 7 or older it provides a newer toolchain. I would just remove the Darwin 
version check..

Chris

> 
> On Oct 27, 2018, at 23:55, Werner LEMBERG  > 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



smime.p7s
Description: S/MIME cryptographic signature

Re: 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  
> wrote:
> 
> something like this from another port earlier today should do, until this 
> issue finally gets fixed in the compiler run deps.
> 
> 
> 
> On Oct 27, 2018, at 23:55, Werner LEMBERG  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

Re: extractpdfmark build failure on 10.6

[Werner LEMBERG]

> something like this from another port earlier today should do, until
> this issue finally gets fixed in the compiler run deps.
> 
> 

Thanks!


Werner

Re: extractpdfmark build failure on 10.6

[Ken Cunningham]

something like this from another port earlier today should do, until this issue 
finally gets fixed in the compiler run deps.



> On Oct 27, 2018, at 23:55, Werner LEMBERG  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

extractpdfmark build failure on 10.6

[Werner LEMBERG]

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