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

[su_v]

On 2015-09-05 17:40 (+0200), David Evans wrote:
> On 9/5/15 8:36 AM, David Evans wrote:
>> On 9/5/15 7:41 AM, echothevoid wrote:
>>> Hello!
>>>
>>> I  got an error after running regular sudo port upgrade outdatedcommand.
>>> The log tells me that:
>>> :info:build /opt/local/include/boost/thread/detail/move.hpp:31:10: fatal 
>>> error: 'type_traits' file not found
>>> I have found a similar issue on: 
>>> http://stackoverflow.com/questions/14104298/clang-boostspirit-and-c11 but 
>>> do not know
>>> how to fix it in the macport's way.
>>> I am using 10.7.5 Lion, with Xcode version 4.6.3.
>>> The outcome of: 
>>> port installed | grep gcc
>>>   gcc49 @4.9.3_0 (active)
>>>   gcc_select @0.1_8 (active)
>>>   libgcc @5.2.0_0 (active)
>>>
>>> Can you suggest a newbie like me what to do next? 
>>>
>>> Many thanks,
>>> void
>>>
>>>
>>
>> As indicated in your stackoverflow.com reference, this is not a problem with 
>> libvisio per se but a problem with boost
>> when using libstdc++ (default c++ lib on Mac OS X earlier than 10.9).  This 
>> builds correctly on 10.9+ where libc++ is
>> the default.
>>
>> Now that trac is back up, suggest you file a ticket against boost including 
>> the information included in this message and
>> attach your log file there as well.  Don't forget to CC the boost 
>> maintainer.  He will probably want to file a bug
>> report upstream with the boost developers.
>>
>> port info --maintainer boost
>>
>> CCing the boost maintainer now for his info.
> 
> Changing the subject.  Problem is when building with libstdc++.

Didn't find a related ticket in trac yet, so I'm posting this here:
Workaround applied successfully on OS X 10.7.5 (Xcode 4.6.3) to libvisio
and libcdr in local port repo [1]:

if {${configure.cxx_stdlib} eq "libstdc++"} {
configure.cppflags-append "-DBOOST_NO_CXX11_RVALUE_REFERENCES"
}

I do not know whether this is a "correct" solution - local tests however
confirmed so far that the results are as expected. Applied, successfully
compiled, installed and tested with libvisio (git master) as well as
libcdr (git master) on Lion: the command line tools of the libraries
produce expected results, and import in Inkscape using the shared
libaries also works (apart from a known regression in inkscape trunk
with CDR import not related to the recent boost upgrade).


Regards, V


[1] local portfiles (libvisio-devel, libcdr-devel):
http://bazaar.launchpad.net/~suv-lp/+junk/inkscape-osx-build-env/view/head:/ports/graphics/libvisio-devel/Portfile#L75
http://bazaar.launchpad.net/~suv-lp/+junk/inkscape-osx-build-env/view/head:/ports/graphics/libcdr-devel/Portfile#L71
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

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

[echothevoid]

Thank you su_v!
I tried to read the guide and the 'howto' but still confused how to apply
your solution.
https://guide.macports.org/
https://trac.macports.org/wiki/howto/Upgrade

Should I replace the original Portfile of libvisio-0.1 and libcdr-0.1 with
the ones from [1] and then do an upgrade? How to make that exactly?
Sorry for dumb questions. Your answer will definitely shed some light on
the subject.

Kind regards,
void

On 06.09.15 12:40, "su_v"  wrote:

>Didn't find a related ticket in trac yet, so I'm posting this here:
>Workaround applied successfully on OS X 10.7.5 (Xcode 4.6.3) to libvisio
>and libcdr in local port repo [1]:
>
>if {${configure.cxx_stdlib} eq "libstdc++"} {
>configure.cppflags-append "-DBOOST_NO_CXX11_RVALUE_REFERENCES"
>}
>
>I do not know whether this is a "correct" solution - local tests however
>confirmed so far that the results are as expected. Applied, successfully
>compiled, installed and tested with libvisio (git master) as well as
>libcdr (git master) on Lion: the command line tools of the libraries
>produce expected results, and import in Inkscape using the shared
>libaries also works (apart from a known regression in inkscape trunk
>with CDR import not related to the recent boost upgrade).
>
>
>Regards, V
>
>
>[1] local portfiles (libvisio-devel, libcdr-devel):
>http://bazaar.launchpad.net/~suv-lp/+junk/inkscape-osx-build-env/view/head
>:/ports/graphics/libvisio-devel/Portfile#L75
>http://bazaar.launchpad.net/~suv-lp/+junk/inkscape-osx-build-env/view/head
>:/ports/graphics/libcdr-devel/Portfile#L71


