Re: boost libstdc++ issue (was libvisio error)

2015-09-07 Thread David Evans
On 9/7/15 12:44 AM, su_v wrote: > On 2015-09-07 09:14 (+0200), David Evans wrote: > >> According to your results for the clang++ case the configuration used >> was >> >>> // Use this file to define a site and compiler specific >>> // configuration policy, this version was auto-generated by >>>

Re: boost libstdc++ issue (was libvisio error)

2015-09-07 Thread David Evans
On 9/6/15 2:08 PM, su_v wrote: > The boost configure script prefers g++ unless CXX is explicitly set > to clang++ or c++. > Attached are both user.hpp files (for llvm-gcc-4.2++ and for clang++). I think what we want to test is the same configuration as MacPorts uses when compiling libvisio. From

Re: boost libstdc++ issue (was libvisio error)

2015-09-07 Thread Jeffrey Walton
> According to your results for the clang++ case the configuration used > was > >> // Use this file to define a site and compiler specific >> // configuration policy, this version was auto-generated by >> // configure on Sun Sep 6 22:42:41 CEST 2015 >> // With the following options: >> //

Re: boost libstdc++ issue (was libvisio error)

2015-09-07 Thread su_v
On 2015-09-07 09:14 (+0200), David Evans wrote: > According to your results for the clang++ case the configuration used > was > >> // Use this file to define a site and compiler specific >> // configuration policy, this version was auto-generated by >> // configure on Sun Sep 6 22:42:41 CEST

Re: Writing portfiles: How to depend on a certain variant of a port?

2015-09-07 Thread Mojca Miklavec
On Sun, Sep 6, 2015 at 8:09 PM, Lars Sonchocky-Helldorf wrote: > > brew install gnuplot --with-wxmac --with-cairo --with-pdflib-lite > --with-x11 --without-lua > - > > now for gnuplot the default variants are +aquaterm +luaterm +pangocairo > +wxwidgets +x11 but according to the above

Re: boost libstdc++ issue (was libvisio error)

2015-09-07 Thread su_v
On 2015-09-07 11:20 (+0200), David Evans wrote: > On 9/7/15 12:44 AM, su_v wrote: >> On 2015-09-07 09:14 (+0200), David Evans wrote: >>> I wonder if you could run the clang++ test again first with >>> -stdlib=libstdc++ appended to configure's own CXXFLAGS >>> as MacPorts does in the libvisio case

Re: How to reliable detect a MacPorts-ported compiler?

2015-09-07 Thread Jeffrey Walton
On Mon, Sep 7, 2015 at 5:04 PM, Rainer Müller wrote: > On 2015-09-07 02:46, Jeffrey Walton wrote: >> We have some users reporting issues under MacPort-ported compilers >> (specifically, Issue 37664, https://trac.macports.org/ticket/37664). >> >> How do I reliably detect a

Re: How to reliable detect a MacPorts-ported compiler?

2015-09-07 Thread Ryan Schmidt
On Sep 7, 2015, at 8:43 PM, Jeffrey Walton wrote: >>> For Apple, we can detect Apple ported gear with: >>> >>> $ clang++ -dM -E - < /dev/null | grep -i apple >>> #define __APPLE_CC__ 6000 >>> #define __APPLE__ 1 >>> #define __VERSION__ "4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)" >>>

Re: pan2 did not install on SnowLeopard and Xode 4

2015-09-07 Thread Ryan Schmidt
On Sep 5, 2015, at 8:51 AM, David Evans wrote: > However, it does build and run with libstdc++ using > > configure.cxx_stdlib libstdc++ > > because none of its dependencies use libc++. > > Since it's not likely that any other port using libc++ will have a binary > dependency on pan2, isn't

Re: How to reliable detect a MacPorts-ported compiler?

2015-09-07 Thread Jeffrey Walton
>>> Well, that's clang, not gcc. >> >> Right, but the APPLE_CC tells me its an Apple port. > > Right: it tells you it is an Apple fork of that compiler. > > MacPorts does not fork things. We package the original thing. For our purposes (identification), it does not matter. Jeff

Re: How to reliable detect a MacPorts-ported compiler?

2015-09-07 Thread Ryan Schmidt
On Sep 7, 2015, at 5:20 PM, Jeffrey Walton wrote: > On Mon, Sep 7, 2015 at 5:04 PM, Rainer Müller wrote: >> On 2015-09-07 02:46, Jeffrey Walton wrote: >>> We have some users reporting issues under MacPort-ported compilers >>> (specifically, Issue 37664, https://trac.macports.org/ticket/37664).

Re: How to reliable detect a MacPorts-ported compiler?

2015-09-07 Thread Brandon Allbery
On Sun, Sep 6, 2015 at 8:46 PM, Jeffrey Walton wrote: > We have some users reporting issues under MacPort-ported compilers > (specifically, Issue 37664, https://trac.macports.org/ticket/37664 > > ). > Did you test the system linker as mentioned in the last comment on that

Re: How to reliable detect a MacPorts-ported compiler?

2015-09-07 Thread Jeffrey Walton
>> For Apple, we can detect Apple ported gear with: >> >> $ clang++ -dM -E - < /dev/null | grep -i apple >> #define __APPLE_CC__ 6000 >> #define __APPLE__ 1 >> #define __VERSION__ "4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)" >> #define __apple_build_version__ 5030040 > > Well, that's

Re: unbound did not start automatically after reboot

2015-09-07 Thread Ryan Schmidt
On Sep 6, 2015, at 7:56 AM, FritzS wrote: > David, Ryan, > who is the unbound specialist? I've never used unbound. > My in MacPorts installed unbound did not start automatically after reboot. > But it seems to run, but not listed in the process list > If I want to start > $ sudo port load

preliminary Portfile for torch 7 (was: Re: Writing portfiles: How to download a master.zip and not a master.zip.tar.gz)

2015-09-07 Thread Lars Sonchocky-Helldorf
Hi Ryan, Am 07.09.2015 um 04:29 schrieb Ryan Schmidt: > On Sep 6, 2015, at 19:34, Lars Sonchocky-Helldorf wrote: > >> Thanks to your help I am now one step further. Now it fails when trying to >> configure the port: >> >> ---> Configuring torch >> sh: ./configure: No such file or directory >

Re: How to reliable detect a MacPorts-ported compiler?

2015-09-07 Thread Rainer Müller
On 2015-09-07 02:46, Jeffrey Walton wrote: > We have some users reporting issues under MacPort-ported compilers > (specifically, Issue 37664, https://trac.macports.org/ticket/37664). > > How do I reliably detect a MacPorts-ported compiler? Wouldn't it be more correct to detect gcc on OS X as