Re: Can brew and port be used on the same system?

OK Mike, If you care to try out a MacPorts build of OpenJK yourself, the Portfile is in reasonable working condition. > I have not yet added in all the deps -- this builds through on my system. I have SDL1.2 and SDL2 installed, and

Re: Can brew and port be used on the same system?

> > Oh -- did you know that the filenames displayed in finder do not have to have > any correlation to the filenames as seen by the shell and other programs? Or > that Finder is perfectly happy to display two different "files with the same > name"? In fact, I did notice that, and was rather

Re: Can brew and port be used on the same system?

It sounds like you got a build working already, so you probably done care about this anymore, but this Portfile with it's associated patches actually does build the port. I have not added in the deps yet. It builds just fine on my

Re: Can brew and port be used on the same system?

I'm about 95% finished a Portfile for OpenJK. It doesn't take but a few minutes to make one for a port like this. It's fully built and sitting on my hard drive. Just working out a patchfile or two for an openGL glitch on MacOS that is widely known, and I'll test it out. If it works, I'll send

Re: Failure to build glib2 as part of xsane dependency

l the broken llvm40 version? > On Step 7, it complains about conflict between llvm39 and llvm 40. > > Thanks > > El 2017-05-05, a las 19:05, Ken Cunningham escribió: > >> >> On 2017-05-04, at 12:32 PM, ges...@ftp83plus.net wrote: >> >>>> Hel

Re: Failure to build glib2 as part of xsane dependency