___
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-06 14:45 (+0200), echothevoid wrote:
> Thank you su_v!
> I tried to read the guide and the 'howto' but still confused how to apply
> your solution.
> https://guide.macports.org/
> https://trac.macports.org/wiki/howto/Upgrade
> 
> Should I replace the original Portfile of libvisio-0.1 and libcdr-0.1 with
> the ones from [1] and then do an upgrade? How to make that exactly?
> Sorry for dumb questions. Your answer will definitely shed some light on
> the subject.

Sorry, the comment was intented for the maintainers of the related ports
(boost, libvisio-0.1, libcdr-0.1) - I did not provide instructions for
users (probably should have posted it on the devel list instead of the
user list). IMHO this should be fixed in the ports, not by indiviual
MacPorts users still on Lion.


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

unbound did not start automatically after reboot

[FritzS - gmx]

David, Ryan,
who is the unbound specialist?

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


Fritz




___
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 3:40 AM, su_v wrote:
> On 2015-09-05 17:40 (+0200), David Evans wrote:
>> On 9/5/15 8:36 AM, David Evans wrote:
>>> On 9/5/15 7:41 AM, echothevoid wrote:
 Hello!

 I  got an error after running regular sudo port upgrade outdatedcommand.
 The log tells me that:
 :info:build /opt/local/include/boost/thread/detail/move.hpp:31:10: fatal 
 error: 'type_traits' file not found
 I have found a similar issue on: 
 http://stackoverflow.com/questions/14104298/clang-boostspirit-and-c11 but 
 do not know
 how to fix it in the macport's way.
 I am using 10.7.5 Lion, with Xcode version 4.6.3.
 The outcome of: 
 port installed | grep gcc
   gcc49 @4.9.3_0 (active)
   gcc_select @0.1_8 (active)
   libgcc @5.2.0_0 (active)

 Can you suggest a newbie like me what to do next? 

 Many thanks,
 void


>>>
>>> As indicated in your stackoverflow.com reference, this is not a problem 
>>> with libvisio per se but a problem with boost
>>> when using libstdc++ (default c++ lib on Mac OS X earlier than 10.9).  This 
>>> builds correctly on 10.9+ where libc++ is
>>> the default.
>>>
>>> Now that trac is back up, suggest you file a ticket against boost including 
>>> the information included in this message and
>>> attach your log file there as well.  Don't forget to CC the boost 
>>> maintainer.  He will probably want to file a bug
>>> report upstream with the boost developers.
>>>
>>> port info --maintainer boost
>>>
>>> CCing the boost maintainer now for his info.
>>
>> Changing the subject.  Problem is when building with libstdc++.
> 
> Didn't find a related ticket in trac yet, so I'm posting this here:
> Workaround applied successfully on OS X 10.7.5 (Xcode 4.6.3) to libvisio
> and libcdr in local port repo [1]:
> 
> if {${configure.cxx_stdlib} eq "libstdc++"} {
> configure.cppflags-append "-DBOOST_NO_CXX11_RVALUE_REFERENCES"
> }
> 
> I do not know whether this is a "correct" solution - local tests however
> confirmed so far that the results are as expected. Applied, successfully
> compiled, installed and tested with libvisio (git master) as well as
> libcdr (git master) on Lion: the command line tools of the libraries
> produce expected results, and import in Inkscape using the shared
> libaries also works (apart from a known regression in inkscape trunk
> with CDR import not related to the recent boost upgrade).
> 
> 
> Regards, V
> 
> 
> [1] local portfiles (libvisio-devel, libcdr-devel):
> http://bazaar.launchpad.net/~suv-lp/+junk/inkscape-osx-build-env/view/head:/ports/graphics/libvisio-devel/Portfile#L75
> http://bazaar.launchpad.net/~suv-lp/+junk/inkscape-osx-build-env/view/head:/ports/graphics/libcdr-devel/Portfile#L71

