Re: compilers on Lion

On 2018-09-08, at 10:45 PM, Werner LEMBERG wrote: > > Ken, > > > What about adding this your explanation to the `LibcxxOnOlderSystems' > page? In particular, people who are mainly interested in porting C++ > GNU software to the Mac (and using it, of course) should rather stay > with libstdc

re: compilers on Lion

> Folks, > > > macports newbie here :-) > > I'm running a Lion box and I'm running macports from git, which works > just fine. I've followed the advice on LibcxxOnOlderSystems and did > > cxx_stdlib libc++ > buildfromsourcealways This is a reasonable choice for Lion, a

Re: rdepof:wine-devel +x11 +universal fails on installing xattr

On 2018-09-07, at 5:33 PM, Ryan Schmidt wrote: > I understand that you are saying that, but I'm not convinced that's desirable > behavior. > > What criteria do you propose to use to exclude the dependency? The dependency > is written "bin:xattr:xattr". Do you propose to exclude all bin (and

Re: rdepof:wine-devel +x11 +universal fails on installing xattr

On 2018-09-07, at 1:47 PM, Gijs Vermeulen wrote: > > Gijss-MacBook-Pro:~ gverm$ which xattr > /usr/bin/xattr > > So I'm not sure what could be wrong. > > Regards, > Gijs Maybe you're just being a bit too fancy. I also see `xattr` listed as an rdepof:wine but I know I don't need it to build or

Re: cctools fails to build on Snow Leopard

On 2018-09-02, at 2:49 PM, Riccardo Mottola wrote: > Hi, > > > On 09/02/18 17:08, Ken Cunningham wrote: >> As part of the LibcxxOnOlderSystems instructions, you can (must) build >> cctools against newer llvm headers, but forcing the build with clang-3.4: >> >

Re: cctools fails to build on Snow Leopard

On 2018-09-02, at 1:10 PM, Riccardo Mottola wrote: > Hi Ken, > > I did not "force" this configuration at all - I am just upgrading, so port > selected this heade/compiler combination by itself! > > Riccardo You're right. I was mistakenly thinking you had done that. I think at some point you

Re: cctools fails to build on Snow Leopard

'2018-08-19T19:49:33-0700' Best, Ken On 2018-09-02, at 7:55 AM, Ken Cunningham wrote: > > usr/bin/gcc-4.2 -Os -std=gnu99 -Os -DLTO_SUPPORT -g -I../../include -Wall > > -D_MACH_I386_THREAD_STATUS_FPSTATE_LEGACY_FIELD_NAMES_ > > -D_ARCHITECTURE_I386_FPU_FPSTATE_LEGA

re: cctools fails to build on Snow Leopard

> usr/bin/gcc-4.2 -Os -std=gnu99 -Os -DLTO_SUPPORT -g -I../../include -Wall > -D_MACH_I386_THREAD_STATUS_FPSTATE_LEGACY_FIELD_NAMES_ > -D_ARCHITECTURE_I386_FPU_FPSTATE_LEGACY_FIELD_NAMES_ -I/opt/local/include > -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_ma

Re: Keeping selected ports to a previous version

On 2018-07-02, at 11:07 AM, Ken Cunningham wrote: > Each repository needs to have the proper structure -- a main folder, with > subfolders that match MacPorts' repo structure, and then ports in there. I should say one more thing. Each repository needs a proper structure, but it do

Re: Keeping selected ports to a previous version

The full description is here , but there is a crucial concept to get. Macports will search for a Portfile in the list of repositories, in order, specified in sources.conf. The FIRST one it finds that meets the search crite

Re: Doing my weekly "port -u uninstall", and...

On 2018-06-18, at 5:35 PM, Dave Horsfall wrote: > > ---> Checking for unnecessary unrequested ports > Error: reclaim failed: can't read "isrequested(adwaita-icon-theme)": no such > element in array > > So, WTF? > > -- Dave Looks like your upgrade to MacPorts 2.5.2 hosed. Is adwaita-icon-th

Re: Help with #!/usr/bin/perl

Easiest: move /usr/bin/perl aside and symlink in the one you want. Safest: reinplace the lot to the version you want. Ken > On Jun 16, 2018, at 15:01, Michael wrote: > > How do I avoid the out of date system Perl,

Re: gcc49 fails to build

On 2018-06-10, at 8:54 PM, Dave Horsfall wrote: > On Tue, 5 Jun 2018, Christopher Jones wrote: > > [...] > > Sorry for the delay, but I have several disparate systems here to maintain, > along with a bunch of electronics projects. Anyway... > >> Its possible you have a port installed using

MacPorts Tiger Support...

Every once in a while the question of support for Tiger comes up -- it's an old but beloved system. Of course the fun advantage is that it can run MacOSX Classic and still run all the MacOS9 software from days gone by. I just thought I'd give a short update to the status of MacPorts on Tiger as

Re: Odd mpv configure series failure following fresh reinstall

On 10.13, current Xcode, everything up to date in App Store and running the newest MacPorts there is: sudo port -v -N install mpv +audiocd+bundle+caca+dvd+libarchive+network+opengl+osd+python27+rubberband+screenshot+smb+uchardet+zsh installs through to completion without touching a single thing

Re: How reconcile openmodelica-dvel & octave dependencies on sundials vs. sundials2

Adam, Murray -- This small patch will patch the octave Portfile to make sundials2 support a variant. If you want to install octave without sundials2 support (so you can use openmodelica which needs sundials) this should allow you to do that. The command is: sudo port -v install octave -sundials

Re: gcc49 fails to build

On 2018-06-05, at 9:53 AM, Ken Cunningham wrote: > build on 10.16 and 10.17 before I get shot, read this as "darwin 16 and darwin 17" please...

Re: gcc49 fails to build

On 2018-06-05, at 9:42 AM, Dave Horsfall wrote: > On Mon, 4 Jun 2018, Ryan Schmidt wrote: > >> Here is the bug report corresponding to that problem: >> https://trac.macports.org/ticket/56511 > > Ooh - a utility called "sw_vers"! I wonder what other hidden gems are > lurking, essentially undo

Re: How reconcile openmodelica-dvel & octave dependencies on sundials vs. sundials2

On 2018-06-04, at 8:22 AM, Adam Dershowitz wrote: >>> The odd thing is that octave 4.2.2 was working fine with sundials (which is >>> version 3.1.0_1) This doesn't seem too likely, unless Octave was ignoring sundials. Why don't you try deleting the sundials dependency in the Octave portfile an

Re: How reconcile openmodelica-dvel & octave dependencies on sundials vs. sundials2

.4 > requires the sundials2 port (2.7.0). So, somehow it seems that upgrading > octaves requires downgrading sundials. But, that is not compatible with > openmodelica). > > > --Adam > > > >> On Jun 3, 2018, at 10:17 PM, Ken Cunningham >> wr

Re: How reconcile openmodelica-dvel & octave dependencies on sundials vs. sundials2

The two sundials ports don't have exactly identical file names, but there is too much overlap to try a simple naming trick for installing them both it appears. If one of the ports you want to install has a bundled copy of sundials that you can statically link in, you might get away with that as

Re: issue building libgcc 7.3 on Snow Leopard

If you install libmacho sudo port -v install libmacho you should be good to go. If it works for you as well as it has for me, I'll add it as a build dep for 10.6. Please report back. Best, Ken On 2018-06-03, at 2:46 PM, Riccardo Mottola via macports-users wrote: > Hi, > > I fail to build

Re: possible to enable debug symbols by default?

Well, to do that, you would have to change the default configure.optflags in portconfigure.tcl open /opt/local/libexec/macports/lib/port1.0/portconfigure.tcl and change default configure.optflags {-Os} to something like default configure.optflags {"-O0 -g"} perhaps, or whatever

Re: MacPorts 2.5.0-beta1 now available for testing

> On May 26, 2018, at 12:27 PM, Ryan Schmidt wrote: > > The error occurs when there is a mismatch between which C++ standard library > a port says it uses (by setting configure.cxx_stdlib, or by leaving it set to > its default value) and which C++ standard library it actually links with. >

Re: MacPorts 2.5.0-beta1 now available for testing

> On May 26, 2018, at 9:40 AM, Ryan Schmidt wrote: > > Unfortunately, we have no way to tell Xcode to use one of our compilers. I > believe we need to create some kind of Xcode-specific file to tell it about > each of our compilers, then update the xcode portgroup to use that. Nobody's > do

Re: MacPorts 2.5.0-beta1 now available for testing

> On May 26, 2018, at 9:49 AM, Ryan Schmidt wrote: > > > On May 26, 2018, at 11:48, Ken Cunningham wrote: > >> Well I think you did the cmake finaggeling last time Not sure you could >> find a better way, but I wait to see... > > I don'

Re: MacPorts 2.5.0-beta1 now available for testing

Well I think you did the cmake finaggeling last time Not sure you could find a better way, but I wait to see... K Sent from my iPhone > On May 26, 2018, at 9:40 AM, Ryan Schmidt wrote: > >> On May 26, 2018, at 11:15, Ken Cunningham wrote: >> >>> On May

Re: MacPorts 2.5.0-beta1 now available for testing

> On May 25, 2018, at 12:05 PM, Ryan Schmidt wrote: > > It's "broken" in that it links with libstdc++, even though MacPorts believes > it will link with libc++ on your system. The rev-upgrade code in previous > versions of MacPorts did not check for this kind of "broken". > > Fix it by fixin

gcc5 potential fix

If anyone else can test > and see if it works for them as well, we can commit this fix for gcc5. Ken

Re: Possible error when building "gstreamer"

you can follow along here https://trac.macports.org/ticket/56481 > On May 14, 2018, at 22:54, Dave Horsfall wrote: > > Whatever "gstreamer" is... Anyway, can anyone translate this gobbledygook > into plain English, so that I can file a bug report if necessary? > > Result from my weekly "port

Re: Octave 4.4.0

and octave-devel could be 4.5.0 now, which I have installed, but I (grr) note the previous patch for the crash-on-exit fix no longer seems to apply, and it _still_ did the darned crash on exit thing… Ken > On May 13, 2018, at 5:35 PM, Marius Schamschula wrote: > > >> On May 13, 2018, at

Re: How to launch after a port?

On 2018-05-11, at 12:52 PM, Ryan Schmidt wrote: > At least when Inkscape is installed with the +x11 variant, its Dock icon will > not function the way a normal Mac app's Dock icon would. Its icon will bounce > forever We should start moving ports to the new app PG enhancements so this kind of

kde help center -- "The file or folder help:/XYZ does not exist

More or less total KDE newbie... Almost every entry in the kde help center fails due to an error like the above. Is this something I have forgotten to install, or is it just non-functional on MacPorts installs at present? Ken

Re: How to launch after a port?

> On May 10, 2018, at 4:47 PM, Roy Henderson wrote: > > Hi Marius, > > I hadn’t installed the inkscape-app until you mentioned it - I have done that > and I can now see a MacPorts folder under Applications complete with an > Inkscape icon - thank you! > > However, when I try to launch it, I

Re: error using gcc 48 on PPC

> On Apr 24, 2018, at 8:30 PM, Ken Cunningham > wrote: > > > >> On Apr 19, 2018, at 11:17 PM, Riccardo via macports-users >> wrote: >> >> Hi, >> >> When using gcc48 from macports on 10.5 Leopart PPC (trying to reporduce >> exa

Re: Compiling TeX Live on 10.5 and 10.4 Intel

As mentioned, I have a version of texlive-bin that builds with gcc6 on Tiger Intel by disabling several features that gcc doesn't seem happy with. However, I also have fixed clang-3.8 to build and install on Tiger Intel, and this compiler can build the existing texlive-bin just as it is without

Re: ffmpeg on 10.5/PPC

> On Apr 29, 2018, at 5:08 PM, Ryan Schmidt wrote: > > > On Apr 29, 2018, at 11:33, Riccardo Mottola wrote: > >> On 2018-04-29 14:36:02 +0200 Ken Cunningham wrote: >> >>> clang-3.4 will never work on PPC, so don't even bother. >> >> I

Re: ffmpeg on 10.5/PPC

On 2018-04-29, at 5:36 AM, Ken Cunningham wrote: >> I notice this: >> License: GPL version 2 or later >> Creating configuration files ... >> >> WARNING: GNU assembler not found, install/update gas-preprocessor >> ---> Building ffmpeg >> >>

Re: ffmpeg on 10.5/PPC

clang-3.4 will never work on PPC, so don't even bother. I have many ffmpeg versions built on 10.5 PPC, including what I think is the current one. I have not seen that assembler error before, but I can try building ffmpeg again later this morning and see what happens. FYI I also have gimp2 buil

Re: Compiling TeX Live on 10.5 (was: libatomic build failure 10.5/x86)

On 2018-04-26, at 8:24 AM, Ken Cunningham wrote: > > > well disabling luajit just leads to the same error I found when I used > > --with-system-luajit > > One or two more iterations and I we should have this :> Fixed. I'll put something up for a PR later today. Ken

Re: Compiling TeX Live on 10.5 (was: libatomic build failure 10.5/x86)

On 2018-04-26, at 7:17 AM, Ken Cunningham wrote: > > On 2018-04-26, at 5:42 AM, Mojca Miklavec wrote: > >>> If you use the_silver_searcher on texlive-bin you will see a flag in >>> autotools build scripts called need_luajit . It looks like many different >>&g

Re: Compiling TeX Live on 10.5 (was: libatomic build failure 10.5/x86)

On 2018-04-26, at 5:42 AM, Mojca Miklavec wrote: >> If you use the_silver_searcher on texlive-bin you will see a flag in >> autotools build scripts called need_luajit . It looks like many different >> tools call for it, and you'd have to disable a lot to get past needing it. > > I have no time

Re: Compiling TeX Live on 10.5 (was: libatomic build failure 10.5/x86)

> On Apr 26, 2018, at 04:19, Mojca Miklavec wrote: > >> On 26 April 2018 at 13:12, Riccardo Mottola wrote: >>> On 2018-04-26 07:33:30 +0200 Mojca Miklavec wrote: >>> >>> Riccardo, can you please try: >>>sudo port -v build luajit configure.compiler=macports-gcc-6 >>> or >>>sudo port -v

Re: Compiling TeX Live on 10.5 (was: libatomic build failure 10.5/x86)

installing libcxx on 10.5 requires changing the universal archs in macports.conf to i386 x86_64 make sure you port sync because I fixed an issue with libcxx recently it will build with clang 3.4 you'll see screenfuls of macports errors . if you get stuck I'll post up binaries for libcxx & cl

Re: Compiling TeX Live on 10.5 (was: libatomic build failure 10.5/x86)

On 2018-04-25, at 10:33 PM, Mojca Miklavec wrote: > On 26 April 2018 at 05:38, Ken Cunningham wrote: >>> On Apr 25, 2018, at 5:23 PM, Ken Cunningham wrote: >>> >>> you know, I went back and looked at my notes. >>> >>> I did in fact build th

Re: Compiling TeX Live on 10.5 (was: libatomic build failure 10.5/x86)

> On Apr 25, 2018, at 5:23 PM, Ken Cunningham > wrote: > > you know, I went back and looked at my notes. > > I did in fact build this with clang-3.4, but I overrode the cxx11 PG's > macports-libstdc++ changes to do it. It worked fine on Intel Tiger as well. &

Re: Compiling TeX Live on 10.5 (was: libatomic build failure 10.5/x86)

On 2018-04-25, at 11:42 AM, Ken Cunningham wrote: >> Forcing clang-3.4 brings up this: >> >> /opt/local/bin/clang++-mp-3.4 -DHAVE_CONFIG_H -I. >> -I./TECkit-src/source/Public-headers -DNDEBUG -isystem/opt/local/include >> -pipe -Os -std=c++11 -Wno

Re: Compiling TeX Live on 10.5 (was: libatomic build failure 10.5/x86)

On 2018-04-25, at 11:38 AM, Riccardo Mottola wrote: > Hi, > Forcing clang-3.4 brings up this: > > /opt/local/bin/clang++-mp-3.4 -DHAVE_CONFIG_H -I. > -I./TECkit-src/source/Public-headers -DNDEBUG -isystem/opt/local/include > -pipe -Os -std=c++11 -Wno-reserved-user-defined-literal >

Re: Compiling TeX Live on 10.5 (was: libatomic build failure 10.5/x86)

On 2018-04-25, at 10:59 AM, Riccardo Mottola wrote: > Hi, > > Michael Dickens wrote: >> That said, on 10.6 Intel there's an issue with objc++ compiling, where the >> OBJCXXFLAGS requires "-fpermissive" to get over some untyped enum issues in >> some security framework. I had 'port' use the def

Re: Compiling TeX Live on 10.5 (was: libatomic build failure 10.5/x86)

On 2018-04-25, at 10:59 AM, Riccardo Mottola wrote: > Hi, > > Michael Dickens wrote: >> That said, on 10.6 Intel there's an issue with objc++ compiling, where the >> OBJCXXFLAGS requires "-fpermissive" to get over some untyped enum issues in >> some security framework. I had 'port' use the def

Re: Compiling TeX Live on 10.5 (was: libatomic build failure 10.5/x86)

> On Apr 25, 2018, at 08:30, Mojca Miklavec wrote: > >> On 25 April 2018 at 16:37, Michael Dickens wrote: >> I don't think I did anything special, and texlive-bin installed for me on >> 10.5 PPC without complaint. > > But note that the code which failed for Riccardo is disabled on PPC. yes,

Re: Compiling TeX Live on 10.5 (was: libatomic build failure 10.5/x86)

for texlive-bin on 10.5, I built it with clang 3.4 with success. sudo port clean texlive-bin sudo port -v install texlive-bin configure.compiler=macports-clang-3.4 I forget just now why gcc6 failed. K > On Apr 25, 2018, at 02:05, Mojca Miklavec wrote: > > Hi, > > I cannot say why this breaks.

Re: error using gcc 48 on PPC

> On Apr 19, 2018, at 11:17 PM, Riccardo via macports-users > wrote: > > Hi, > > When using gcc48 from macports on 10.5 Leopart PPC (trying to reporduce exact > TenFourFox build environment needed) it will fail this way during configure: > > Ever seen something like this? I *think* gcc was

Re: libatomic build failure 10.5/x86

I just pushed a commit that should fix this for you. After it propogates through, please sudo port sync -or- sudo port selfupdate and try your install again. Best, Ken On 2018-04-21, at 1:10 AM,

Re: error using gcc 48 on PPC

In https://github.com/tpoechtrager/osxcross/issues/50 it is suggested that to link against the 10.4 SDK with PPC you need to use Tiger's linker. Well down the page. I haven't tried that myself as yet. There's lots of further good PPC lore there too K > On Apr 19, 2018, at 23:17, Riccar

Re: upcoming removal of components from macOS Server: opportunity?

On 2018-04-16, at 5:43 PM, Craig Treleaven wrote: >> On Apr 16, 2018, at 7:39 PM, Richard L. Hamilton wrote: >> >> "In fall 2018, Apple will stop bundling open source services such as >> Calendar Server, Contacts Server, the Mail Server, DNS, DHCP, VPN Server, >> and Websites with macOS Serve

Re: OpenModelica?

Whenever I get to this level of hassle, I just blow up MacPorts and start over. It takes but a few minutes to reinstall the prebuilt binaries, and then you know you're clean. Life is too short Ken

Re: mplayer start problem

> On Apr 8, 2018, at 11:35 AM, rmgls wrote: > > hi all, > in terminal mode: > mplayer somefile.mp3 > illegal instruction 4 > my ports are up-to-date, and mplayer reinstalled. > Darwin myhost.home 17.4.0 Darwin Kernel Version 17.4.0: Sun Dec 17 09:19:54 > PST 2017; root:xnu-4570.4

Re: OpenModelica?

> On Apr 7, 2018, at 1:13 PM, Murray Eisenberg > wrote: With a small change in the openmodelica-devel Portfile that I did prior to starting the build (so it would use gcc7 for fortran), all of openmodelica-devel built through to completion for me on a current Xcode and 10.13 system, using n

Re: OpenModelica?

> On Apr 7, 2018, at 12:54 PM, Murray Eisenberg > wrote: > > Ouch, yes, my disastrous typo in the repository name, sorry. (The first time > I tried, without using "sudo su -“, I had copied the “echo rsync” command > directly from the https://www.openmodelica.org/download/download-mac >

Re: OpenModelica?

> > > >> On Apr 7, 2018, at 2:56 PM, Ken Cunningham > <mailto:ken.cunningham.web...@gmail.com>> wrote: >> >> >> >>> On Apr 7, 2018, at 11:51 AM, Ryan Schmidt >> <mailto:ryandes...@macports.org>> wrote: >>> >&g

Re: OpenModelica?

> On Apr 7, 2018, at 11:51 AM, Ryan Schmidt wrote: > > > On Apr 7, 2018, at 13:50, Murray Eisenberg wrote: > >> What’s happening now is befuddling to me. Doing the step >> >> echo rsync://build.openmodelica.org/macports/ >> >> /opt/local/etc/macports/sources.conf >> >> as root (sudo su

Re: OpenModelica?

> On Apr 7, 2018, at 10:53, Ryan Schmidt wrote: > > >> On Apr 7, 2018, at 12:49, Ken Cunningham wrote: >> >> sounds like this software needs a port and a maintainer! > > It already has a port, and a collection of hundreds of related ports, in an > ent

Re: OpenModelica?

sounds like this software needs a port and a maintainer! Murray? > On Apr 7, 2018, at 10:17, Ryan Schmidt wrote: > > >> On Apr 7, 2018, at 11:27, Murray Eisenberg wrote: >> >> Thanks, that seems to have worked. >> >> To do the remaining steps… >> >> port selfupdate >> port install gcc44 # W

Re: Port trees for specific versions of MacOS

On 2018-03-28, at 10:04 AM, René J.V. Bertin wrote: > > I'm not sure I follow nor that I agree with what I think I understand. If > pegged ports are ports no longer supported (in that form/version) on the main > tree, why would they have to follow what the main tree does with their > current v

Re: Port trees for specific versions of MacOS

On 2018-03-28, at 9:20 AM, René J.V. Bertin wrote: > On Wednesday March 28 2018 09:00:52 Ken Cunningham wrote: > > Thanks for picking this up, > >> I'd just like to mention that I've been working on this on my own for a >> while now, and have such

Port trees for specific versions of MacOS

In Rene mentions the idea of generating port tree overlays for specific versions of MacOS, to preserve compatible versions of ports which have moved beyond the capabilities of that OS. I'd just like to mention that I've been working on this on

Re: How to resolve libstdc++.6.dylib dependency

that's probably the simplest solution for simple executables with no complicated web of supporting libraries. I wonder if the same thing could work for Mojca's libc++ issues with her binaries? Ken On 2018-03-24, at 11:20 AM, Andreas Falkenhahn wrote: > On 24.03.2018 at 17:34 Mojca Miklavec

Re: LibreSSL 2.7.1 Released

see > On Mar 24, 2018, at 03:49, Jan Stary wrote: > > Hi Jeremy, > > what is the plan really with libressl and libressl-devel? > We have 2.5.5 in security/libressl, 2.6.2 in security/libressl-devel, > and now 2.7.1 is out. > > I would just pre

Re: How to resolve libstdc++.6.dylib dependency

Cameron Kaiser builds and distributes TenFourFox which is a c++11 app built with gcc48 against a new libstdc++. He has worked a lot of this out. His instructions are here , and there's a script in the repo

Re: Installing gcc6 on a PPC Mac Mini 10.4 gives me hell

On 10.5 you installed a prebuilt binary. gcc6 takes 12 to 24 hrs to build on a PPC machine. I should make my premade binaries available. K > On Mar 20, 2018, at 14:32, Andreas Falkenhahn wrote: > > > > So I installed gcc6 on my 10.5 G5 PowerMac a few days ago and it was a breeze. > It took

Re: request for port peg command, to lock down a port at the currently installed version

M, G Alexander wrote: > > isnt this the same as --no-upgrade? > >> On Mar 6, 2018, at 06:50, Ken Cunningham >> wrote: >> >> It is fairly common for users to find an update to a port that won't build >> on their system for some reason. >> >&g

Re: mtree violation

On 2018-03-06, at 7:01 AM, macpo...@parvis.nl wrote: > I'm trying to local install jdupes with my own test fixes, but i cannot > destroot/activate due to more violation. > Warning: violation by /usr > fragment of original Makefile: > -- > # PREFIX determines where

Re: running macports along with homebrew

Indeed. Db had asked how it would technically be done, eg in his personal repo. I am also on neither side in this. K Sent from my iPhone > On Mar 5, 2018, at 2:39 AM, Ryan Schmidt wrote: > >> On Mar 5, 2018, at 04:34, db wrote: >> >> I know, but I don't see how HEAD is pragmatically that

Re: running macports along with homebrew

On 2018-02-13, at 12:20 PM, db wrote: > >> 2. HEAD variants. >> This is a specific MacPorts decision, based on the "reproducible builds" >> philosophy. It's open for debate at times, I would think. It's easy to do >> it, but we just don't do it on purpose. >> I have overridden this and allowe

Re: macports easytag font size

> On Feb 25, 2018, at 5:06 PM, M B via macports-users > wrote: > I have not been able to find the information about how to change the size of > the font in gtk apps installed via macports. > > Can someone help me solve this issue ? Where should I look ? Gtk preferences > ? XQuartz preferenc

thread_local with clang-5.0 on 10.6 (and lower) -- works , but slight issue with libc++ that I would appreciate some help with.

thread_local is a c++11 feature that newer software is increasingly using. It is available with gcc 4.8+, and with clang since about clang-3.5. On macOS (darwin) it requires system supports that arrived in 10.7. My goal is to get thread_local with clang-5.0 and newer on 10.6 (and 10.5). Turns

Re: distfile downloads failing on https

> On Feb 23, 2018, at 01:49, Jan Stary wrote: > > On Feb 22 18:04:23, ken.cunningham.web...@gmail.com wrote: You are done. No more circular dependency. >>> Yes. One installation of MP depends on another installation. >>> >> >> That's not circular. Circular is when an installation of MacP

Re: distfile downloads failing on https

On 2018-02-21, at 11:14 AM, Jan Stary wrote: >> You are done. No more circular dependency. > > Yes. One installation of MP depends on another installation. > That's not circular. CIrcular is when an installation of MacPorts depends on itself, and is therefore fragile. The installation of libc

Re: Search for a MacPorts Mascot: looking for talented artists

On 2018-02-21, at 12:36 PM, Dave Horsfall wrote: > On Wed, 21 Feb 2018, Mojca Miklavec wrote: > >> During the GSOC meeting in Mountain View we had some fruitful evening >> discussions where we were heavily criticised for not having our own happy >> fluffy animal mascot (like a flying platypus?

Re: lowdown not helped by snowleopardfixes

On 2018-02-21, at 11:31 AM, Jan Stary wrote: > Hm, doesn't the PortGroup add its stuff to LDFLAGS and LDADD > (and whatever else) _after_ the port has done its configure? not usually. eg. this portgroup adds: configure.ldflags-append -lsnowleopardfixes > I am probably missing something fundam

Re: lowdown not helped by snowleopardfixes

lowdown uses it's own completely unique methods for configure and library function replacements, I see. It clears out the LDFLAGS during the build, ergo the -lsnowleopardfixes not being honoured it also replaces some functions on it's own, so there might be collisions if -lsnowleopardfixes was

Re: distfile downloads failing on https

I should have been more descriptive about the /opt/bootstrap part of the post below. Like you, I didn't like the circular dependency. If you "sudo port uninstall active", you're hooped. So here's what I actually do on all systems 10.4 to 10.7 using Macports from this page

Re: lowdown not helped by snowleopardfixes

I'll take a look. The PG adds -lsnowleopardfixes to the ldflags, but thats not showing up in your build for some reason. For some ports, you have to add the flag a different way, via a patch or similar... K > On Feb 21, 2018, at 05:40, Jan Stary wrote: > > Hi Ken, > > when I created the text

Re: distfile downloads failing on https

see https://trac.macports.org/ticket/51516#comment:19 for a workaround that works quite well on Tiger up until this gets fixed K > On Feb 21, 2018, at 04:26, Jan Stary wrote: > >> On Feb 21 13:18:47, h...@stare.cz wrote: >>> On Feb 21 12:43:28, h...@stare.cz wrote: >>> A more general proposed

Re: Fail to install git from macports ("can't find file to patch" error)

> On Feb 20, 2018, at 06:34, Joshua Kordani wrote: > > Not the OP, but regarding DYLD_LIBRARY_PATH, I don't understand how to make > use of dylib's provided by macports in my own programs without setting this > flag. I've read in several places that, esp with macports, this should not > be

Re: Problem opening x-window over an ssh connection

This happens recurrently to me, usually after significant updates. The last time was some months ago, so I forget exactly what I did, but it involved the location of xauth and the ssh config on the target machine, if I recall correctly. So that's where I would start to google, (and will, the n

Re: running macports along with homebrew

not to. > > Peter > >> On 15 Feb 2018, at 5:46 am, Ken Cunningham >> wrote: > … > >> In a recent poll >> <https://www.slant.co/versus/1588/1674/~macports_vs_homebrew>, homebrew was >> recommended 375 to 25 over MacPorts. > … >> 2.

Re: running macports along with homebrew

On 2018-02-14, at 5:56 AM, Ryan Schmidt wrote: > We will definitely never offer a user-facing feature for building the HEAD > version of a port's code. I completely recognize why you stick with this, I totally get it, but this caution is costing MacPorts both users and mindshare to do so...

Re: running macports along with homebrew

On 2018-02-13, at 12:20 PM, db wrote: > > I have some devel ports locally, that I have to manually update for the > latest commit, instead of automatically updating for the current master. I > have to check that wielands port. > widelands uses bzr, so it's easy to force it to the current comm

Re: running macports along with homebrew

On 2018-02-13, at 6:40 AM, db wrote: > On 13 Feb 2018, at 07:01, Ken Cunningham > wrote: >> If there is anything worth having in MacPorts that is in Homebrew but not >> MacPorts, just ask for it. > > I'm trying homebrew as a fallback for MacPorts, but since y

Re: running macports along with homebrew

If I might suggest something to make this issue easier, If there is anything worth having in MacPorts that is in Homebrew but not MacPorts, just ask for it. Most of these ports take 10 to 20 minutes to make. Some a bit longer, if they are weird in some way. Best, Ken

Re: issue upgrading libcxxabi

On 2018-01-30, at 5:41 PM, Joshua Root wrote: > Ken Cunningham wrote: >> On 2018-01-30, at 9:44 AM, Riccardo Mottola via macports-users wrote: >>> before filing a bug, maybe this is expected and there is a stragey for >>> updating it or replacing it with somethin

Re: gdb fails to compile on Leopard - C++11 compiler

On 2018-01-30, at 8:41 AM, Chris Jones wrote: > > On 30/01/18 16:31, Riccardo Mottola wrote: >> Hi, >> Chris Jones wrote: >>> Or maybe the gdb port could be updated to use one of macports python >>> versions ? >> can I do this easily as a test in my portfile? could you do it? >> I already have

Re: issue upgrading libcxxabi

On 2018-01-30, at 9:44 AM, Riccardo Mottola via macports-users wrote: > Hi, > > before filing a bug, maybe this is expected and there is a stragey for > updating it or replacing it with something? > This is on 10.6 Snow Leopard, btw. > > Riccardo > The message is correct. This is expected.

Re: macports libsndfile 1.0.28 Mac OS X 10.4.11 Tiger

On 2018-01-27, at 6:10 AM, Ryan Schmidt wrote: > > Correct, Availability.h was introduced in Mac OS X 10.5. 10.4 and earlier > must use AvailabilityMacros.h instead. A suggestion for all the other Tiger users out there: This comes up all the time. Not many people are interested in special-cas

Re: gdb fails to compile on Leopard - C++11 compiler

Use an older version of gdb, like 7.6.8 maybe, that worked on leopard. J Sent from my iPhone > On Jan 26, 2018, at 12:07 PM, Joshua Root wrote: > > Riccardo Mottola wrote: >> Build fails with: >> >> /opt/local/bin/g++-mp-6 -pipe -Os -D_GLIBCXX_USE_CXX11_ABI=0 -m32 >> -I. -I. -I./common -

Re: display issue when launching qalculate

On 2018-01-26, at 7:40 AM, Jonathan Stickel wrote: > > Still, qalculate-gtk should look OK with X11, but I have not tested it > recently. Using xorg-server works for other x11 ports on my computer, e.g., > xlogo. The X11 version looks perfect on my systems. K

Re: clamav

On 2018-01-25, at 8:28 PM, Daniel J. Luke wrote: > On Jan 25, 2018, at 10:44 PM, Ken Cunningham > wrote: >> If anyone ever cares to put some quick MacPorts-specific setup instructions >> for clamav in the Port Notes or somewhere, that would be great. >> >> I as

clamav

If anyone ever cares to put some quick MacPorts-specific setup instructions for clamav in the Port Notes or somewhere, that would be great. I assume a few directories need to be set up, etc. Ken

<    1   2   3   4   5   6   7   >