On 2017-05-04, at 12:32 PM, ges...@ftp83plus.net wrote: >> Hello there, >> >> I needed to reinstall MacPorts on Snow Leopard, and followed the >> instructions in LibcxxOnOlderSystems (I recall some ports wouldn't compile >> properly without it), including the experimental steps. Only there,

Re: Do I need +universal to be used when installing ports?

WINE is the only thing that comes to mind that really only runs i386 even on x86_64. And that triggers all it’s deps to be i386 as well. K > On Apr 28, 2017, at 8:06 AM, Barrie Stott wrote: > > I have an iMac as my only computer and am near the beginning of installing

Re: stuck in loop with restore_ports.tcl migrating to macOS Sierra (10.12.1)

>> >> If so, the workaround for that was to make a local copy of Availability.h in >> /opt/local/include and edit it there. >> I'd still reinstall Xcode and the command line tools -- but you don't have a rogue Availability.h sitting /opt/local/include do you? If so, that's your trouble. K

Re: stuck in loop with restore_ports.tcl migrating to macOS Sierra (10.12.1)

Availability.h with 'defined(__has_feature)’ > which should really be 'defined(__has_feature)’ > again, as discussed in ticket #48471? > > If so, the workaround for that was to make a local copy of Availability.h in > /opt/local/include and edit it there. > > &

Re: stuck in loop with restore_ports.tcl migrating to macOS Sierra (10.12.1)

t; /usr/include/pthread.h, namely: >>> >>> /usr/include/pthread.h:423:1: error: C++ requires a type specifier for >>> all declarations >>> __SWIFT_UNAVAILABLE_MSG("Use lazily initialized globals instead") >>> ^ >>> /usr/include/pth

Re: stuck in loop with restore_ports.tcl migrating to macOS Sierra (10.12.1)

rejects g++ 2.7.2 which doesn't have , only a >pre-standard iostream.h. */ >#include > > I just was about to try to do that >> On Nov 2, 2016, at 11:46 PM, Ken Cunningham >> <ken.cunningham.web...@gmail.com> wrote: >>

Re: 10.6.8 and ffmpeg

Wouldn’t it just be a treat if Jeremy fixed libsdl2’s code and this all went away :> Ken > On Nov 2, 2016, at 8:49 PM, Al Varnell wrote: > > On Nov 2, 2016, at 8:43 PM, Ryan Schmidt wrote: >> On Nov 2, 2016, at 10:41 PM, Al Varnell wrote: >>> On Nov 2, 2016, at 8:38 PM,

Re: stuck in loop with restore_ports.tcl migrating to macOS Sierra (10.12.1)

no, it just points into a pthread folder. let me try building (from source) a port that triggers your err. > On Nov 2, 2016, at 8:40 PM, Ken Cunningham <ken.cunningham.web...@gmail.com> > wrote: > > hmmm, So do I > > lrwxr-xr-x 1 root wheel 17 31 Oct 09:43 &

Re: stuck in loop with restore_ports.tcl migrating to macOS Sierra (10.12.1)

rw-r--r-- 1 root wheel 19414 Sep 19 17:53 /usr/include/pthread/pthread.h > >> On Nov 2, 2016, at 11:26 PM, Ken Cunningham <ken.cunningham.web...@gmail.com >> <mailto:ken.cunningham.web...@gmail.com>> wrote: >> >> /Applications/Xcode.app/Contents/Developer/Pl

Re: stuck in loop with restore_ports.tcl migrating to macOS Sierra (10.12.1)

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/pthread.h:423:25: error: expected parameter declarator So I'd open that file and look at line 423 and see if you can figure out what is happening. If this is only you, then it’s

Re: stuck in loop with restore_ports.tcl migrating to macOS Sierra (10.12.1)

Murray, I note the error in your log looks somewhat like this error in trac: __SWIFT_UNAVAILABLE_MSG … Ken___ macports-users mailing list macports-users@lists.macosforge.org

Re: 10.6.8 and ffmpeg

> > Why would you do that? It can be downloaded from the Apple developer web site > (in a newer version of Xcode). Well, everyone seems to feel it’s way to difficult to expect a user to do that, so I’m trying to help you come up with an easier way. Of course, I just downloaded the darned

Re: 10.6.8 and ffmpeg

> That's just: > > #if MAC_OS_X_VERSION_MAX_ALLOWED < 1070 > # error SDL for Mac OS X must be built with a 10.7 SDK or above. > #endif /* MAC_OS_X_VERSION_MAX_ALLOWED < 1070 */ > that’s what I meant when I referred to using availability macros - sorry if it was the wrong term. Mojca did an

Re: stuck in loop with restore_ports.tcl migrating to macOS Sierra (10.12.1)

here’s what I do when stuff like this happens check your path `printenv` and see if it’s set correctly cat ~/.profile try “which clang” and “clang —version” try writing up a very simple “hello.c” source file and see if it compiles (with the -v option to see what happens) and whether the

Re: 10.6.8 and ffmpeg

On 2016-11-02, at 2:03 AM, Jeremy Huddleston Sequoia wrote: > Do you know *why* it is requiring the 10.7 SDK to build? Why can't libsdl2 > use the 10.6 SDK effectively? > I took a quick look at the code. It has a lot of AVAILABILITY_ macros in it, a few mentioning 10.7, most of them

Re: 10.6.8 and ffmpeg

and 10.6. One Raimue explained how to do this, I set this up for my own use a while back, and shared it on github for others to use: https://github.com/ken-cunningham-webuse/TigerPorts https://github.com/ken-cunningham-webuse/LeopardPorts https://github.com/ken-cunningham-webuse/SnowLeo

Re: 10.6.8 and ffmpeg

Oh — I see that there’s a lot of build info in docs/ README-macosx.md in there it says you need minimum Xcode 4.6 and the 10.7 SDK (maybe that’s why macports-clang-3.7 worked for me?) and a lot more info that I didn’t read fully through. Ken > On Oct 30, 2016, at 2:28 PM,

Re: 10.6.8 and ffmpeg

> > Agreed, the problem here is with libsdl2. We need to understand what the > problem is on > 10.6 at least and either help upstream to fix it or fix it ourselves. Dave, I may not be seeing the entire picture (often happens!), but I don’t think there is actually a problem on 10.6. It uses

Re: 10.6.8 and ffmpeg

> I can do that on the buildbot machines, and we can write the libsdl2 > portfile so that it uses that SDK if available and instructs the user how to > download and install it if it's not yet there. The portfile is already written like that. Also, see:

Re: 10.6.8 and ffmpeg

> > If sdl2 can be built on Snow Leopard using a copy of the 10.7 SDK obtained > from a later Xcode, and that sdl2 then works ok on Snow Leopard, then I'd be > happy if we could come up with an official way to support that, and then we > could do that on the buildbot, which would cover a lot

Re: 10.6.8 and ffmpeg

s/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_libsdl2/libsdl2/work/SDL2-2.0.5': > configure:3286: error: C compiler cannot create executables > See `config.log' for more details > > > sh-3.2# /Users/rlhamil/bin/vers # a script of mine that

Re: 10.6.8 and ffmpeg

@1.2.12_0 (active) platform='darwin 10' archs='x86_64' libsdl_net @1.2.8_0 (active) platform='darwin 10' archs='x86_64' libsdl_ttf @2.0.11_0 (active) platform='darwin 10' archs='x86_64' On 2016-10-29, at 7:17 AM, Ryan Schmidt wrote: > >> On Oct 29, 2016, at 12:05 AM, Ken C

Re: Libc++ on Snow Leopard

Jasper, I've been using this for months now, and I think I've worked through most of the hiccups, often with Jeremy's help. If you get stuck or have any questions or issues, please don't hesitate to ask, either on the list here if you want, or offline to me directly if you prefer to conceal

Re: webkit-gtk2: Will it ever be fixed?

Thanks for posting your worries instead of just giving up. I will leap here to assume you actually do want help to get this to work, and you're not just venting frustration. You have to realize that with the kind of information you've volunteered so far, no-one on Earth is likely to be able to

Re: gcc6 build failed on Snow Leopard

>> >> on the other, the checksum differs and it says comparison successful. I'm a bit curious why the comparison is successful and the build proceeds when the checksum differs like that ... I'm actually not sure which build attempt is the more valid. Perhaps it is supposed to fail, and the

Re: gcc6 build failed on Snow Leopard

Weird. Is this on the same exact machine? on one hand the checksum differs and it says bootstrap fails. on the other, the checksum differs and it says comparison sucessful. No difference in file system / case sensitivitiy? ? race condition involving parallel build threads? on one hand the

Re: python, port select and group

> This problem was brought up previously on this list. You may have > uninstalled python34 at some point while it was selected; the "port > select" code doesn't handle this properly and leaves dangling symlinks. There is also a very useful port (for me) called "symlinks" that helps find and

Re: gtk2 and gtk3 ports and +x11 vs +quartz variant worries

> > > These are all legitimate and in my experience tend to come from trying to > switch from building +x11 to building +quartz > without "cleaning the slate" as it were. I always do this when switching > like this (say with gimp2 that can build > either way). > > sudo port install gimp2

gtk2 and gtk3 ports and +x11 vs +quartz variant worries

Is there a wiki page I missed perhaps for how to sort out the conflicting requirements for +x11 and +quartz in the various gtk port implementations? I understand the basic reasons for this, but I quite frequently seem to find myself on the wrong side of the line with this. Perhaps there is no

Re: Subversion checkout failed...?

looks like v8 is here now: https://github.com/v8/v8 K On 2016-10-08, at 8:07 AM, Ryan Schmidt wrote: > >> On Oct 8, 2016, at 9:55 AM, Carlo Tambuatco wrote: >> >> Made the leap to Sierra yesterday and a few ports have had trouble >> downloading. >> >> The v8 and

Re: LLVM not supported on Sierra?

llvm-3.5 is not supported on macOS Sierra or newer. I don't think llvm-3.5 is a version to be used. One of the Apple engineers frequently steers people to newer versions. Why not llvm-3.7, 3.8, or 3.9? On Sun, Oct 2, 2016 at 8:05 PM, Dave Horsfall wrote: > Doing a "port

Re: osxfuse @3.5.0 build error - fixed

> > I notice in the development tree there is some activity on this file 2 days > ago: > > https://github.com/osxfuse/support/tree/support/osxfuse-3/mount_osxfuse. > > mount_osxfuse.c (mount_osxfuse) Fix build warning on Mac OS X 10.6 > So that fixed the osxfuse build on 10.6 for me

Re: osxfuse @3.5.0 build error

> > cc1: warnings being treated as errors > /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_fuse_osxfuse/osxfuse/work/osxfuse-osxfuse-cc7d953/support/mount_osxfuse/mount_osxfuse.c: > In function 'send_fd': >

Re: osxfuse @3.5.0 build error

> > info:build pbxcp: mount_osxfuse: No such file or directory > :info:build pbxcp: mount_osxfuse: No such file or directory > :info:build CpResource > :info:build The following build commands failed: > :info:build mount_osxfuse: > :info:build CompileC >

Re: fetching of some ports fails, but you can wget them from the same URL

That explains it. The port I remembered failing to fetch from a few weeks ago turns out to have been the older version of hexchat, I recalled sometime later this morning. Ken On 2016-09-27, at 3:28 PM, Rainer Müller wrote: > On 2016-09-27 15:45, Ken Cunningham wrote: >> I'v

fetching of some ports fails, but you can wget them from the same URL

I've noticed this behaviour a few times recently, most recently today with hexchat, but this is not the only example. Trying to get a file using macports' fetch fails, but you can manually wget it without trouble. I'm not sure if it's an SSL certificate thing, or why this is happening,

Re: LibCxxOnOlderSystems - and more software that is pushing for gcc

> > Why would the Fortran compiler link its build products against > libstdc++? Are you seeing this behavior? > Please provide evidence that these ports are actually using g++. If they > are, then they should be fixed to not do so. If they are not and are > only using gcc and/or gfortran, then

Re: LibCxxOnOlderSystems - and more software that is pushing for gcc

> > The problem is not really about libc++; it's about mixing multiple C++ > runtimes. Indeed. What is happening exactly on my MacPros running 10.11, I wonder? Software installed by macports on 10.11 is using clang++ (mostly) and g++ (sometimes). clang++ is linking against libc++, and g++ is

LibCxxOnOlderSystems - and more software that is pushing for gcc

I realize I asked this a bit ago about qemu, and received a very reasonable big caution regarding any attempt to combine gcc of any version on a system set up with LibCxxOnOlderSystems... but I just thought I'd mention that a few more fairly common ports appear to be failing to install without

Re: osxfuse @3.5.0 build error

and sometimes because of the tremendous support by people like jeremy and many others, macports can build things that don’t exist out there in the world — like a current version of OpenSCAD or Widelands that runs on 10.6, for example. or versions of software you can customize to your liking,

Re: osxfuse

On 2016-09-23, at 12:57 PM, Raoul MEGELAS wrote: > info:build OSXFUSEBuildTool(): building OSXFUSE kernel extension > and tools > :info:build xcrun: error: missing DEVELOPER_DIR path: > :info:build OSXFUSEBuildTool() failed: xcodebuild cannot build configuration > Release. Looks

Re: how to maintain multiple active versions of a port (e.g. octave)?

> > One last question … can you give me a quick idea of how much work would be > involved in me attempting to locally implement the first approach you > mentioned (different ports for different versions of octave). That is, > starting with the files for the 3.8.2 revision of the octave port,

Re: Can't install qt4?

version, which of course wouldn't work due to the HTMl. Best, Ken On 2016-09-21, at 6:38 PM, [ftp83plus] wrote: > Hmmm, I get: > > sudo patch patch unexpectedly ends in middle of line > patch: Only garbage was found in the patch input. > > > El 2016-09-21, a las

Re: Can't install qt4?

the part above, as it's very short :> Best, K On 2016-09-21, at 6:38 PM, [ftp83plus] wrote: > Hmmm, I get: > > sudo patch patch unexpectedly ends in middle of line > patch: Only garbage was found in the patch input. > > > El 2016-09-21, a las 13:40, Ken Cunningham

Re: Can't install qt4?

t; > Would you point me to a clear explanation please? > > El 2016-09-17, a las 21:08, Ken Cunningham escribió: > >> Hi Pat, >> >> just rebuilt it to make sure it's all still good with the current port mix >> -- indeed, it built without trouble, with the

Re: Qt 5.x and OS X 10.6

On 2016-09-20, at 12:54 PM, René J.V. Bertin wrote: > That's a Qt bug you should report if 5.4.2 is still supposed to install and > work on 10.7! Rene, I see I made an error there -- I just tried again to install 5.4.2 on 10.7 and it installed. I must have been slightly mixed up when I

Re: Qt 5.x and OS X 10.6

I think this might be progress. Fixed the libstdc++ linking (my fault, sorta, not theirs -- had to do the -std=libc++ in the CXX flags that is pervasive on the LibCxxOnOlderSystems machine). I note this 'platform plugin' issue was all over the 'net when 5.4 came out a while back, so I

Re: Qt 5.x and OS X 10.6

Thanks, I tried 10.7 first, but 5.4.2 would not install due to this message. Ergo moved up the chain to the next machine I had in line. >> Symbol not found: _NSPreferredScrollerStyleDidChangeNotification > It would probably be possible to do this in the mkspec itself, and/or a > module.pri

Re: Can't install qt4?

Hi Pat, just rebuilt it to make sure it's all still good with the current port mix -- indeed, it built without trouble, with the patch I referenced. It took about two and a half hours, though. If you get stuck and it won't build for you, let me know and I'll send you a link to a binary. ken

Re: User for startupitem.executable

Here's a snippet from another port that might help: startupitem.create yes startupitem.netchange yes if {[getuid] == 0} { startupitem.executable ${prefix}/sbin/asterisk -d -U asterisk -G asterisk } else { startupitem.executable ${prefix}/sbin/asterisk -d } and there is a

Re: Can't install qt4?

Pat, look here for instructions on how to install qt4 on systems upgraded with LibCxxOnOlderSystems. There is a patch there I submitted about a month ago, and your issue is likely the same kind of issue I had, given similar systems. It is labelled as

Re: qemu, and using gcc45+ compilers on systems set up with LibCxxOnOlderSystems and libc++

> Someone else can elaborate if they want, but all I'll say at the moment is > that we have encountered an obscene amount of trouble involving g++, > libstdc++, and libc++, and a long time ago we basically decided that g++ was > dead to us. > > vq _That_ is exactly what has stopped me from

qemu, and using gcc45+ compilers on systems set up with LibCxxOnOlderSystems and libc++

I would like to try building qemu, but it doesn't seem to be able to build with clang-3.7 or clang-3.8 (on 10.68 with LibCxxOnOlderSystems and libc++) the error for both :info:configure ERROR: Your compiler does not support the __thread specifier for :info:configureThread-Local

Re: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

FYI - the gtk3 upgrade does ultimately proceed normally on 10.6, once the LibCxxOnOlderSystems toolchain is repaired, per the separate instructions I posted. The problem was not with gtk specifically, but the toolchain it appears. Ken $ sudo port upgrade gtk3 ---> Computing dependencies

LibCxx on older systems toolchain blew up on 10.6 -- and fixed -- WAS Re: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

stalls and appears to be a coherent toolchain that works again (with clang-3.8, llvm-3.8). Best, Ken On 2016-08-29, at 1:45 AM, Mojca Miklavec wrote: > On 28 August 2016 at 23:21, Ken Cunningham wrote: >> OK - I see what happened. >> >> All traces of llvm37 have been

Re: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

OK - I see what happened. All traces of llvm37 have been from the new ld64 portfile. and so when the porfile saw my requested +llvm37, it saw that as no llvm variant, and defaulted to llvm34. And now my toolchain is looking pretty inoperable. there isn't an llm37 option in the ld64 portfile

Re: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

. ... have to do a better fix once I figure out what's happening here. -- K > > and that looks to me like the correct mixture. > > Ken > > > > > On 2016-08-28, at 7:52 AM, Ken Cunningham wrote: > >> I note that ld64-latest, ld64-136, a

Re: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

86_64' ld64-latest @264.3.102_2+llvm34 platform='darwin 10' archs='x86_64' and that looks to me like the correct mixture. Ken On 2016-08-28, at 7:52 AM, Ken Cunningham wrote: > I note that ld64-latest, ld64-136, and cctools were all updated just now. _

Re: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

AM, Ken Cunningham wrote: > I'll try later this afternoon to update my own gtk3 on the same system and > let you know what happens. > > Looks like it might be just your ld64* port that is dysfunctional - I suppose > we could make up an example that tests the linker, like w

Re: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

I'll try later this afternoon to update my own gtk3 on the same system and let you know what happens. Looks like it might be just your ld64* port that is dysfunctional - I suppose we could make up an example that tests the linker, like we did for clang, and see if that segfaults. Sorry I don't

Re: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

to build and run, you do need to keep your wits about you. K On 2016-08-26, at 9:13 AM, Brandon Allbery wrote: > > On Fri, Aug 26, 2016 at 12:09 PM, Ken Cunningham > <ken.cunningham.web...@gmail.com> wrote: > There must be a more elegant answer / way to do this, thou

Re: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

Nope - your clang-3.7 is working, it appears. Thanks for checking. ?? K On 2016-08-26, at 10:08 AM, [ftp83plus] wrote: > Here it the output: http://pastebin.com/JJ4iUjPU > > El 2016-08-26, a las 12:55, Ken Cunningham escribió: > >> Hmm. >> >> Would you

Re: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

ut it's a > bit on the slow and noisy side > > > El 2016-08-26, a las 12:13, Brandon Allbery escribió: > >> >> On Fri, Aug 26, 2016 at 12:09 PM, Ken Cunningham >> <ken.cunningham.web...@gmail.com> wrote: >> There must be a more elegant answ

Re: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

Yikes. Clang is segfaulting on you again, eh? Do I assume you're still using the libc++ upgrade for older systems on snow leopard? This has happened to me a couple of times, as you know from previous discussions. Try writing up and running just a simple clang compilation on a five-line "hello,

Re: Updating tk failed on Snow Leopard

Hi Richard, I have tk 8.6.6 running on snow leopard, but with +x11 (and not universal, but x86_64) $ port -v installed tk The following ports are currently installed: tk @8.6.6_0+x11 (active) platform='darwin 10' archs='x86_64' for what that's worth. I installed it with clang-3.7, and my

Re: X11 and QD name space conflicts as they apply to webkit2-gtk on snowleopard

again, Ken On 2016-08-15, at 4:36 PM, David Evans wrote: > On 8/15/16 3:15 PM, Ken Cunningham wrote: >> I'm attempting to build Epiphany on SnowLeopard with libc++ installed, as >> Snow Leopard has no up-to-date browser options available any longer. > Thanks for your repor

X11 and QD name space conflicts as they apply to webkit2-gtk on snowleopard

I'm attempting to build Epiphany on SnowLeopard with libc++ installed, as Snow Leopard has no up-to-date browser options available any longer. Epiphany uses webkit2-gtk, and with some minor fixes, webkit2-gtk does build on snow leopard. But there are name space conflicts between X11 and QD, so

Re: clang 3.4 can't be configured (part of a selfupdate)

Pat, I seemed to have none of these issues... but I installed libomp-universal on my x86_64 compatible mac. libomp @3.8.1_0-universal (active) platform='darwin 10' archs='x86_64' And so it remains. That seems to have been the main reason I didn't run into any of the issues you have run

Re: clang 3.4 can't be configured (part of a selfupdate)

Interestingly, I just went to update my libmacho and libunwind to the universal variants given this conversation (already did the cxx and cxxabi ports) -- but oddly, perhaps, this seemingly fully functional 10.6.8 /libc++ system with clang-3.8, all installed through macports, has neither

Re: clang 3.4 can't be configured (part of a selfupdate)

>>> El 29 jul 2016, a las 16:45, Lawrence Velázquez escribió: >>> >>>> On Jul 29, 2016, at 1:35 AM, Ken Cunningham wrote: >>>> >>>>> /opt/local/bin/clang++-mp-3.3 -pipe -Os -stdlib=libc++ -arch i386 >>>>> -mmacosx-v

Re: clang 3.4 can't be configured (part of a selfupdate)

> > I followed the instructions for full uninstall: > https://guide.macports.org/chunked/installing.macports.uninstalling.html That is infinitely better, and gets all the other bits and pieces that might cause trouble. > > this is the only occurence of "build_arch" in macports.conf, and is

Re: clang 3.4 can't be configured (part of a selfupdate)

> > Move your opt folder out of the way > > sudo mv /opt /opt-junked > Oh dear - this step is not quite right - I'm very sorry about that. There could be (and probably are) other things in your /opt folder that you don't want to move. If you did that, please move it back ( sudo mv

Re: clang 3.4 can't be configured (part of a selfupdate)

On 2016-07-29, at 7:57 AM, [ftp83plus] wrote: > SoI would have to 0- remove said files 1- reinstall MacPorts, Yes > 2- correct the macports.conf to replace x86 by x86_64 architecture No, don't think so. My macports.conf has build_arch x86_64 near the top -- I installed macports two

Re: clang 3.4 can't be configured (part of a selfupdate)

you search for these ports, reset your macports.conf and variants.conf to the default settings, delete the /usr/lib files listed above, and follow the instructions carefully. Hope this helps. K On 2016-07-28, at 10:35 PM, Ken Cunningham wrote: > Hi, > > There are many here sma

Re: clang 3.4 can't be configured (part of a selfupdate)

log >> Error: The following dependencies were not installed: libomp llvm-3.8 >> To report a bug, follow the instructions in the guide: >> http://guide.macports.org/#project.tickets >> Error: Processing of port clang-3.8 failed > > > Should I open a new topic for this partic

Re: question about OpenSCAD 2015.03 on Snow Leopard, and a home-built libc++ package installer

I would indeed have preferred to put libc++ and libc++abi into the app bundle -- but all the other dylibs linked against them were hard-coded to look for these two libraries in the /usr/lib directory. So I tried "install_name_tool'ing" all these libraries to redirect them to a bundled copy of