V --

Thanks for pointing out this fix but I'm a little bit confused.  You;re talking 
about libvisio and libcdr but your local
libvisio-devel and libcdr-devel ports appear to be correspond to the latest 
MacPorts ports libvisio-0.1 and libcdr-0.1
but built from git master.  Am I correct?

I don't have a platform to test on Lion at this point so I wonder if you could 
check and verify that this issue applies
to all four MacPorts ports libvisio, libvisio-0.1, libcdr, libcdr=0.1 and 
perhaps librevenge separately?

Which version(s) are you using to build Inkscape OSX releases?  I'm planning to 
drop the older non-librevenge versions
as soon as they are not needed by other dependents.  Is this a problem for you?

Thanks again for your 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)

[su_v]

On 2015-09-06 16:30 (+0200), David Evans wrote:
> On 9/6/15 3:40 AM, su_v wrote:
>> On 2015-09-05 17:40 (+0200), David Evans wrote:
>>> On 9/5/15 8:36 AM, David Evans wrote:
 On 9/5/15 7:41 AM, echothevoid wrote:
> Hello!
>
> I  got an error after running regular sudo port upgrade outdatedcommand.
> The log tells me that:
> :info:build /opt/local/include/boost/thread/detail/move.hpp:31:10: fatal 
> error: 'type_traits' file not found
> I have found a similar issue on: 
> http://stackoverflow.com/questions/14104298/clang-boostspirit-and-c11 but 
> do not know
> how to fix it in the macport's way.
> I am using 10.7.5 Lion, with Xcode version 4.6.3.
> The outcome of: 
> port installed | grep gcc
>   gcc49 @4.9.3_0 (active)
>   gcc_select @0.1_8 (active)
>   libgcc @5.2.0_0 (active)
>
> Can you suggest a newbie like me what to do next? 
>
> Many thanks,
> void
>
>

 As indicated in your stackoverflow.com reference, this is not a problem 
 with libvisio per se but a problem with boost
 when using libstdc++ (default c++ lib on Mac OS X earlier than 10.9).  
 This builds correctly on 10.9+ where libc++ is
 the default.

 Now that trac is back up, suggest you file a ticket against boost 
 including the information included in this message and
 attach your log file there as well.  Don't forget to CC the boost 
 maintainer.  He will probably want to file a bug
 report upstream with the boost developers.

 port info --maintainer boost

 CCing the boost maintainer now for his info.
>>>
>>> Changing the subject.  Problem is when building with libstdc++.
>>
>> Didn't find a related ticket in trac yet, so I'm posting this here:
>> Workaround applied successfully on OS X 10.7.5 (Xcode 4.6.3) to libvisio
>> and libcdr in local port repo [1]:
>>
>> if {${configure.cxx_stdlib} eq "libstdc++"} {
>> configure.cppflags-append "-DBOOST_NO_CXX11_RVALUE_REFERENCES"
>> }
>>
>> I do not know whether this is a "correct" solution - local tests however
>> confirmed so far that the results are as expected. Applied, successfully
>> compiled, installed and tested with libvisio (git master) as well as
>> libcdr (git master) on Lion: the command line tools of the libraries
>> produce expected results, and import in Inkscape using the shared
>> libaries also works (apart from a known regression in inkscape trunk
>> with CDR import not related to the recent boost upgrade).
>>
>>
>> Regards, V
>>
>>
>> [1] local portfiles (libvisio-devel, libcdr-devel):
>> http://bazaar.launchpad.net/~suv-lp/+junk/inkscape-osx-build-env/view/head:/ports/graphics/libvisio-devel/Portfile#L75
>> http://bazaar.launchpad.net/~suv-lp/+junk/inkscape-osx-build-env/view/head:/ports/graphics/libcdr-devel/Portfile#L71
> 

