Quantcast

Problems cross-compiling with clang 3.7 & 3.9 on 10.6

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Problems cross-compiling with clang 3.7 & 3.9 on 10.6

Mojca Miklavec-2
Hi,

After a long time I tried cross-compiling a few things on 10.6, but
most attempts failed:

> clang-mp-3.4 -arch ppc test.c -o test

[OK]

> clang-mp-3.7 -arch i386 test.c -o test

[OK]

> clang-mp-3.7 -arch ppc test.c -o test
ld: warning: ignoring file
/opt/local/libexec/llvm-3.7/bin/../lib/clang/3.7.1/lib/darwin/libclang_rt.osx.a,
missing required architecture ppc in file
ld: symbol dyld_stub_binder not found (normally in libSystem.dylib).
Needed to perform lazy binding to function _exit for architecture ppc
clang: error: linker command failed with exit code 1 (use -v to see invocation)

> clang-mp-3.9 test.c -o test
ld: library not found for -lto_library
clang: error: linker command failed with exit code 1 (use -v to see invocation)

> clang-mp-3.9 -arch i386 test.c -o test
ld: library not found for -lto_library
clang: error: linker command failed with exit code 1 (use -v to see invocation)

> clang-mp-3.9 -arch ppc test.c -o test
ld: library not found for -lto_library
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Any hints about how to fix these issues?

Any tickets I found that that remotely resembled problems with lto
have been closed.

With respect to ppc I probably just need to recompile the compiler
with some proper universal flag? Is there any chance to enable some of
that on the buildbot?

Mojca
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problems cross-compiling with clang 3.7 & 3.9 on 10.6

Mojca Miklavec-2
On 27 March 2017 at 17:14, Mojca Miklavec wrote:
> Hi,
>
> After a long time I tried cross-compiling a few things on 10.6, but
> most attempts failed:
>
>> clang-mp-3.4 -arch ppc test.c -o test
>
> [OK]

Plus another problem that I don't quite understand:

libtool: link: clang-mp-3.4 -Wimplicit -Wreturn-type
-Wdeclaration-after-statement -Wno-unknown-pragmas -arch ppc -isysroot
/Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -arch ppc
-isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -o
kpseaccess access.o  -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib
ld: absolute address to symbol ___stdoutp in a different linkage unit
not supported in _main from access.o
collect2: ld returned 1 exit status

Mojca
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problems cross-compiling with clang 3.7 & 3.9 on 10.6

Mojca Miklavec-2
On 27 March 2017 at 17:39, Mojca Miklavec wrote:

> On 27 March 2017 at 17:14, Mojca Miklavec wrote:
>> Hi,
>>
>> After a long time I tried cross-compiling a few things on 10.6, but
>> most attempts failed:
>>
>>> clang-mp-3.4 -arch ppc test.c -o test
>>
>> [OK]
>
> Plus another problem that I don't quite understand:
>
> libtool: link: clang-mp-3.4 -Wimplicit -Wreturn-type
> -Wdeclaration-after-statement -Wno-unknown-pragmas -arch ppc -isysroot
> /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -arch ppc
> -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -o
> kpseaccess access.o  -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib
> ld: absolute address to symbol ___stdoutp in a different linkage unit
> not supported in _main from access.o
> collect2: ld returned 1 exit status

I'm sorry, that's probably closely related to
    https://trac.macports.org/ticket/39052

I guess I forgot that I should not be using clang for cross-compiling for PPC.

I tried (not ever sure if that makes any sense):

sudo port -v -n upgrade --force libcxxabi +universal
universal_archs="x86_64 i386 ppc"

but I get another error:

ld: symbol dyld_stub_binder not found (normally in libSystem.dylib).
Needed to perform lazy binding to function _abort for architecture ppc



So I'll forget about clang & PPC. But it would still be nice to get
clang 3.9 working on 10.6.

Mojca
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problems cross-compiling with clang 3.7 & 3.9 on 10.6

Jeremy Huddleston Sequoia
In reply to this post by Mojca Miklavec-2

