On 2014-9-9 12:06 , Jeremy Lavergne wrote:
> DEBUG: dlist_eval: all entries in dependency list have unsatisfied
> dependencies; can't process
>
>
> What happened there?
Dependency cycle, most likely.
- Josh
___
macports-dev mailing list
macports-dev@
---> Computing dependencies for kdepim4
The following dependencies will be installed:
…
Continue? [Y/n]:
Error: Follow http://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port kdepim4 failed
So.. that’s not helpful at all.
the log for kdepim4 shows a blank line:
On Sep 8, 2014, at 2:21 PM, Ryan Schmidt wrote:
>
> On Sep 8, 2014, at 2:35 PM, Thomas G Lockhart wrote:
>>
>> On Sep 8, 2014, at 1:05 AM, Ryan Schmidt wrote:
>>
>>>
>>> On Sep 8, 2014, at 12:37 AM, Thomas G Lockhart wrote:
Great. btw, it seems that the patch files are no longer ne
> On Sep 8, 2014, at 3:23 PM, m...@macports.org wrote:
>
> Revision
> 125176
> Author
> m...@macports.org
> Date
> 2014-09-08 13:23:04 -0700 (Mon, 08 Sep 2014)
> Log Message
>
> ocaml-camlp4: dont use "+" in version string
> Modified Paths
>
> • trunk/dports/lang/ocaml-camlp4/Portfile
> D
On Sep 8, 2014, at 2:35 PM, Thomas G Lockhart wrote:
>
> On Sep 8, 2014, at 1:05 AM, Ryan Schmidt wrote:
>
>>
>> On Sep 8, 2014, at 12:37 AM, Thomas G Lockhart wrote:
>>>
>>> Great. btw, it seems that the patch files are no longer necessary, though I
>>> have not yet done enough interoperabil
On Sep 8, 2014, at 4:15 PM, Jeremy Lavergne wrote:
>
> Were considering enabling trace mode by default on the buildbots?
I don't know of any specifics, but the longer-term plan is to just always have
trace mode on, right?
--
Daniel J. Luke
On Sep 8, 2014, at 3:35 PM, Thomas G Lockhart wrote:
>
>
> On Sep 8, 2014, at 1:05 AM, Ryan Schmidt wrote:
>
>>
>> On Sep 8, 2014, at 12:37 AM, Thomas G Lockhart wrote:
>>>
>>> Great. btw, it seems that the patch files are no longer necessary, though I
>>> have not yet done enough interoper
On Mon, Sep 8, 2014 at 2:44 PM, Brandon Allbery wrote:
> So the cases here are:
>
> - pre-C++11 C++ support must use the system libstdc++ (the binary-only
> backward compatibility one on newer systems whose development C++ runtime
> is libc++).
>
> - C++11 C++ support must either face the license
Were considering enabling trace mode by default on the buildbots?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
On Sep 8, 2014, at 1:05 AM, Ryan Schmidt wrote:
>
> On Sep 8, 2014, at 12:37 AM, Thomas G Lockhart wrote:
>>
>> Great. btw, it seems that the patch files are no longer necessary, though I
>> have not yet done enough interoperability testing to be absolutely certain.
>> I’ll open a ticket at
On Mon, Sep 8, 2014 at 2:35 PM, Lawrence Velázquez
wrote:
> So if we start using our own libc++abi on older OS X, wouldn't C++
> binaries built with Xcode's compilers be unable to interoperate with
> binaries built with MacPorts compilers?
>
Only if you try to use it for pre-C++11; but in that c
> On Mon, Sep 8, 2014 at 2:22 PM, Lawrence Velázquez
> wrote:
>> - My first assertion is that MacPorts' libstdc++ is broken on OS X because
>> it doesn't use the system C++ runtime, libc++abi. This assertion, strictly
>> speaking, is not about C++11 support.
>
> It strictly IS about C++11 supp
On Mon, Sep 8, 2014 at 2:22 PM, Lawrence Velázquez
wrote:
> - My first assertion is that MacPorts' libstdc++ is broken on OS X because
> it doesn't use the system C++ runtime, libc++abi. This assertion, strictly
> speaking, is not about C++11 support.
>
It strictly IS about C++11 support, becaus
On Sep 8, 2014, at 2:08 PM, Brandon Allbery wrote:
> On Mon, Sep 8, 2014 at 1:24 PM, Lawrence Velázquez
> wrote:
>> That's true, but it's a red herring. If our libstdc++ wasn't broken, ports
>> would not have to avoid it.
>>
>> Our actual problem is that none of the g++ compilers we distribut
On Mon, Sep 8, 2014 at 1:24 PM, Lawrence Velázquez
wrote:
> That's true, but it's a red herring. If our libstdc++ wasn't broken, ports
> would not have to avoid it.
>
> Our actual problem is that none of the g++ compilers we distribute are
> viable because they don't use the system's C++ runtime.
On Sep 8, 2014, at 4:52 AM, Mojca Miklavec wrote:
> It would be weird if we forced users to switch to a different runtime.
Herein lies the problem.
Users shouldn't be able to "switch runtimes" because there should not be more
than one runtime available. There should only be the system libc++ab
(Moving to macports-dev, which is long overdue. Prior history at
http://thread.gmane.org/gmane.os.apple.macports.user/35812)
On Sep 8, 2014, at 4:24 AM, Mojca Miklavec wrote:
> On Sun, Sep 7, 2014 at 8:36 PM, Lawrence Velázquez wrote:
>>
>> All this talk about keeping track of C++ runtimes an
On Sep 8, 2014, at 1:05 AM, Ryan Schmidt wrote:
> On Sep 8, 2014, at 12:37 AM, Thomas G Lockhart wrote:
>>
>> Great. btw, it seems that the patch files are no longer necessary, though I
>> have not yet done enough interoperability testing to be absolutely certain.
>> I’ll open a ticket at some
On Sep 8, 2014, at 12:37 AM, Thomas G Lockhart wrote:
>
> Great. btw, it seems that the patch files are no longer necessary, though I
> have not yet done enough interoperability testing to be absolutely certain.
> I’ll open a ticket at some point to get them to go away.
I agree the patch for C
On Sep 8, 2014, at 12:37 AM, Thomas G Lockhart wrote:
>
>>> Can we close out the issues (including a very old #23558) and get a fresh
>>> start on issues for these ports?
>>
>> #23558 has not been resolved...
>
> And never will be. It is written on snow leopard, and involves a problem with
>
20 matches
Mail list logo
