It's possible (if hopefully unlikely) there are subtle semantic
differences that they rely on. Safest would be to use -std=gnu89
instead, which gcc-4.2 does accept, and in later gcc versions specifies
the same behaviour as gnu90. (The reason for the synonym is that ISO C90
is identical to ANSI C89.
On Thu, Jun 6, 2013 at 11:35 PM, Ryan Schmidt wrote:
> Please allow glib2-devel to satisfy this dependency by writing it this way:
>
> path:lib/pkgconfig/glib-2.0.pc:glib2
Done: r106747
Cheers
Adam
___
macports-dev mailing list
macports-dev@lists.mac
On Jun 6, 2013, at 23:40, r...@macports.org wrote:
> Revision: 106746
> https://trac.macports.org/changeset/106746
> Author: r...@macports.org
> Date: 2013-06-06 21:40:14 -0700 (Thu, 06 Jun 2013)
> Log Message:
> ---
> science/lscsoft-deps: add new deps and remove ones no l
On Jun 6, 2013, at 21:16, Michael Dickens wrote:
> Using the github portgroup removes a few of the entries, so I'll go with
> it. But, I still have to override the fetch.type to be from git, since
> there does not seem to be any other form of retrieving the source; no
> tarball or even any tags
I can replicate the error by selecting "configure.compiler=llvm-gcc-4.2"
on my 10.8 box. After some testing, I see no reason why they use
"-std=gnu90" at all -- it does not seem to impact compilation, at least
on OSX. Maybe it works on some other host OS. So, I'm just removing
the use of it. - ML
Using the github portgroup removes a few of the entries, so I'll go with
it. But, I still have to override the fetch.type to be from git, since
there does not seem to be any other form of retrieving the source; no
tarball or even any tags of relevance. I tried :) - MLD
On Thu, Jun 6, 2013, at 07
Good idea. I'll look into it. - MLD
On Thu, Jun 6, 2013, at 07:23 PM, Ryan Schmidt wrote:
> Since this is hosted at github, using the github portgroup might take
> care of some of these details for you. Is there a reason why you must
> fetch from git? If using a tarball is possible, that is prefer
On Jun 5, 2013, at 20:42, michae...@macports.org wrote:
> Revision: 106713
> https://trac.macports.org/changeset/106713
> Author: michae...@macports.org
> Date: 2013-06-05 18:42:16 -0700 (Wed, 05 Jun 2013)
> Log Message:
> ---
> hackrf: initial port addition.
>
> Added Pat
On 06/giu/2013, at 08:19, Ryan Schmidt wrote:
> On Jun 5, 2013, at 02:55, g...@macports.org wrote:
>
>> Revision: 106691
>> https://trac.macports.org/changeset/106691
>> Author: g...@macports.org
>> Date: 2013-06-05 00:55:54 -0700 (Wed, 05 Jun 2013)
>> Log Message:
>> ---
>
Interesting; thanks! I'll look into it shortly. - MLD
On Thu, Jun 6, 2013, at 01:50 PM, Ryan Schmidt wrote:
> I can reproduce this problem on 10.6. According to
> build/CMakeFiles/CMakeError.log the reason why this failed is "-std=gnu90" is
> not recognized by gcc 4.2:
_
On Jun 6, 2013, at 06:23, Michael Dickens wrote:
> http://build.macports.org/builders/buildports-snowleopard-x86_64/builds/17877
>
> Build Source Stamp: [branch trunk] 106716
>
> The error is:
> {{{
> -- Looking for include file pthread.h
> -- Looking for include file pthread.h - not found
> CM
On 2013-6-7 02:16 , Bradley Giesbrecht wrote:
> It took me a while to find why "port outdated" was failing.
>
> I had a port installed that had revision set to and empty string.
>
> I doubt this is a common problem for developers but I mention it in the case
> that a test to verify that $install
It took me a while to find why "port outdated" was failing.
I had a port installed that had revision set to and empty string.
I doubt this is a common problem for developers but I mention it in the case
that a test to verify that $installed_revision and $latest_revision are numbers
would be wor
Hello,
Thank you for the patch information, it indeed seems to be exactly the same
issue. However, it still seems a lot to patch qt for only one port, as also
there may other unforeseen consequences, as also mentioned before. It other
cases rise, then it would probably be worth.
I was not aw
The below looks correct from my reading of the Qt installed files. - MLD
On Jun 5, 2013, at 11:50 PM, Ian Wadham wrote:
> From what I can gather, QT_NO_STL is intended for platforms where the
> standard C++ library (STL/std) is not available.
Not quite, though it can mean that too. Even if the
http://build.macports.org/builders/buildports-snowleopard-x86_64/builds/17877
Build Source Stamp: [branch trunk] 106716
The error is:
{{{
-- Looking for include file pthread.h
-- Looking for include file pthread.h - not found
CMake Error at
/opt/local/share/cmake-2.8/Modules/FindPackageHandleStan
On 2013-6-1 05:21 , Jeremy Lavergne wrote:
> Let's kick it out the door then.
> http://trac.macports.org/browser/trunk/base/portmgr/ReleaseProcess
I'll start a branch and package up a first beta over the weekend.
- Josh
___
macports-dev mailing list
mac
17 matches
Mail list logo