> On Mar 27, 2017, at 08:14, Mojca Miklavec <[hidden email]> wrote:
>
> Hi,
>
> After a long time I tried cross-compiling a few things on 10.6, but
> most attempts failed:
>
>> clang-mp-3.4 -arch ppc test.c -o test
>
> [OK]
IIRC, cfe just spawns llvm-gcc-4.2 when using -arch ppc in older versions.  I suspect 3.4 does that which is why it "works"


>> clang-mp-3.7 -arch i386 test.c -o test
>
> [OK]
>
>> clang-mp-3.7 -arch ppc test.c -o test
> ld: warning: ignoring file
> /opt/local/libexec/llvm-3.7/bin/../lib/clang/3.7.1/lib/darwin/libclang_rt.osx.a,
> missing required architecture ppc in file
> ld: symbol dyld_stub_binder not found (normally in libSystem.dylib).
> Needed to perform lazy binding to function _exit for architecture ppc
> clang: error: linker command failed with exit code 1 (use -v to see invocation)


>> clang-mp-3.9 test.c -o test
> ld: library not found for -lto_library
> clang: error: linker command failed with exit code 1 (use -v to see invocation)

>> clang-mp-3.9 -arch i386 test.c -o test
> ld: library not found for -lto_library
> clang: error: linker command failed with exit code 1 (use -v to see invocation)

>> clang-mp-3.9 -arch ppc test.c -o test
> ld: library not found for -lto_library
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
>
> Any hints about how to fix these issues?

What's the output of with '-v -Wl,-v'?


> Any tickets I found that that remotely resembled problems with lto
> have been closed.
>
> With respect to ppc I probably just need to recompile the compiler
> with some proper universal flag? Is there any chance to enable some of
> that on the buildbot?
>
> Mojca


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problems cross-compiling with clang 3.7 & 3.9 on 10.6

Mojca Miklavec-2
On 27 March 2017 at 22:26, Jeremy Huddleston Sequoia wrote:

>> On Mar 27, 2017, at 08:14, Mojca Miklavec wrote:
>>
>> Hi,
>>
>> After a long time I tried cross-compiling a few things on 10.6, but
>> most attempts failed:
>>
>>> clang-mp-3.4 -arch ppc test.c -o test
>>
>> [OK]
>
> IIRC, cfe just spawns llvm-gcc-4.2 when using -arch ppc in older versions.  I suspect 3.4 does that which is why it "works"

