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

[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
>>> //  configure on Sun Sep  6 22:42:41 CEST 2015
>>> //  With the following options:
>>> //CXX  = clang++
>>> //CXXFLAGS = -I./../.. -I./../../libs/config/test -g -O2 
>>> -DBOOST_NO_CONFIG
>>> //LDFLAGS  = 
>>> //LIBS = -lm -lpthread 
>>> //
>>
>> This seems ambiguous as to which library is being used libc++ or libstdc++.
>>
>> 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 and secondly with -stdlib=libc++ to 
>> see if that makes any difference.
> 
> Attached are the 'user.hpp' files created with these commands:
> 
> $ CXX='/usr/bin/clang++' CXXFLAGS='-stdlib=libstdc++' sh ./configure
> $ CXX='/usr/bin/clang++' CXXFLAGS='-stdlib=libc++' sh ./configure
> 
> 
> 
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
> 

Ok, this says that clang++ on Lion passes boost's test for rvalue reference 
support. This may be true. If so, then
disabling boost's support for it is not the right thing to do.

Going back to review the situation from the beginning, I looked at git master 
for libcdr and libvisio again.  I see that
the most recent commit in each claims to be a build fix for boost 1.59.  V, are 
you sure that your fix is required with
this most recent commit in place?  It uses a different set of boost defines.

Dave



___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

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

[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 the logfile attached to the initial
report this is

CXX='/usr/bin/clang++'
CXXFLAGS='-pipe -Os -arch x86_64 -stdlib=libstdc++'

The g++ version doesn't really seem relevant because MacPorts shouldn't ever
use it.

> 
> Just to be sure, I ran the configure script twice - on the extracted
> source, and after applying MacPorts' patches: the result was the same.
> 

> The one for clang++ does not set BOOST_NO_CXX11_RVALUE_REFERENCES.

Not only that but it DOES define BOOST_HAS_RVALUE_REFS so that's pretty
definite.   Any fix should probably disable this one too.

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:
> //CXX  = clang++
> //CXXFLAGS = -I./../.. -I./../../libs/config/test -g -O2 -DBOOST_NO_CONFIG
> //LDFLAGS  = 
> //LIBS = -lm -lpthread 
> //

This seems ambiguous as to which library is being used libc++ or libstdc++.

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 and secondly with -stdlib=libc++ to see 
if that makes any difference.

Thanks for the help
Dave




___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

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

[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:
>> //CXX  = clang++
>> //CXXFLAGS = -I./../.. -I./../../libs/config/test -g -O2 
>> -DBOOST_NO_CONFIG
>> //LDFLAGS  =
>> //LIBS = -lm -lpthread
>> //
>
> This seems ambiguous as to which library is being used libc++ or libstdc++.
>
> 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 and secondly with -stdlib=libc++ to see 
> if that makes any difference.
>
As far as I know after talking with the LLVM and GCC folks, the way to
reliably test for '-stdlib=libc++' or '-stdlib=libstdc++' is to
#include a C++ header, and then check for  __GLIBCXX__ (GNU and
'-stdlib=libstdc++'). I don't recall what to check for on an LLVM
system, but you should be able to find it throw one of Marshal Clow's
blog posts.

On a LLVM system, #include . On a GNU system, #include .

Also see https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_macros.html
and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67195.

Jeff
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

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

[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 2015
>> //  With the following options:
>> //CXX  = clang++
>> //CXXFLAGS = -I./../.. -I./../../libs/config/test -g -O2 
>> -DBOOST_NO_CONFIG
>> //LDFLAGS  = 
>> //LIBS = -lm -lpthread 
>> //
> 
> This seems ambiguous as to which library is being used libc++ or libstdc++.
> 
> 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 and secondly with -stdlib=libc++ to see 
> if that makes any difference.

Attached are the 'user.hpp' files created with these commands:

$ CXX='/usr/bin/clang++' CXXFLAGS='-stdlib=libstdc++' sh ./configure
$ CXX='/usr/bin/clang++' CXXFLAGS='-stdlib=libc++' sh ./configure
//  (C) Copyright Boost.org 2001.
//  Do not check in modified versions of this file,
//  This file may be customised by the end user, but not by boost.

//
//  Use this file to define a site and compiler specific
//  configuration policy, this version was auto-generated by
//  configure on Mon Sep  7 09:31:22 CEST 2015
//  With the following options:
//CXX  = /usr/bin/clang++
//CXXFLAGS = -I./../.. -I./../../libs/config/test -stdlib=libstdc++ 
-DBOOST_NO_CONFIG
//LDFLAGS  = 
//LIBS = -lm -lpthread 
//

// define this to disable all config options,
// excluding the user config.  Use if your
// setup is fully ISO complient, and has no
// useful extentions, or for autoconf generated
// setups:
#ifndef BOOST_NO_CONFIG
#  define BOOST_NO_CONFIG
#endif


// define if you want to disable threading support, even
// when available:
// #define BOOST_DISABLE_THREADS

// define if you want the regex library to use the C locale
// even on Win32:
// #define BOOST_REGEX_USE_C_LOCALE

// define this is you want the regex library to use the C++
// locale:
// #define BOOST_REGEX_USE_CPP_LOCALE


//
// options added by configure:
//
#define BOOST_MSVC6_MEMBER_TEMPLATES
#define BOOST_HAS_VARIADIC_TMPL
#define BOOST_HAS_UNISTD_H
#define BOOST_HAS_STDINT_H
#define BOOST_HAS_SIGACTION
#define BOOST_HAS_SCHED_YIELD
#define BOOST_HAS_RVALUE_REFS
#define BOOST_HAS_PTHREADS
#define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE
#define BOOST_HAS_PARTIAL_STD_ALLOCATOR
#define BOOST_HAS_NRVO
#define BOOST_HAS_NL_TYPES_H
#define BOOST_HAS_NANOSLEEP
#define BOOST_HAS_LONG_LONG
#define BOOST_HAS_LOG1P
#define BOOST_HAS_INT128
#define BOOST_HAS_GETTIMEOFDAY
#define BOOST_HAS_EXPM1
#define BOOST_HAS_DIRENT_H
#define BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX
#define BOOST_NO_CXX11_UNICODE_LITERALS
#define BOOST_NO_CXX11_STATIC_ASSERT
#define BOOST_NO_CXX11_SCOPED_ENUMS
#define BOOST_NO_CXX11_RAW_LITERALS
#define BOOST_NO_CXX11_NULLPTR
#define BOOST_NO_CXX11_NOEXCEPT
#define BOOST_NO_CXX11_LAMBDAS
#define BOOST_NO_MS_INT64_NUMERIC_LIMITS
#define BOOST_NO_CXX11_EXPLICIT_CONVERSION_OPERATORS
#define BOOST_NO_CXX11_DELETED_FUNCTIONS
#define BOOST_NO_CXX11_DEFAULTED_FUNCTIONS
#define BOOST_NO_CXX11_DECLTYPE_N3276
#define BOOST_NO_CXX11_DECLTYPE
#define BOOST_NO_CXX11_HDR_FUNCTIONAL
#define BOOST_NO_CXX14_VARIABLE_TEMPLATES
#define BOOST_NO_CXX14_RETURN_TYPE_DEDUCTION
#define BOOST_NO_CXX14_AGGREGATE_NSDMI
#define BOOST_NO_CXX14_INITIALIZED_LAMBDA_CAPTURES
#define BOOST_NO_CXX14_HDR_SHARED_MUTEX
#define BOOST_NO_CXX14_GENERIC_LAMBDAS
#define BOOST_NO_CXX14_DIGIT_SEPARATORS
#define BOOST_NO_CXX14_DECLTYPE_AUTO
#define BOOST_NO_CXX14_CONSTEXPR
#define BOOST_NO_CXX11_USER_DEFINED_LITERALS
#define BOOST_NO_CXX11_TRAILING_RESULT_TYPES
#define BOOST_NO_CXX11_STD_ALIGN
#define BOOST_NO_CXX11_SMART_PTR
#define BOOST_NO_CXX11_NUMERIC_LIMITS
#define BOOST_NO_CXX11_NON_PUBLIC_DEFAULTED_FUNCTIONS
#define BOOST_NO_CXX11_HDR_UNORDERED_SET
#define BOOST_NO_CXX11_HDR_UNORDERED_MAP
#define BOOST_NO_CXX11_HDR_TYPEINDEX
#define BOOST_NO_CXX11_HDR_TYPE_TRAITS
#define BOOST_NO_CXX11_HDR_TUPLE
#define BOOST_NO_CXX11_HDR_THREAD
#define BOOST_NO_CXX11_HDR_SYSTEM_ERROR
#define BOOST_NO_CXX11_HDR_REGEX
#define BOOST_NO_CXX11_HDR_RATIO
#define BOOST_NO_CXX11_HDR_RANDOM
#define BOOST_NO_CXX11_HDR_MUTEX
#define BOOST_NO_CXX11_HDR_INITIALIZER_LIST
#define BOOST_NO_CXX11_HDR_FUTURE
#define BOOST_NO_CXX11_HDR_FORWARD_LIST
#define BOOST_NO_CXX11_HDR_CONDITION_VARIABLE
#define BOOST_NO_CXX11_HDR_CODECVT
#define BOOST_NO_CXX11_HDR_CHRONO
#define BOOST_NO_CXX11_HDR_ATOMIC
#define BOOST_NO_CXX11_HDR_ARRAY
#define BOOST_NO_CXX11_ATOMIC_SMART_PTR
#define BOOST_NO_CXX11_ALLOCATOR
#define BOOST_NO_CXX11_ALIGNAS
#define BOOST_NO_CXX11_ADDRESSOF
#define BOOST_NO_CXX11_CONSTEXPR
#define BOOST_NO_CXX11_CHAR32_T
#define BOOST_NO_CXX11_CHAR16_T
//  (C) Copyright Boost.org 2001.
//  Do not check in modified versions of this file,
//  This file may be customised by 

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

[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 brew stuff I guess I would need 
> the variants +wxwidgets +pangocairo +pdflib +x11
>
> So how would I specify the variants I want in depends_lib?

Having +auaterm +luaterm enabled certainly won't be a problem, but in
general I really doubt that the software requires *exactly* those
terminals enabled. In particular I don't understand why one would need
both X11 and wxWidgets at the same time. And if you have pangocairo
(note that this also requires pango, not just cairo; having just cairo
installed might not be sufficient to get the desired functionality),
there is no need for yet another PDF library because pangocairo knows
how to generate a PDF (and even if you set "set term pdf", it will
automatically work and use pdfcairo instead of pdf even if pdflib is
not installed).

Just start with defaults for now and check how it works. You could in
principle use something like this:

PortGroup active_variants 1.1
require_active_variants gnuplot wxwidgets

to make sure that wxWidgets has been compiled into gnuplot, but leave
that for the end.

Mojca
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

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

[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 and secondly with -stdlib=libc++ to 
>>> see if that makes any difference.
>>
>> Attached are the 'user.hpp' files created with these commands:
>>
>> $ CXX='/usr/bin/clang++' CXXFLAGS='-stdlib=libstdc++' sh ./configure
>> $ CXX='/usr/bin/clang++' CXXFLAGS='-stdlib=libc++' sh ./configure

> Ok, this says that clang++ on Lion passes boost's test for rvalue reference 
> support. This may be true. If so, then
> disabling boost's support for it is not the right thing to do.
> 
> Going back to review the situation from the beginning, I looked at git master 
> for libcdr and libvisio again.  I see that
> the most recent commit in each claims to be a build fix for boost 1.59.  V, 
> are you sure that your fix is required with
> this most recent commit in place?  It uses a different set of boost defines.

Yes, it is required for git master of libvisio and libcdr too, at least
when compiling on OS X 10.7.5 with boost 1.59.

I redid the tests I had already done earlier after seeing the latest
commits upstream wrt boost 1.59 (i.e. comment out all boost-related
workarounds in the two devel portfiles, update port to latest git master
and build).


Tests with libvisio from git master:


1) all boost-related workarounds in portfile commented out:

build fails with:
> :info:build ./VSDXMLTokenMap.h:14:10: fatal error: 'tokens.h' file not found

(AFAICT 'tokens.h' is a generated file, which apparently is not
generated after the latest upstream commit - I don't know why. I also
tested variations of that commit, adding only
'-DBOOST_ERROR_CODE_HEADER_ONLY' or '-DBOOST_SYSTEM_NO_DEPRECATED' to
the CPPFLAGS in 'src/lib/Makefile.am': either way 'tokens.h' fails to be
generated.)


2) all boost-related workarounds in portfile commented out, last
upstream commit which claims to fix build with boost 1.59 reverted:

build fails with:
> :info:build ${prefix}/include/boost/thread/detail/move.hpp:31:10: fatal 
> error: 'type_traits' file not found


3) enabling workaround '-DBOOST_NO_CXX11_RVALUE_REFERENCES',  last
upstream commit which claims to fix build with boost 1.59 reverted:

build fails with:
> :info:build Undefined symbols for architecture x86_64:
> :info:build   "boost::system::system_category()", referenced from:
> :info:build   __GLOBAL__I_a in VSDContentCollector.o
> :info:build   __GLOBAL__I_a in VSDXMLParserBase.o
> :info:build   "boost::system::generic_category()", referenced from:
> :info:build   __GLOBAL__I_a in VSDContentCollector.o
> :info:build   __GLOBAL__I_a in VSDXMLParserBase.o
> :info:build ld: symbol(s) not found for architecture x86_64
> :info:build clang: error: linker command failed with exit code 1 (use -v to 
> see invocation)


4) enabling both workarounds for boost in the portfile, last upstream
commit which claims to fix build with boost 1.59 reverted:

build succeeds.


Tests with libcdr from git master:
==

1) all boost-related workarounds in portfile commented out:

