It's growing on me.
This will be quite useful on 10.4 and 10.5 PPC, where it's the only
way forward, for gtk3 for example.
I noticed this method enables thread-local storage on 10.6, which
until now was not available (at least I didnt' figure it out).
There is a flag to compile libgcc so it defa
> On Jan 19, 2017, at 12:21, Craig Treleaven wrote:
>
> Craig Treleaven (ctreleaven) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/39211f92fda4458526220604cef41079bd7b3899
>
> The following commit(s) were added to refs
> On Jan 19, 2017, at 20:28, Ivan Larionov wrote:
>
>> On Thu, Jan 19, 2017 at 5:58 PM, Ryan Schmidt
>> wrote:
>>
>> > On Jan 19, 2017, at 17:29, Ivan Larionov wrote:
>> >
>> > How do we control postgresql version for py-psycopg2 when installing pgcli
>> > then? Is there a way to do someth
pgcli doesn't care, but, for example, user of postgresql96 don't want to
install postgresql95 when installing pgcli just because default variant of
py-psycopg2 is postgresql95.
On Thu, Jan 19, 2017 at 5:58 PM, Ryan Schmidt
wrote:
>
> > On Jan 19, 2017, at 17:29, Ivan Larionov wrote:
> >
> > How
> On Jan 19, 2017, at 17:29, Ivan Larionov wrote:
>
> How do we control postgresql version for py-psycopg2 when installing pgcli
> then? Is there a way to do something like this?
>
> if variant postgresql96 {
> depends_lib-append py{python.version}-psycopg2 +postgresql96
> }
You cannot decl
> On Jan 19, 2017, at 2:04 PM, Chris Jones wrote:
>
> I don't think we should, under any circumstances, but making the use of gcc
> to build c++ ports a standard practise.
Just to be clear, the proposal is not to use gcc but to use clang with
libstdc++ and *only* on systems where it has been
How do we control postgresql version for py-psycopg2 when installing pgcli
then? Is there a way to do something like this?
if variant postgresql96 {
depends_lib-append py{python.version}-psycopg2 +postgresql96
}
On Thu, Jan 19, 2017 at 6:39 AM, Aljaž Srebrnič wrote:
> > On 17 gen 2017, at 19:
Hi,
For me, the better approach is to
1. On systems where the default system compiler is clang and thus uses libc++,
when neccessary (such as c++14, 17, support, which over time will become
as much of an issues as c++11) use one of the macports clang compilers that
works on that platform
I do not know if this helps with your concerns or not, but in the current
proposal, _GLIBCXX_USE_CXX11_ABI is only set to 0 for
macOS prior to Mavericks, where libstdc++ is the default.
So _GLIBCXX_USE_CXX11_ABI is being used as it was intended, as a mechanism to
facilitate transition.
-Marcus
> On 17 gen 2017, at 19:09, Joshua Root wrote:
>
> I guess you're aware that this doesn't actually do anything, and the variants
> only exist to encourage the user to specify one when installing?
Yep, that was the intention.
> The downsides:
> * The situation where the user doesn't specify a v
10 matches
Mail list logo