> Thanks for pointing out this fix but I'm a little bit confused. 
> You;re talking about libvisio and libcdr but your local 
> libvisio-devel and libcdr-devel ports appear to be correspond to the 
> latest MacPorts ports libvisio-0.1 and libcdr-0.1 but built from git 
> master. Am I correct?

Yes - the naming is due to legacy reasons: I started testing
librevenge-based versions of libcdr, libvisio and libwpg from git master
for inkscape before MacPorts had new ports for them, thus the local
devel ports had been based on the names used in the original MacPorts
portfiles. Later on, I did not bother to rename the devel ports (since
the local port repository is mostly used for testing, and not shared
elsewhere) - only the conflicts line was updated.

> I don't have a platform to test on Lion at this point so I wonder if
> you could check and verify that this issue applies to all four
> MacPorts ports libvisio, libvisio-0.1, libcdr, libcdr=0.1 and perhaps
> librevenge separately?

I can try to verify that - I do use MacPorts trunk though, installed
(without root privileges) into custom prefixes only, which might make
the results less conclusive for a default MacPorts installation or the
buildbots (if the one for Lion ever comes back).

> Which version(s) are you using to build Inkscape OSX releases? I'm
> planning to drop the older non-librevenge versions as soon as they
> are not needed by other dependents. Is this a problem for you?

The current stable Inkscape package for OS X (64bit only) includes the
librevenge-based versions, the same is planned for future releases.

Inkscape's autotools-based build system has checks for both versions: it
prefers the newer librevenge-based one and falls back to the older one:

http://bazaar.launchpad.net/~inkscape.dev/inkscape/RELEASE_0_91_BRANCH/view/head:/configure.ac#L567
http://bazaar.launchpad.net/~inkscape.dev/inkscape/RELEASE_0_91_BRANCH/view/head:/configure.ac#L607

If neither is found, the feature is disabled altogether.

Similar checks are in place for the (future) Cmake build system in
Inkscape trunk, but they have not been checked thoroughly yet

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

[su_v]

On 2015-09-06 16:30 (+0200), David Evans wrote:
> On 9/6/15 3:40 AM, su_v wrote:
>> Didn't find a related ticket in trac yet, so I'm posting this here:
>> Workaround applied successfully on OS X 10.7.5 (Xcode 4.6.3) to libvisio
>> and libcdr in local port repo [1]:
>>
>> if {${configure.cxx_stdlib} eq "libstdc++"} {
>> configure.cppflags-append "-DBOOST_NO_CXX11_RVALUE_REFERENCES"
>> }
>>
>> I do not know whether this is a "correct" solution - local tests however
>> confirmed so far that the results are as expected. (...)

> I don't have a platform to test on Lion at this point so I wonder if
> you could check and verify that this issue applies to all four
> MacPorts ports libvisio, libvisio-0.1, libcdr, libcdr=0.1 and perhaps
> librevenge separately?

These 2 built without any changes on Lion:
- librevenge
- libvisio

These 3 only built after applying above change:
- libcdr
- libcdr-0.1
- libvisio-0.1

All ports have been tested after successful installation with their
command line tool to convert CDR, VSD to XHTML, and viewing the result
in Firefox.


Regards, V
___
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 9:24 AM, su_v wrote:
> On 2015-09-06 16:30 (+0200), David Evans wrote:
>> On 9/6/15 3:40 AM, su_v wrote:
>>> Didn't find a related ticket in trac yet, so I'm posting this here:
>>> Workaround applied successfully on OS X 10.7.5 (Xcode 4.6.3) to libvisio
>>> and libcdr in local port repo [1]:
>>>
>>> if {${configure.cxx_stdlib} eq "libstdc++"} {
>>> configure.cppflags-append "-DBOOST_NO_CXX11_RVALUE_REFERENCES"
>>> }
>>>
>>> I do not know whether this is a "correct" solution - local tests however
>>> confirmed so far that the results are as expected. (...)
> 
>> I don't have a platform to test on Lion at this point so I wonder if
>> you could check and verify that this issue applies to all four
>> MacPorts ports libvisio, libvisio-0.1, libcdr, libcdr=0.1 and perhaps
>> librevenge separately?
> 
> These 2 built without any changes on Lion:
> - librevenge
> - libvisio
> 
> These 3 only built after applying above change:
> - libcdr
> - libcdr-0.1
> - libvisio-0.1
> 
> All ports have been tested after successful installation with their
> command line tool to convert CDR, VSD to XHTML, and viewing the result
> in Firefox.
> 
> 
> Regards, V
> 