build fails with:
> :info:build ${prefix}/include/boost/thread/detail/move.hpp:31:10: fatal 
> error: 'type_traits' file not found


2) enabling workaround '-DBOOST_NO_CXX11_RVALUE_REFERENCES':

buld fails with:
> :info:build Undefined symbols for architecture x86_64:
> :info:build   "boost::system::system_category()", referenced from:
> :info:build   __GLOBAL__I_a in libcdr-internal.a(CDRParser.o)
> :info:build   "boost::system::generic_category()", referenced from:
> :info:build   __GLOBAL__I_a in libcdr-internal.a(CDRParser.o)
> :info:build ld: symbol(s) not found for architecture x86_64
> :info:build clang: error: linker command failed with exit code 1 (use -v to 
> see invocation)


3) enabling both workarounds for boost in the portfile:

build succeeds.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

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

[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 MacPorts-ported compiler?
>
> Wouldn't it be more correct to detect gcc on OS X as apparently this
> feature is not supported no matter where the compiler comes from?
>
Thanks.

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

What strings or bits is MacPorts providing?

Thanks again.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

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

[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)"
>>> #define __apple_build_version__ 5030040
>> 
>> 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.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: pan2 did not install on SnowLeopard and Xode 4

[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 this a permissible
> configuration for this port on Mavericks and Yosemite until the libc++ issue 
> is addressed upstream? Haven't checked
> whether this will work on El Capitan as yet.

Great idea. Committed just this change.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

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

[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
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

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

[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).
>>> 
>>> How do I reliably detect a MacPorts-ported compiler?
>> 
>> Wouldn't it be more correct to detect gcc on OS X as apparently this
>> feature is not supported no matter where the compiler comes from?
>> 
> Thanks.
> 
> 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 clang, not gcc. 

> What strings or bits is MacPorts providing?

If you want to know if gcc is FSF GCC compiled by MacPOrts, you could inspect 
the version string:

$ gcc-mp-6 --version
gcc-mp-6 (MacPorts gcc6 6-20150830_0+universal) 6.0.0 20150830 (experimental)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Note that this inclues the string "MacPorts".

However, I reiterate what Rainer said: the issue being discussed here is not 
(we believe) specific to MacPorts, but rather would occur anytime you compile 
FSF GCC on OS X.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

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

[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
ticket, which made it clear that the problem is with Apple's ld?

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

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

[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 clang, not gcc.

Right, but the APPLE_CC tells me its an Apple port.

>> What strings or bits is MacPorts providing?
>
> If you want to know if gcc is FSF GCC compiled by MacPOrts, you could inspect 
> the version string:
>
> $ gcc-mp-6 --version
> gcc-mp-6 (MacPorts gcc6 6-20150830_0+universal) 6.0.0 20150830 (experimental)
> Copyright (C) 2015 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> Note that this includes the string "MacPorts".

OK, thanks.

Jeff
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: unbound did not start automatically after reboot

[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 unbound
> /opt/local/etc/LaunchDaemons/org.macports.unbound/org.macports.unbound.plist: 
> Operation already in progress
> 
> So I must 
> $ sudo port unload unbound
> $ sudo port load unbound
> 
> Seldom it starts after reboot. My guess, the start command for unbound comes 
> to early in the OS X startup.
> 
> Why I could set a waiting time in the
> org.macports.unbound.plist

I'm not aware of a way to set a waiting time in a plist.

I believe you can set dependencies on some things, like indicating that a plist 
requires the network be up, or that it should be restarted if the network 
connection changes?

One reason why a launchd plist might not work at startup is if your ports are 
actually installed on a second volume, not on the startup disk. Is that the 
case?

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

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

[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
> 
> The default for the configure phase is to run a script called configure. I 
> guess this project doesn't have one.

no, it doesn't have a configure script. As I said it is a completely homegrown 
build system based on cmake. First it fetches the sources using git, then 
builds and even installs (of course not in the right location) torch. 

> 
> 
>> This happens because this whole project is based on a rather weird build 
>> system with shell scripts downloaded from remote hosts and executed locally, 
>> it uses homebrew, cmake and luarocks to build the whole thing …
> 
> Everything that is needed should be fetched in the fetch phase. We would not 
> want a build system to fetch additional files. We do have a couple ports that 
> do this, but it causes various problems and should be avoided. 

Fixing that would be way above my level. I am even struggling setting up 
supposedly simple Portfiles. Here is what I did for now. see attached portfile. 



Portfile
Description: Binary data


> 
> 
>> I managed to work around homebrew for now. I have no idea how to skip the 
>> configure phase of macports nor how to invoke install.sh later … any ideas?
> 
> If you want there to be no configure phase, use:
> 
> use_configure no
> 
> If instead you want to run a different program in the configure phase, change 
> configure.cmd and possible configure.args and configure.pre_args to match. 
> 
> This should already be mentioned in the guide...

There is also the output of running "sudo port -v install torch" for the 
interested ones, I can send this on request (not to the list because it is too 
large), There you can see that everything is done right but in the wrong way 
(for the MacPorts system)


regards,

Lars

P.S.: If you have question on the Portfile please ask.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

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

[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 apparently this
feature is not supported no matter where the compiler comes from?

Rainer
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users