Hi Adam - Thanks for the info. Two points:
(1) You can ignore the warning; is will not impact the installation
and/or select of qt4-mac.
(2) Interestingly, I removed that section of code from the Portfile a
ways back, since it is unnecessary. It's odd that it seems to still be
in your
On Wed, 11 Aug 2010 11:57 -0500, Adam Mercer r...@macports.org wrote:
$ grep \?honon `port dir qt4-mac`/Portfile
Interesting again. Try this see if either generates the warning:
{{{
sudo port deactivate qt4-mac
sudo port activate qt4-mac
}}}
If not, then it makes me wonder if the Portfile upon
I fixed that issue this morning in r70897 and r70899 (per ticket #26209);
please 'sync' and try again. - MLD
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
If you knowingly use / develop using Qt4, please reply to me your usage
preference, probably off list is best to keep traffic down:
1) I -require- Qt4 to be installed as a framework.
2) I -prefer- Qt4 to be installed as a framework.
3) I do not care at all how Qt4 is installed so long as it
Does any project beyond GNU Radio's USRP actually -require- the
libusb-legacy (0.1.12) port / library?
The reason I'm asking is that I want to rename the installed
libusb-legacy libraries from libusb.dylib (etc) to
libusb-legacy.dylib (etc) in order to avoid the (as I'm calling
it) same name
Hi Bradley -
On Aug 31, 2010, at 11:00 AM, Bradley Giesbrecht wrote:
Wouldn't adding your desired flags to the front of
configure.env, configure.pre_args or where ever else needed
work?
I suppose I could change the compiler from gcc to gcc
-L${prefix}/lib/libusb-legacy -L${prefix}/lib,
This is the last poll (for now :); sorry for so many, but I have
a number of changes that I'd like to make to various ports, and
I'd like to believe that I'm not significantly messing anyone up
in the process and/or that these changes are sane.
In this poll, I'd like to know if there are users /
Hi Frank - Thank you for the feedback. I will test out the no_framework
change with lots of ports to make sure it works across the board with
high probability (I can't test -every- port); I'll make sure to include
the py26-PyQt4 port (since I use py26). - MLD
On Tue, 31 Aug 2010 08:53 -0600,
I agree with Rainer all around.
Apple uses frameworks, but most non-OSX-native projects do not they
generally work just fine when ported without frameworks to OSX. Qt and
Python are two of the few exceptions of which I know that can do
framework installs; I'm sure there are others. That said,
On Sep 8, 2010, at 1:18 PM, Ryan Schmidt wrote:
On Sep 8, 2010, at 11:59, Jan Lübke wrote:
I assume that qt4-mac is basically the same. Only the paths
are different. Is that assumption correct?
I hope so, but do not know.
For all practical purposes, yes, they are the same. They
My US$0.02 worth, having been extensively experimenting with numpy over the
past few days. - MLD
On Sep 14, 2010, at 12:56 PM, Jeff Singleton wrote:
I took a gamble and changed the CC and CXX variables being set in the
py26-numpy Portfile to point to the gcc-4.2/g++-4.2 compiler in OS X.
On Sep 14, 2010, at 2:41 PM, Jeff Singleton wrote:
How could I be compiling for one arch and then linking another ... I'm
using MacPorts. I would assume that if a Port has support for universal,
then MP would adhere to this and build universal.
As pointed out by Ryan, many MP developers /
Does anyone know or remember why MP's version of numpy (I use py26-numpy)
requires non-Apple gcc? Why -not- use Apple's GCC? In playing around with
various installs (+gcc44, +universal), reading through debug outputs, and
testing builds, I do not find that fortran is required to compile
On Sep 17, 2010, at 12:48 PM, Adam Mercer wrote:
Looking at the history, the use of macports gcc was added when atlas
was added as a dependency [1]. I believe this was due to compiler ABI
differences.
Thanks Adam; seems like maybe MacPorts/GCC/whatever don't have those
differences any longer?
On Sep 17, 2010, at 3:22 PM, Ryan Schmidt wrote:
AFAIK the differences do still exist and will always exist. The problem as I
understand it is if you try to compile library A with compiler X and compile
program B (which links with library A) with compiler Y, inexplicable problems
can
On Sep 18, 2010, at 6:38 PM, Ryan Schmidt wrote:
Now, in the specific case of py*-numpy and its dependency atlas, it seems
that py*-numpy doesn't link with any libgcc_s.1.dylib so it might not be
affected by this problem. Bear in mind I have not actually experienced any
of the issues we're
On Sep 21, 2010, at 4:06 AM, Keith J. Schultz wrote:
Hi All, Is there not a way to get of make a port for the Apple GCC or add
ATLAS support to it? I no it is easier just to adapt the other gcc, but
adding the above mentioned functionality would get ride of the other
headaches. regards,
Hi Keith - No problem on the reply to all thing; it happens to all of us
(really). There was a follow-up on this subject (renamed ambivalence about
fortran) that covered parts of your fortran question. Apple does not provide
a fortran compiler in XCode, and, really, there is no good way to
On Sep 22, 2010, at 4:09 AM, Michael Feiri wrote:
We also have llvm-gfortran-4.2 available in macports as part of the
llvm-gcc42 port. This version of gfortran is based on Apples branch of gcc42
and uses the latest llvm for code generation. It should be the safest option
because it uses the
After playing around with py26-numpy a bit more as well as reading through the
NumPy/SciPy MacOS X install guide
http://www.scipy.org/Installing_SciPy/Mac_OS_X , I think I've reached a
compromise that seems to meet the developers' requirements (linking
fortran-created libraries with fortran,
Does anyone actually use -both- qt4-mac and qt4-x11? They are currently
installed separately (in ${prefix}/libexec/qt4-mac and .../qt4-x11), so it is
possible to do so. Reason I'm asking is that most (almost all?) of the ports
we have that can be x11/quartz just have variants for these, while
A few thoughts:
(1) Where does /usr/bin/gfortran come from? There are a number of numpy
tickets open (and closed) where this executable has been installed. numpy's
internal configure routines will discover it, and it causes issues. Apple's
XCode does not install a fortran executable, so it
On Sep 30, 2010, at 2:38 PM, Michael Dickens wrote:
(3) an externally set LDFLAGS does override the internal definition just for
the linalg module. This is the only module that requires external fortran
linking, and setting the external LDFLAGS causes the linking to fail in the
way it does
On Sep 30, 2010, at 2:38 PM, Michael Dickens wrote:
(2) Try out the fix in ticket #24942 https://trac.macports.org/ticket/24942
. It still has issues with the resulting 'f2py', but I think I know what to
do -- just need a few hours to do it (hopefully Friday).
I just uploaded a new svn
Begin forwarded message:
From: michae...@macports.org
Subject: [72874] trunk/dports/_resources/port1.0/group/qt4-1.0.tcl
Add in a few more variables; set all variables to 'global' to allow
for use in variants and enbedded stages.
Related to this change, I've also tracked down 3 other issues
Hi Faisal - F2PY has the issue of allowing its internal LDFLAGS to be
overwritten by the user's -- and thus linking will fail unless the necessary
compiler flags (as found in the internal LDFLAGS) are added to the user's
LDFLAGS. Although this might not be the problem, it is worth trying since
Hi Thomas - My guess is that the 'configure' stage failed without
errors and the Makefile was not created; hence, 'build' would
fail as what happened to you. Can you do sudo port
clean kile-devel and then sudo port install kile-devel and
if/when that fails, search for a matching ticket and/or
On Nov 28, 2010, at 7:16 PM, Ryan Schmidt wrote:
On Nov 28, 2010, at 09:18, Thomas Schneider wrote:
objc[538]: Class QCocoaColorPanelDelegate is implemented in both
/opt/local/lib/libQtGui.4.dylib and
/Library/Frameworks/QtGui.framework/Versions/4/QtGui. One of the two will be
used. Which
Hi Pierre-Henri - I don't think anyone ever replied to your query. Did you
submit a ticket on this issue? Was it resolved? We've recently made a number
of changes to both the KDE 1.1 PortGroup as well as ports that use it. So,
maybe your issue has been resolved? - MLD
On Nov 30, 2010, at
I also re-fixed the issue (per ticket #25989) generically (future proof?)
this time --- so you should be able to install akonadi with cdparanoia active
now. - MLD
On Jan 10, 2011, at 12:04 PM, Chris Jones wrote:
However, the solution at the end, to install cdparanoia doesn't work this
time
I checked in qt 4.7.2 in r76859 a couple days ago. I hope it helps! - MLD
On Mar 9, 2011, at 11:23 PM, Gabriele Kahlout wrote:
When could we expect the port to be updated to qt-4.7.2. Perhaps that will
fix issues.
___
macports-users mailing list
Hi Norman - 'strigi' depends on 'automoc', which depends on 'qt4-mac'. In your
install, 'qt3' is active, while 'qt4-mac' is not. Hence, the 'strigi' cannot
be upgraded. 'qt3' and 'qt4-mac' conflict with each other, so you'll need to
deactivate qt3 and activate qt4-mac @4.7.3_0+quartz before
Hi Kieran - Well, that's a tricky one. Let me elaborate; please bear with me.
See also
http://developer.apple.com/library/mac/#technotes/tn2124/_index.html#//apple_ref/doc/uid/DTS10003391-CH1-SECDYLD
,
Hi Kieran - Can you provide the versions of OS, XCode, and MacPorts that you're
using? I'll admit that I have't tried debugging Qt stuff in a long time, so
... - MLD
On Oct 14, 2011, at 5:37 AM, Kieran Simpson wrote:
I noticed when debugging a segfault, even though my binary was linked to
Hi James - Is your qt4-mac-devel installed with the +debug vartiant?
Try port installed qt4-mac-devel and that should show you what
variants are installed. If it's not installed as +debug, then there
will be very few _debug libraries, if any -- no supposed to be any,
but the default Qt install
I recently updated qt4-mac from 4.7.4 to 4.8.2. For those of you using
qt4-mac-devel (4.8.0), I will be moving it to the 5.0 alpha release as
soon as it compiles cleanly for me. So, if you're still using
qt4-mac-devel, please switch to using qt4-mac instead since it's
actually more recent (for
On Jun 17, 2012, at 11:41 AM, Craig Treleaven wrote:
From the Qt4-mac portfile, it appears that OS X 10.4 through 10.7 are
supported on the various combinations of PPC, i386, x86_64 in 32 and 64 bit
modes, as appropriate. (So the minimum would be PPC 32 bit if anyone was
patient enough to
Hi Michael - Well, qt4-mac's doc and examples are in,
respectively:
${prefix}/share/doc/qt4
and
${prefix}/share/qt4/examples
I don't know about qt4-creator-mac's; why not view the installed
files for this port and see what's in ${prefix}/share/... ? - MLD
On Jul 21, 2012, at 9:21 AM, Michael
Hi Comer - It is quite possible that qt4-mac is still building.
Depending on your specific Mac and OS, it can take 1 hour to 1 day. I
truly doubt that the install was stalled; more likely is that it just
takes a very long time to build. If you have the patience and
resources, leave it going
I've updated octave-devel in r97159. For those using octave and wanting
the latest, please do a seflupdate and then see if the new octave-devel
works for you. The octave-* ports may or not work with the Octave
3.6.2, but they should still be compatible with the octave (3.2) port.
Someone (not
Hi Peng - I see this too. I think one can create a startup file that
does graphics_toolkit gnuplot or graphics_toolkit fltk which should
take care of the issue. See
http://www.gnu.org/software/octave/doc/interpreter/Startup-Files.html
. There is probably a way to fix this in octave-devel
After some thinking about the amount of effort I've put into relocating
Qt's frameworks from ${prefix}/lib to ${prefix}/Library/Frameworks, and
how much more will need to be done -- e.g., for CMake, and pretty much
any CMake-using port that tries to find Qt4, to work reliably when
trying to find
On Sep 19, 2012, at 12:02 PM, Craig Treleaven ctrelea...@cogeco.ca
wrote:
Appreciate all the effort you have and continue to put into making Qt as
painless as possible!
Thanks! And, that's the goal: as painless as possible. qt4-mac is a BIG
compile, so I try hard to avoid requiring a
On Sep 19, 2012, at 10:28 PM, Ryan Schmidt ryandes...@macports.org
wrote:
As for moving to a framework-always install, that seems like a good idea to
me. If there are a few ports that have problems with it hopefully they can be
patched.
Well, the internals would be compiled as frameworks,
On Aug 31, 2012, at 5:54 PM, Peng Yu pengyu...@gmail.com wrote:
I get the following warning. Is there a compile option should be enabled for
octave?
~$ /opt/local/bin/octave -q
warning: no graphical display found
So I think I fixed this issue today.
The story is that octave-devel's
Not sure of the issue exactly, but qt4-mac 4.8 does not compile on PPC
nicely. See ticket #36497 https://trac.macports.org/ticket/36497
for more on that. Maybe your issue is the same as this ticket's? As
another has already said, we cannot do more without a log file. - MLD
Hmm ... mine does not either. Let me fix that, shortly. - MLD
On Tue, May 21, 2013, at 10:52 PM, Ryan Schmidt wrote:
Examining the contents on my system, the octave port @3.2.4_13 installs
some manpages; the octave-devel port @3.6.4_3 does not. I don't know why
not.
The manpage is provided by the +docs variant. The reason +docs is
separate is because it requires texlive, which is a pretty serious set
of ports to compile/install -- so I kept it separate. Is this the
behavior we want? - MLD
___
macports-users mailing
I finally finished the gnuradio (and related) ports today, for install
via MacPorts on Mac OS X (mainly 10.6+, but should work on 10.4+). I
split gr-osmosdr off such that there is a 3.6 API version and a 3.7 API
version -- respective: gr-osmosdr and gr-osmosdr-next. The GNU Radio
ports are split
Hi Dan - Try the following:
{{{
sudo port -f uninstall qwt
sudo port clean qwt52
sudo port install qwt52
}}}
and see if that works. If it does not, it should print out which ports
are disliking what you're trying to do. You can get a list of
already-installed ports that depend on qwt via port
Done in r107067 https://trac.macports.org/changeset/107067 , though
I've tested with py27 only. - MLD
On Mon, Jun 17, 2013, at 07:57 AM, Timothy W. Grove wrote:
I am using py33-pyqt4, but there are some bugs in the pyqt4 code at
version 4.10.1. A new version (4.10.2) has been released today
On Thu, Jul 11, 2013, at 05:14 AM, Conrad Taylor wrote:
Hi, I was wondering, is there a qt5-mac port in the works? Well, I must go
and thanks in advance for any information that you can provide.
Hi Conrad - I'm cc'ing the overall dev and user's groups, since it seem
that there are a number of
, but to each :) I'm happy to be
listed as a co-maintainer as well as it being openmaintainer, if
you/me/someone gets to that point.
On 11 juil. 2013, at 15:51, Michael Dickens michae...@macports.org wrote:
MacPorts is a great piece of software, and many of its developers are
already
On Fri, Jul 26, 2013, at 06:25 AM, Degang Wu wrote:
mountain lion 10.8.4
I have attached the log
Hi Degang - For some reason, SciPy is being -partly- built as
+universal, even though that should not be allowed since the Portfile
specifies universal_variant no. In situations such as this, I
On Fri, Jul 26, 2013, at 01:03 PM, Ryan Schmidt wrote:
I suspect this is because of a bug in python itself, when python itself
is installed with the universal variant.
https://trac.macports.org/ticket/39669
Yes, I bet this is the issue. Do you really need the +universal variant
for python?
Hi Conrad - Qt maintains a blog at [1]http://blog.qt.digia.com , and
has GIT repositories for a bunch of different parts of Qt at
[2]https://codereview.qt-project.org/ . I watch the 4.8 branch at
[3]https://codereview.qt-project.org/p/qt/qt for important Qt changes
for OSX; I do not watch or
If you mean py*-pyqt4, then yes, I'm involved in that. Got some changes
I'll hopefully get checked in tomorrow which fix some issues with how
MacPorts interfaces with that port. py*pyqt5 will require a qt5 port
first. I have not had time to work on qt5; maybe others have? - MLD
On Tue, Oct 1,
Hi Masha - Yes, please! Attach to ticket #40683
https://trac.macports.org/ticket/40683 your Portfiles, or even better,
the diff -u between your Portfiles and the current versions. I'm on CC
there, and I maintain octave-devel so I have some interest in these
ports working (though I do not use
According to http://octave.sourceforge.net/communications/index.html
, this octave package does not auto-load. I'm not sure how one makes a
package auto-load yet. With the forthcoming release of octave 3.8.0
(right now 3.7.7, sort of a devel or beta level), I'm working on fixing
the octave ports
I'm almost to the point of making the Octave transition:
1) moving octave-devel (3.6.4) to octave (was 3.2.4);
2) making octave-devel replaced by octave temporarily, to get folks
currently using octave-devel to move to octave;
3) adding octave-next for the current 3.7.7 release (yes: it works
I just pushed the octave update
https://trac.macports.org/changeset/114034 , which should fix
octave-communications. I've checked building and loading under 10.8 and
10.9, so hopefully the transition will be reasonably smooth. - MLD
___
macports-users
I just pushed the octave update
https://trac.macports.org/changeset/114034 . I've checked building and
loading under 10.8 and 10.9, so hopefully the transition will be
reasonably smooth. - MLD
___
macports-users mailing list
Hi Ben - port rdeps octave +gcc48 does returns lots of ports, but
gcc48 only in that category for me (10.8, MacPorts from svn trunk).
Maybe it is part of a rev-upgrade? - MLD
On Sat, Nov 30, 2013, at 02:06 PM, Ben Abbott wrote:
I noticed that sudo port install octave +gcc48 eventually installs
Hi Jerry - I just updated my 10.9 boot to 10.9.1, then updated MacPorts
to latest; Xcode did not change. Then uninstalled octave and reinstalled
it. No issues for me. Just a guess: Your MacPorts install is out of
date. Try:
{{{
sudo port clean octave
sudo port selfupdate
sudo port install octave
Hi René - This is sort of an off-MacPorts topic, but it's worth
answering, too. Qt4 in MacPorts (qt4-mac) does not change the
functionality of qFatal, nor any of the other logging / message
routines. You should see the same functionality for these routines no
matter if using the pre-compiled
Hi René - Are you saying that you removed the linking with -framework
Carbon from when QtGui is linked and that worked? Or, are you talking
about for some project that's using QtGui via QMake, for which removing
the linking with Carbon worked? I've never tried the former, and the
latter could
On Sun, Mar 16, 2014, at 09:36 PM, René J.V. Bertin wrote:
On Sunday March 16 2014 18:42:53 you wrote:
about for some project that's using QtGui via QMake, for which removing
the linking with Carbon worked? I've never tried the former, and the
latter could easily work depending on the
Hi Jerry - There is a ticket open discussing reincarnating octave-devel
as the 3.8 release series: https://trac.macports.org/ticket/41155 .
I haven't had time to do more than post a patch for folks interested in
trying this change out. The patch provides 3.8.0-rc1 (along with
patchfiles for
I'm pretty sure Octave has issues with the new Clang/LLVM in Xcode 6. We're
working on it during the coming days to verify and hopefully fix. - MLD
On Fri, Sep 26, 2014 at 2:49 AM, Tabitha McNerney tabith...@gmail.com wrote:
I noticed Apple recently made available, for OS X 10.9, XCode 6.0.1
I couldn't get CMake (3.0.2) to install today (10.10 preview 3, Xcode 6.0.1).
It's kinda critical for other ports I maintain, so I'll be poking on it in the
coming week. - MLD
___
macports-users mailing list
macports-users@lists.macosforge.org
Thanks for the info, y'all! I didn't know there was an Xcode beta for 10.10.
I'll try this out Monday. - MLD
On Sep 26, 2014, at 9:15 PM, Ryan Schmidt ryandes...@macports.org wrote:
Right. The Xcode 6 betas included the 10.10 SDK, then it was removed for
Xcode 6 final. cmake requires an
Hi Ray - You actually want to look at the Portfile itself for the
version info. In this case, the one you want is
https://trac.macports.org/browser/trunk/dports/math/octave/Portfile?rev=121949
.. or, revision 121949. The next revision of this Portfile (121950)
bumps the version to 3.8.1.
On Wed, Dec 10, 2014, at 04:03 PM, René J.V. Bertin wrote:
On Wednesday December 10 2014 15:50:59 Lawrence Velázquez wrote:
On Dec 10, 2014, at 2:27 PM, René J.V. Bertin rjvber...@gmail.com wrote:
patches_welcome
You're welcome to try to rework the Qt ports so that they can be
Hi René - If the Makefile is hand-written, it probably does not contain
a way to set DESTROOT or some other variable to direct where to install
stuff outside of PREFIX -- you'll need to read through the Makefile to
verify, generally in the install: section. If this is this case, you
have to add
On Thu, Dec 11, 2014, at 12:38 PM, René J.V. Bertin wrote:
On Thursday December 11 2014 11:53:00 Michael Dickens wrote:
Hi René - If the Makefile is hand-written, it probably does not contain
a way to set DESTROOT or some other variable to direct where to install
stuff outside of PREFIX
On Thu, Dec 11, 2014, at 03:13 PM, Ray Zimmerman wrote:
Now back to my original goal, getting multiple versions of octave installed …
if I now do the following to build version 3.6.4 of Octave …
svn co -r 121949
http://svn.macports.org/repository/macports/trunk/dports/math/octave
cd
FYI that I created a unified patch to bring the CMake port to 3.1.2 from
the current SVN head, and attached it to the appropraite ticket
https://trac.macports.org/ticket/46493#comment:12 . I think this change
keeps the same functionality with the Darwin Platform changes as before;
the CMake devs
Hi Jim - I'm going to work with you off-list since this is a 32/64 bit
issue will require some programming work on my part and testing on
your part. If we come up with something relevant to this list, I'll
email a summary. - MLD
On Wed, Mar 4, 2015, at 06:27 PM, Jim Goudie wrote:
OS X 10.6.8
On Mon, Apr 13, 2015, at 01:35 PM, Eneko Gotzon wrote:
I frequently run:
sudo port clean --all installed
And, that's a good thing. You might also want to try:
{{{
sudo port reclaim
}}}
every so often. Also:
{{{
sudo port selfupdate
}}}
is good to keep 'port' up to date.
But, the main issue is
Hi Enrico - Glad those worked too. As I like to say: cruft happens!
Cleaning often takes care of these build issues.
As to what's going on with running Gimp, I don't know; I don't have or
use Gimp (from MacPorts or elsewhere). Check out the Console.app look
under User Diagnostic Reports to see
Hi Joerg - Can you try:
{{{
sudo port clean octave
sudo port install octave +gcc48
}}}
and see if that helps. Sometimes it does, though I kinda doubt it will
in your case. If not, then do a search
https://trac.macports.org/search to see if someone else has already
reported the same (or very
Hi Enrico - When submitting a build error -- whether on this list or on
a ticket -- please do the following beforehand for the port in issue (in
this case, cmake), and alway submit a full build log (not just the
latest try; see also the first item in the MacPorts FAQ:
Hi Enrico - Glad it worked; you're welcome! As for the others, try
cleaning each, and when the build fails check out each build log to see
if the issue is common or separate. File tickets accordingly, after a
search for whether a ticket is already open with your issues. - MLD
On Mon, Apr 13,
I've been working on a fix to this issue, but haven't finalized it yet.
The problem is that mkoctfile hard-codes -L and -I paths, when what it
should actually do is glean them at runtime just before compiling or
linking. My way around this is to override the settings in mkoctfile by
those
Set the environment variable:
{{{
QMAKE=/opt/local/libexec/qt4/bin/qmake
}}}
before running cmake.
If you're inside a Portfile, then just do:
{{{
PortGroup qt4 1.0
}}}
somewhere before the cmake command.
- MLD
On Fri, Nov 6, 2015, at 09:26 AM, Davide Liessi wrote:
> I'm trying to build a
thus far, luckily. - MLD
On Wed, Oct 14, 2015, at 09:00 AM, Brandon Allbery wrote:
> On Wed, Oct 14, 2015 at 8:57 AM, Michael Dickens
> <michae...@macports.org> wrote:
>> 1) I find no OpenModelica port in my search ("port search
>>OpenModelica"). Maybe this
Hi Adam -
1) I find no OpenModelica port in my search ("port search
OpenModelica"). Maybe this port actually goes by a different name?
Maybe it is local to your system? Since this is a qt4 issue, I'm
happy to help (being the one who committed the change to move the qt4
install into
, 2015, at 03:18 AM, Ryan Schmidt wrote:
On Jul 5, 2015, at 12:50 PM, Michael Dickens wrote:
I've been working on a fix to this issue, but haven't finalized it yet.
The problem is that mkoctfile hard-codes -L and -I paths, when what it
should actually do is glean them at runtime just before
Just built & works for me too (actual testing inside octave), so I
committed the fix in r143912. Thanks for pointing out that issue! - MLD
On Thu, Dec 24, 2015, at 06:55 PM, Ryan Schmidt wrote:
>
> On Dec 24, 2015, at 6:01 AM, Mojca Miklavec wrote:
>
> > On 23 December 2015 at 16:12, Adam
Hi Comer - Looks like you're experiencing ticket #50950 <
https://trac.macports.org/ticket/50950 >. Maybe some part of the
discussion on it will be useful? HTH! - MLD
On Tue, May 24, 2016, at 10:23 AM, Comer Duncan wrote:
> Yesterday I upgraded mac os to El Capitan. All went fine. Later I
>
Hi Yongwei - Would you please attach a patch that updates the boost
install to the latest here < https://trac.macports.org/ticket/50671 >?
That way, folks can try it out & see how/if it works & comment back.
Thanks! - MLD
On Wed, Aug 17, 2016, at 09:39 PM, Yongwei Wu wrote:
> I think the
91 matches
Mail list logo