Thanks, V.

After looking at the Boost code/documentation for a while this morning, I'm 
coming around to the theory that while using
your fix may work on a port by port basis, it's fixing the symptom rather than 
the root cause of the problem.

Boost uses BOOST_NO_CXX11_RVALUE_REFERENCES internally to switch code when the 
compiler in use doesn't support c++11
(c++0x) rvalue references.  When this macro is defined, boost disables code 
that uses rvalue references and either
emulates this functionality using pre-c++11 syntax or just disables the feature 
altogether.

Supposedly boost tests for compiler support during configuration and sets this 
macro if necessary in the boost headers.
Boost discourages the use of this and related macros in user code and reserves 
the right to change them without notice.

So the question is, why isn't this set by boost when compiling on Mac OS X 
configurations that use clang with
-stdlib=libstdc++ (Lion for instance).  Seems like there is possibly a 
mis-configuration in this case which could
have a wider effect more than just the ports referenced here.

This is just a working theory at this point, but if this is the case than it 
would probably be better to fix things
in boost itself rather than over-ride its configuration in each effected port.

Ryan, do you have any input on this?  I'm interested in the user.hpp that 
${worksrcpath}/libs/config/configure generates
in this case. Does it define BOOST_NO_CXX11_RVALUE_REFERENCES? If so, perhaps 
the default clang configuration isn't
appropriate and a customized user.hpp needs to be employed?

http://www.boost.org/doc/libs/1_59_0/libs/config/doc/html/index.html#boost_config.configuring_boost_for_your_platform

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)

[Brandon Allbery]

On Sun, Sep 6, 2015 at 1:36 PM, David Evans  wrote:

> So the question is, why isn't this set by boost when compiling on Mac OS X
> configurations that use clang with
> -stdlib=libstdc++ (Lion for instance).  Seems like there is possibly a
> mis-configuration in this case which could
> have a wider effect more than just the ports referenced here.
>

I think the problem is that boost will generally be installed with clang /
libc++ support but is still visible to g++ even if that is using libstdc++?

-- 
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

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

[Lars Sonchocky-Helldorf]

Hi 'porters