Thanks. (It nevertheless breaks at some other point, so it's still useless.)

I knew that ppc has never been supported properly, but there was this
crazy "clang on ppc tiger" project that just kept going and each
version of clang worked slightly better. I just checked and it seems
that the author apparently started working for Google in 2015 and
there were no commits to llvm/clang forks since 2014. I didn't realize
that the project actually "died" in the meantime.

>>> clang-mp-3.9 test.c -o test
>> ld: library not found for -lto_library
>> clang: error: linker command failed with exit code 1 (use -v to see invocation)
>>
>> Any hints about how to fix these issues?
>
> What's the output of with '-v -Wl,-v'?

> clang-mp-3.9 -v -Wl,-v test.c -o test
clang version 3.9.1 (tags/RELEASE_391/final)
Target: x86_64-apple-darwin10.8.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-3.9/bin
 "/opt/local/libexec/llvm-3.9/bin/clang" -cc1 -triple
x86_64-apple-macosx10.6.0 -Wdeprecated-objc-isa-usage
-Werror=deprecated-objc-isa-usage -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -discard-value-names -main-file-name test.c
-mrelocation-model pic -pic-level 2 -mthread-model posix
-mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2
-target-linker-version 136 -v -dwarf-column-info -debugger-tuning=lldb
-resource-dir /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.1
-fdebug-compilation-dir /Users/context-osx/app/texlive/svn/Build
-ferror-limit 19 -fmessage-length 175 -stack-protector 1 -fblocks
-fobjc-runtime=macosx-10.6.0 -fencode-extended-block-signature
-fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/Qr/QrzZQ3sbHSybp2W5GAvzYU+++TI/-Tmp-/test-afae7b.o -x c
test.c
clang -cc1 version 3.9.1 based upon LLVM 3.9.1 default target
x86_64-apple-darwin10.8.0
ignoring nonexistent directory "/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.1/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
 "/opt/local/libexec/llvm-3.9/bin/ld" -demangle -lto_library
/opt/local/libexec/llvm-3.9/lib/libLTO.dylib -dynamic -arch x86_64
-macosx_version_min 10.6.0 -o test -lcrt1.10.6.o -v
/var/folders/Qr/QrzZQ3sbHSybp2W5GAvzYU+++TI/-Tmp-/test-afae7b.o
-lSystem /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.1/lib/darwin/libclang_rt.osx.a
@(#)PROGRAM:ld  PROJECT:ld64-127.2
configured to support archs: i386 x86_64 ppc ppc64 armv6 armv7
Library search paths:
/usr/lib
/usr/local/lib
Framework search paths:
/Library/Frameworks/
/System/Library/Frameworks/
ld: library not found for -lto_library
clang: error: linker command failed with exit code 1 (use -v to see invocation)


Mojca
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problems cross-compiling with clang 3.7 & 3.9 on 10.6

Ken Cunningham Webuse
In reply to this post by Mojca Miklavec-2
It's been a few months since I went down this rabbit hole, but IIRC,
it worked a little better to build clang on ppc directly. 10.5 intel
fails to build PPC correctly due to the runtime library issues you
stumbled across. The highest i have been able to go is clang-3.6 on
ppc so far (building it on PPC, using clang-3.4). clang-3.7+ will not
build successfully, although llvm-3.7+ does build (wouldn't trust the
code it produces on PPC, though).

Libc++ works, but the exceptions don't work correctly still. But clang
> 3.4 works in a spotty fashion, and the produced binaries have
errors. llvm > 3.4 produces buggy ppc code that crashes easily.

I might hope to find a way to get clang-3.7 to output intermediate
code that gcc5 or gcc6 might further process (AKA llvm-4.2), but I
guess that seems pretty unlikely these days.

here's what I have working on 10.5 ppc at present:

LeopardG5:MacPorts-2.4.1 macportsdev$ port -v installed | grep clang
  clang-3.4 @3.4.2_12+analyzer platform='darwin 9' archs='ppc'
date='2016-11-08T21:25:19-0800'
  clang-3.6 @3.6.2_5+analyzer platform='darwin 9' archs='ppc'
date='2016-12-29T22:18:32-0800'
  clang_select @2_0 (active) platform='darwin 9' archs='noarch'
date='2016-10-02T00:17:54-0700'
LeopardG5:MacPorts-2.4.1 macportsdev$ port -v installed | grep llvm
  cctools @886_6+llvm33 (active) platform='darwin 9' archs='ppc'
date='2016-10-22T10:49:21-0700'
  ld64-127 @127.2_8+llvm33 (active) platform='darwin 9' archs='ppc'
date='2016-11-08T21:00:26-0800'
  llvm-3.3 @3.3_10 (active) platform='darwin 9' archs='ppc'
date='2016-10-02T17:27:59-0700'
  llvm-3.4 @3.4.2_11 (active) platform='darwin 9' archs='ppc'
date='2016-10-02T17:32:34-0700'
  llvm-3.6 @3.6.2_4 (active) platform='darwin 9' archs='ppc'
date='2016-12-29T19:47:09-0800'
  llvm-3.8 @3.8.1_0 (active) platform='darwin 9' archs='ppc'
date='2017-01-06T17:43:28-0800'
  llvm_select @2_0 (active) platform='darwin 9' archs='noarch'
date='2016-10-02T00:18:02-0700'
LeopardG5:MacPorts-2.4.1 macportsdev$ port -v installed | grep libc
  libcxx @3.9.0_0+universal (active) platform='darwin 9' archs='i386
ppc x86_64' date='2016-12-11T15:19:16-0800'
  libcxxabi @3.9.0_0+universal (active) platform='darwin 9'
archs='i386 ppc x86_64' date='2016-12-11T15:17:25-0800'
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problems cross-compiling with clang 3.7 & 3.9 on 10.6

Joshua Root-8
In reply to this post by Mojca Miklavec-2
On 2017-3-28 11:46 , Mojca Miklavec wrote:
> ld: library not found for -lto_library

Looks like ld is interpreting "-lto_library" as -l with a library name
of "to_library". No LTO support I guess.

- Josh
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problems cross-compiling with clang 3.7 & 3.9 on 10.6

Mojca Miklavec-2
In reply to this post by Ken Cunningham Webuse
On 28 March 2017 at 05:07, Ken Cunningham wrote:
> It's been a few months since I went down this rabbit hole, but IIRC,
> it worked a little better to build clang on ppc directly.

Just to clarify. I want to compile some software for multiple
architecture and provide backwards compatibility for as long back as
reasonably feasible and ideally not having to depend on "weird
hardware".

That means compiling on 10.6 for ppc, i386, x86_64. I don't want to
keep a real PPC around just for that, I'm not even sure how many users
there are. As long as I can build everything on a single VM, it
doesn't take any extra effort to do it. If I had to buy a PPC and
power it up each time for building ... no, but no thanks.

It's a collection of various (C/C++) tools. The big majority of those
tools doesn't require C++11, but I'm sure the situation will get
"worse" (or should I call it better?) each year.

I guess I could potentially ship libc++ or gcc's stdlibc++ along with
binaries, but I would like to avoid that. Once maintaining binaries
for PPC becomes too cumbersome, I'll just stop building for PPC. At
the moment building for PPC still works (with gcc 4.0 or 4.2 or
whatever that is) for everything but a tiny fraction of binaries which
I just exclude at the moment.

> 10.5 intel
> fails to build PPC correctly due to the runtime library issues you
> stumbled across. The highest i have been able to go is clang-3.6 on
> ppc so far (building it on PPC, using clang-3.4). clang-3.7+ will not
> build successfully, although llvm-3.7+ does build (wouldn't trust the
> code it produces on PPC, though).

It makes absolutely no sense that I try to use a compiler that has
never been designed or tested to produce binaries for PPC.

> Libc++ works, but the exceptions don't work correctly still. But clang
> 3.4 works in a spotty fashion, and the produced binaries have
> errors. llvm > 3.4 produces buggy ppc code that crashes easily.

While there are some tools that require C++11 (just two out of
hundreds this year), building against libc++ doesn't bring any added
value to start with. If I have to ship stdlib with binaries, I can
just as well ship a newer stdlibc++ that's known to work. But I would
more likely just drop support for PPC at that point (once the set of
non-C++11 tools becomes useless).

It's just that I completely forgot that clang isn't well suited for
PPC. I'm nowadays almost "hardwired" to try to use the latest and
greatest clang that I forgot that this is only a good idea for intel
processors.

Mojca
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problems cross-compiling with clang 3.7 & 3.9 on 10.6

Ken Cunningham Webuse

On 2017-03-28, at 2:18 AM, Mojca Miklavec wrote:

It makes absolutely no sense that I try to use a compiler that has
never been designed or tested to produce binaries for PPC.

It had always been a design goal for llvm to produce workable PPC code, but although close (lots of things do work) they never quite got there (Jeremy has most of the bugs outlined on the llvm bug reporter), and only quite recently announced (past few months) they were officially dropping the effort  (which unsurprisingly has reduced my enthusiasm for trying to get it to work).

While there are some tools that require C++11 (just two out of
hundreds this year), building against libc++ doesn't bring any added
value to start with.

When I started tinkering with it, as you know libc++ was the only way to get clang to support  c++11 --  until the recent changes in 3.9 allowed linking against  the newer libstdc++. But now it offers nothing.


For reliable c++11 cross-compiling to PPC at present the only thing I could point you towards was an effort to add -arch support to newer versions of gcc that I came across one evening on the web. 

Or, if you want, I can make one of my PPC machines available to you via ssh to compile and test your PPC code on. Dave already has access for some gtk stuff he was working on.

Sounds like you're not too interested in putting too much more time into this, so let me know if you actually would be interested in that.

K
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problems cross-compiling with clang 3.7 & 3.9 on 10.6

Mojca Miklavec-2
On 28 March 2017 at 17:37, Ken Cunningham wrote:

> On 2017-03-28, at 2:18 AM, Mojca Miklavec wrote:
>
> It had always been a design goal for llvm to produce workable PPC code, but
> although close (lots of things do work) they never quite got there (Jeremy
> has most of the bugs outlined on the llvm bug reporter), and only quite
> recently announced (past few months) they were officially dropping the
> effort  (which unsurprisingly has reduced my enthusiasm for trying to get it
> to work).
>
> While there are some tools that require C++11 (just two out of
> hundreds this year), building against libc++ doesn't bring any added
> value to start with.
>
> When I started tinkering with it, as you know libc++ was the only way to get
> clang to support  c++11 --  until the recent changes in 3.9 allowed linking
> against  the newer libstdc++. But now it offers nothing.

Has PPC support already been removed from LLVM sources?

> For reliable c++11 cross-compiling to PPC at present the only thing I could
> point you towards was an effort to add -arch support to newer versions of
> gcc that I came across one evening on the web.

Thanks. I actually knew that gcc was able to compile C++11 code. I
never thought about cross-compiling with gcc, even though I guess that
I might even be able to install a gcc cross-compiler on the latest OS?
:)

What worries me though is how to properly distribute stdlibc++ along
with binaries. If there's just one file that I need to copy, that
might even be doable. But if it gets too annoying, I might not be
willing to spend too much effort.

> Or, if you want, I can make one of my PPC machines available to you via ssh
> to compile and test your PPC code on. Dave already has access for some gtk
> stuff he was working on.
>
> Sounds like you're not too interested in putting too much more time into
> this, so let me know if you actually would be interested in that.

I do have a super slow PPC notebook with G4 and hardly enough disk
space to actually install anything reasonable on it (60 GB). That's
enough for testing once in a long while.

The thing is: I want to set up a buildbot job to do the compiling for
me (it's pretty heavy for a PPC box though, it needs several hours to
complete on an old box). I know I need to check whether the binaries
work at some point, but I don't see any added benefit of actually
compiling natively as compered to compiling on a 10.6 VM. There will
be an increasing number of C++11 software over the years, but I don't
believe that compiling natively would really help here. If I'm wrong,
please correct me.

But to be fair, the other developers actually decided to drop support
for anything but the officially supported macOS versions. What I'm
working on is a fallback options for those who cannot (or don't want
to :) upgrade. And dropping support for PPC has kind of been on the
table for quite a while now. After all, the same software is also
provided by MacPorts anyway (only updated much less frequently) and
the few PPC users can even compile it themselves, so it's not so
horribly important to keep providing the binaries upstream.

As far as motivation goes: I would be more interested in making
MacPorts better for PPC users than in compiling a single piece of
software for PPC. I will support PPC just because it doesn't really
cost that much extra effort if I build for one or three architectures
at the same time.

Mojca
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

dvips from texlive-basic broken?

Andrew L. Moore
In reply to this post by Joshua Root-8
Only by moving aside dvips(1) from MacPorts texlive-basic  and using dvips(1) from MacTeX 2016 distribution, was I able to upgrade to MacPorts asymptote 2.41 vector graphics package.

asymptote 2.40 was installed about a month ago without any issues.  Anyone care to confirm or dispute this claim?  texlive-basic doesn’t appear to have been updated since December 2016, so it doesn’t make a lot of sense, but I’ve verified the problem and solution on two independent systems…  Thank you!

MacOS 10.12.4,  Xcode 8.3.1, MacPorts via git HEAD.
-AM

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dvips from texlive-basic broken?

Mojca Miklavec-2
On 13 April 2017 at 01:42, Andrew Moore wrote:
> Only by moving aside dvips(1) from MacPorts texlive-basic  and using dvips(1) from MacTeX 2016 distribution, was I able to upgrade to MacPorts asymptote 2.41 vector graphics package.
>
> asymptote 2.40 was installed about a month ago without any issues.  Anyone care to confirm or dispute this claim?  texlive-basic doesn’t appear to have been updated since December 2016, so it doesn’t make a lot of sense, but I’ve verified the problem and solution on two independent systems…  Thank you!


I'm not on 10.12 yet, but asymptote builds for me even if I remove
dvips from MacPorts.

This comes out of the blue, but did you perhaps update ghostscript?
MacPorts currently ships version 9.19. Version 9.21 has been released
very recently (see http://pages.uoregon.edu/koch/), but I didn't
update it and if you did, this could explain the reason, even if I'm
currently not aware of how that could have happened. Both asymptote
and dvips would use whatever gs comes first in PATH (so they might
take it from the system rather than from MacPorts if you installed it
manually). You should provide at least some logs to see what exactly
is going on. (You could also open a ticket, even if it turns out to be
invalid.)

Mojca
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dvips from texlive-basic broken?

Ryan Schmidt-24
In reply to this post by Andrew L. Moore

> On Apr 12, 2017, at 18:42, Andrew Moore <[hidden email]> wrote:
>
> Only by moving aside dvips(1) from MacPorts texlive-basic  and using dvips(1) from MacTeX 2016 distribution, was I able to upgrade to MacPorts asymptote 2.41 vector graphics package.
>
> asymptote 2.40 was installed about a month ago without any issues.  Anyone care to confirm or dispute this claim?  texlive-basic doesn’t appear to have been updated since December 2016, so it doesn’t make a lot of sense, but I’ve verified the problem and solution on two independent systems…  Thank you!
>
> MacOS 10.12.4,  Xcode 8.3.1, MacPorts via git HEAD.

Hmm. Buildbot was able to build 2.41 just fine with MacPorts texlive:

https://packages.macports.org/asymptote/

What error messages did you encounter?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dvips from texlive-basic broken?

Andrew L. Moore
In reply to this post by Mojca Miklavec-2
I did verify that ghostscript it is not causing the problem, and have now completely rebuilt TeX and confirmed that MacPorts dvips is broken on my system with regard to building asymptote documentation (it exits with trap 6 - presumably SIGABRT).  

The only other recent change that I can think of is Xcode was upgraded to 8.3.1…
-AM

> On Apr 13, 2017, at 1:20 AM, Mojca Miklavec <[hidden email]> wrote:
>
> On 13 April 2017 at 01:42, Andrew Moore wrote:
>> Only by moving aside dvips(1) from MacPorts texlive-basic  and using dvips(1) from MacTeX 2016 distribution, was I able to upgrade to MacPorts asymptote 2.41 vector graphics package.
>>
>> asymptote 2.40 was installed about a month ago without any issues.  Anyone care to confirm or dispute this claim?  texlive-basic doesn’t appear to have been updated since December 2016, so it doesn’t make a lot of sense, but I’ve verified the problem and solution on two independent systems…  Thank you!
>
>
> I'm not on 10.12 yet, but asymptote builds for me even if I remove
> dvips from MacPorts.
>
> This comes out of the blue, but did you perhaps update ghostscript?
> MacPorts currently ships version 9.19. Version 9.21 has been released
> very recently (see http://pages.uoregon.edu/koch/), but I didn't
> update it and if you did, this could explain the reason, even if I'm
> currently not aware of how that could have happened. Both asymptote
> and dvips would use whatever gs comes first in PATH (so they might
> take it from the system rather than from MacPorts if you installed it
> manually). You should provide at least some logs to see what exactly
> is going on. (You could also open a ticket, even if it turns out to be
> invalid.)
>
> Mojca

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dvips from texlive-basic broken?

Mojca Miklavec-2
On 13 April 2017 at 16:56, Andrew Moore wrote:
> I did verify that ghostscript it is not causing the problem, and have now completely rebuilt TeX and confirmed that MacPorts dvips is broken on my system with regard to building asymptote documentation (it exits with trap 6 - presumably SIGABRT).
>
> The only other recent change that I can think of is Xcode was upgraded to 8.3.1…

Please open a ticket and attach the full log.

Mojca
Loading...