I am trying to write a portfile for torch7 (see 
http://torch.ch/docs/getting-started.html ). Since I am not very experienced 
with that task I might ask some possibly stupid questions for a while …

At the moment I am trying to figure out the right depends_lib. My guideline for 
this is https://raw.githubusercontent.com/torch/ezinstall/master/install-deps 
which is normally used to install torch. This script hat the shortcoming that 
it unasked for installs brew:

-
if [[ `uname` == 'Darwin' ]]; then
# GCC?
if [[ `which gcc` == '' ]]; then
echo "MacOS doesn't come with GCC: please install XCode and the command 
line tools."
exit 1
fi

# Install Homebrew (pkg manager):
if [[ `which brew` == '' ]]; then
ruby -e "$(curl -fsSL 
https://raw.githubusercontent.com/Homebrew/install/master/install)"
fi

# Install dependencies:
brew update
brew install git readline cmake wget qt
brew install libjpeg imagemagick zeromq graphicsmagick openssl
brew link readline --force
brew install caskroom/cask/brew-cask
brew cask install xquartz
brew remove gnuplot
brew install gnuplot --with-wxmac --with-cairo --with-pdflib-lite 
--with-x11 --without-lua
-

Since I am a macports fellow I don't like the fact of having brew on my 
maschine. Despite the little funny beermug …


So I am trying to determine the dependencies from this. At the moment it looks 
like this:

depends_lib port:git \
port:readline \
port:cmake \
port:wget \
port:qt4-mac \
port:jpeg \
port:ImageMagick \
port:zmq \
port:GraphicsMagick
port:openssl \
port:quartz-wm \
port:gnuplot

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? 


I searched https://guide.macports.org/chunked/development.variants.html and 
https://guide.macports.org/chunked/development.creating-portfile.html but found 
no answer on my question there.


regards,

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

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

[Ryan Schmidt]

On Sep 6, 2015, at 13:09, Lars Sonchocky-Helldorf wrote:
> 
> So how would I specify the variants I want in depends_lib? 

MacPorts itself does not have that capability. Please verify first whether it 
is really necessary to use other variants. If so, use the active_variants 1.1 
portgroup. 
___
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 10:42 AM, Brandon Allbery wrote:
> On Sun, Sep 6, 2015 at 1:36 PM, David Evans  > wrote:
> 
> So the question is, why isn't this set by boost when compiling on Mac OS 
> X configurations that use clang with
> -stdlib=libstdc++ (Lion for instance).  Seems like there is possibly a 
> mis-configuration in this case which could
> have a wider effect more than just the ports referenced here.
> 
> 
> I think the problem is that boost will generally be installed with clang / 
> libc++ support but is still visible to g++
> even if that is using libstdc++?
> 

Not sure I completely understand.

When compiling C++ programs the default compilers are to my understanding

clang++, -stdlib=libc++ for 10.9 +
clang++, -stdlib=libstdc++  for 10.7, 10.8

On these platforms, again to my understanding, g++ is an alias for clang++
and shouldn't be used in any case per Ryan's 
https://trac.macports.org/wiki/UsingTheRightCompiler mandate.

It may be that boost is configuring for libc++ on 10.7, 10.8 instead of 
libstdc++ but, if that is the case, that is not
correct and would lead to the type of failure reported in this thread.

Also note that the issue here is the configuration of the boost headers not the 
boost libraries themselves.

For now, I'm not addressing the issue of earlier OS X versions, or MacPorts gcc 
versions which could be a different can
of worms altogether.

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)

[Ryan Schmidt]

On Sep 6, 2015, at 13:43, David Evans wrote:
> 
> It may be that boost is configuring for libc++ on 10.7, 10.8 instead of 
> libstdc++ but, if that is the case, that is not
> correct and would lead to the type of failure reported in this thread.

I thought it did, and that you fixed it in:

https://trac.macports.org/changeset/120994

But maybe additional fixes are needed in this new version of boost. 

Did you ever report that problem to the developers of boost? We don't want to 
forever maintain patches for this problem in MacPorts; the fixes should be 
committed to the boost repository. ___
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 12:33 PM, Ryan Schmidt wrote:
> On Sep 6, 2015, at 13:43, David Evans wrote:
> 
>> It may be that boost is configuring for libc++ on 10.7, 10.8 instead of 
>> libstdc++ but, if that is the case, that is not
>> correct and would lead to the type of failure reported in this thread.
> 
> I thought it did, and that you fixed it in:
> 
> https://trac.macports.org/changeset/120994
> 
> But maybe additional fixes are needed in this new version of boost. 
> 
> Did you ever report that problem to the developers of boost? We don't want to 
> forever maintain patches for this problem
> in MacPorts; the fixes should be committed to the boost repository. 


Wow!!  I completely forgot about doing that!!

In any case, this patch sets BOOST_APPLE_CLANG_NO_LIBCXX which apparently 
doesn't translate into
BOOST_NO_CXX11_RVALUE_REFERENCES and there's a whole lot of other 
BOOST_NO_CXX11_* macros as well.
In the current version, BOOST_APPLE_CLANG_NO_LIBCXX is used only in 
boost/multi_index/detail/vartempl_support.hpp,
which I think was the previous problem.

After looking at the Boost.Config documentation, I'm wondering now if using a 
custom user.hpp might not be a better
approach than patching clang.hpp.  Running their configure util 
(libs/config/configure) should run all the necessary
tests and generate a recommended user.hpp (in the cwd).  Unfortunately, I don't 
have a Lion system handy to see the
results myself.  Could you do this and publish the results?  I'm curious to see 
if BOOST_NO_CXX11_RVALUE_REFERENCES is
included.  Or whatever else is included for that matter.

I haven't mentioned this upstream as yet because I'm not really sure whether 
this should be considered a bug in the
Boost configuration system or just a failure on our part to add an appropriate 
user.hpp.  If we could come up with the
correct configuration we could ask that they include that upstream somewhere 
appropriate.

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)

[su_v]

On 2015-09-06 22:19 (+0200), David Evans wrote:

> In any case, this patch sets BOOST_APPLE_CLANG_NO_LIBCXX which
> apparently doesn't translate into BOOST_NO_CXX11_RVALUE_REFERENCES
> and there's a whole lot of other BOOST_NO_CXX11_* macros as well. In
> the current version, BOOST_APPLE_CLANG_NO_LIBCXX is used only in
> boost/multi_index/detail/vartempl_support.hpp, which I think was the
> previous problem.
> 
> After looking at the Boost.Config documentation, I'm wondering now if
> using a custom user.hpp might not be a better approach than patching
> clang.hpp.  Running their configure util (libs/config/configure)
> should run all the necessary tests and generate a recommended
> user.hpp (in the cwd).  Unfortunately, I don't have a Lion system
> handy to see the results myself.  Could you do this and publish the
> results?  I'm curious to see if BOOST_NO_CXX11_RVALUE_REFERENCES is 
> included.  Or whatever else is included for that matter.

OS X 10.7.5 / Xcode 4.6.3 compiler versions:

$ g++ --version
i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) 
(LLVM build 2336.11.00)
Copyright (C) 2007 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.

$ c++ --version
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix
$ clang++ --version
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix
$

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++).

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.


Regards, V
//  (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 Sun Sep  6 22:34:54 CEST 2015
//  With the following options:
//CXX  = g++
//CXXFLAGS = -I./../.. -I./../../libs/config/test -g -O2 -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_UNISTD_H
#define BOOST_HAS_STDINT_H
#define BOOST_HAS_SIGACTION
#define BOOST_HAS_SCHED_YIELD
#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_GETTIMEOFDAY
#define BOOST_HAS_EXPM1
#define BOOST_HAS_DIRENT_H
#define BOOST_NO_CXX11_VARIADIC_TEMPLATES
#define BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX
#define BOOST_NO_CXX11_UNICODE_LITERALS
#define BOOST_NO_CXX11_TEMPLATE_ALIASES
#define BOOST_NO_CXX11_LOCAL_CLASS_TEMPLATE_PARAMETERS
#define BOOST_NO_CXX11_STATIC_ASSERT
#define BOOST_NO_SFINAE_EXPR
#define BOOST_NO_CXX11_SCOPED_ENUMS
#define BOOST_NO_CXX11_RVALUE_REFERENCES
#define BOOST_NO_CXX11_RAW_LITERALS
#define BOOST_NO_CXX11_RANGE_BASED_FOR
#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_FUNCTION_TEMPLATE_DEFAULT_ARGS
#define BOOST_NO_CXX11_FIXED_LENGTH_VARIADIC_TEMPLATE_EXPANSION_PACKS
#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_CXX14_BINARY_LITERALS
#define BOOST_NO_CXX11_USER_DEFINED_LITERALS
#define BOOST

Writing portfiles: How to download a master.zip and not a master.zip.tar.gz

[Lars Sonchocky-Helldorf]

Hi,

I have the following entries in a local portfile:
-
homepagehttp://torch.ch/
master_siteshttps://github.com/torch/torch7/archive/
distnamemaster.zip
-

when running sudo port -v install torch I get attempts to fetch the source zip 
like this:

--->  Attempting to fetch master.zip.tar.gz from 
https://github.com/torch/torch7/archive/

which off course doesn't exist.


So how would I specify not to append .tar.gz?


regards,

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

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

[Lars Sonchocky-Helldorf]

Am 06.09.2015 um 20:17 schrieb Ryan Schmidt:

> On Sep 6, 2015, at 13:09, Lars Sonchocky-Helldorf wrote:
>> 
>> So how would I specify the variants I want in depends_lib? 
> 
> MacPorts itself does not have that capability. Please verify first whether it 
> is really necessary to use other variants. If so, use the active_variants 1.1 
> portgroup.

Thanks, I'll try using the default variants. I'll see if it works.


regards,

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

Re: Writing portfiles: How to download a master.zip and not a master.zip.tar.gz

[Ryan Schmidt]

On Sep 6, 2015, at 16:33, Lars Sonchocky-Helldorf wrote:
> 
> I have the following entries in a local portfile:
> -
> homepagehttp://torch.ch/
> master_siteshttps://github.com/torch/torch7/archive/
> distnamemaster.zip
> -
> 
> when running sudo port -v install torch I get attempts to fetch the source 
> zip like this:
> 
> --->  Attempting to fetch master.zip.tar.gz from 
> https://github.com/torch/torch7/archive/
> 
> which off course doesn't exist.
> 
> 
> So how would I specify not to append .tar.gz?

use_zip yes

However that is not the correct solution in this case. Since this software is 
hosted on the github service, it should use the github 1.0 portgroup. Read the 
comments in the portgroup for instructions on how to use it.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Writing portfiles: How to download a master.zip and not a master.zip.tar.gz

[Clemens Lang]

Hi,

- On 6 Sep, 2015, at 23:33, Lars Sonchocky-Helldorf 
lars.sonchocky-helld...@hamburg.de wrote:

> I have the following entries in a local portfile:
> -
> homepagehttp://torch.ch/
> master_siteshttps://github.com/torch/torch7/archive/
> distnamemaster.zip
> -

If you're using software from github, you should use the github PortGroup:

PortGroupgithub 1.0
# Using a commit hash because the repo doesn't have tags
# You should ask upstream to tag releases
github.setup torch torch7 9e1b9dd15bbad3ee5cbd6440322ac3c3a368d631
# version defaults to the third argument of github.setup, but that's not
# monotonic, use a date instead.
version  2015-09-06

That should automatically set up master_sites and distname for you.


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

Re: Writing portfiles: How to download a master.zip and not a master.zip.tar.gz

[Lars Sonchocky-Helldorf]

Am 06.09.2015 um 23:48 schrieb Clemens Lang:

> Hi,
> 
> - On 6 Sep, 2015, at 23:33, Lars Sonchocky-Helldorf 
> lars.sonchocky-helld...@hamburg.de wrote:
> 
>> I have the following entries in a local portfile:
>> -
>> homepagehttp://torch.ch/
>> master_siteshttps://github.com/torch/torch7/archive/
>> distnamemaster.zip
>> -
> 
> If you're using software from github, you should use the github PortGroup:
> 
> PortGroupgithub 1.0
> # Using a commit hash because the repo doesn't have tags
> # You should ask upstream to tag releases
> github.setup torch torch7 9e1b9dd15bbad3ee5cbd6440322ac3c3a368d631
> # version defaults to the third argument of github.setup, but that's not
> # monotonic, use a date instead.
> version  2015-09-06
> 
> That should automatically set up master_sites and distname for you.
> 
> 
> -- 
> Clemens Lang


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
Command failed:  cd 
"/opt/local/var/macports/build/_Volumes_Data_Projects_MacPorts_ports_science_torch/torch/work/torch7-9e1b9dd15bbad3ee5cbd6440322ac3c3a368d631"
 && ./configure --prefix=/opt/local 
Exit code: 127
Error: org.macports.configure for port torch returned: configure failure: 
command execution failed



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 …

https://github.com/torch/ezinstall

or a supposedly newer way like this:

https://github.com/torch/distro/blob/master/install.sh

with the whole build system as an separate project: 
https://github.com/torch/distro



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?


regards,

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

How to reliable detect a MacPorts-ported compiler?

[Jeffrey Walton]

Hi Everyone,

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?

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

Re: Writing portfiles: How to download a master.zip and not a master.zip.tar.gz

[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.


> 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. 


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