Re: port listed to be upgraded but not upgraded

[Joshua Root]

On 2018-9-10 14:23 , Ryan Schmidt wrote:
> 
> 
> On Sep 9, 2018, at 23:21, Joshua Root wrote:
> 
>> On 2018-9-10 13:23 , Ryan Schmidt wrote:
>>> It is fine for ports to offer different versions to different platforms. Up 
>>> to now, a "platform" was the combination of an operating system name, major 
>>> version number, and architecture (PowerPC or Intel). It has been proposed 
>>> that the C++ standard library should be added to that definition. Code 
>>> implementing that has already been added to portindex. We have not yet 
>>> deployed changes to the server to generate separate indexes per C++ 
>>> standard library, and we have not modified MacPorts base to look for a 
>>> different index on the server depending on the C++ standard library. We 
>>> should make both of those changes.
>>
>> Oh sure, you can multiply the number of portindexes easily enough to
>> reflect one more configuration choice. It's not a sustainable design
>> direction though.
> 
> We're only talking about adding a libc++ index for 10.4, 10.5, 10.6, 10.7, 
> 10.8. We're not talking about adding further indexes for other reasons.

I'm not only talking about this one problem, I'm talking about the
bigger picture. Anyway this has gone off-topic for -users.

- Josh

Re: TeXLive distribution and macports

[Ryan Schmidt]

On Sep 9, 2018, at 10:23, Christopher Jones wrote:

> Note that MacPorts has a policy of not using external libraries, as far as 
> possible (apart from obvious system ones) so if you aim is to have a port 
> that basically allows something externally externally to pretend to be 
> something MacPorts provides, then no this is strictly not allowed. See for 
> instance
> 
> https://trac.macports.org/wiki/FAQ#ownlibs
> 
> its the same deal as why we do not support using anything installed outside 
> of MacPorts, from /usr/local

TeXLive is an exception to this rule. Users who wish to use the MacTeX TeXLive 
distribution instead of the one in MacPorts should edit 
/opt/local/etc/macports/macports.conf and add /Library/TeX/texbin to binpath.

Ports that are ok with using MacTeX instead will have declared their 
dependencies in such a way (using the bin: specification instead of the port: 
specification) that MacTeX versions will satisfy them.

If you have MacPorts set up in this way, and you install a port, and it still 
pulls in MacPorts texlive ports, then either those ports' dependencies need to 
be fixed to use bin: instead of port:, or there is a specific reason why those 
ports can't do it that way.

Re: port listed to be upgraded but not upgraded

[Ryan Schmidt]

On Sep 9, 2018, at 23:21, Joshua Root wrote:

> On 2018-9-10 13:23 , Ryan Schmidt wrote:
>> It is fine for ports to offer different versions to different platforms. Up 
>> to now, a "platform" was the combination of an operating system name, major 
>> version number, and architecture (PowerPC or Intel). It has been proposed 
>> that the C++ standard library should be added to that definition. Code 
>> implementing that has already been added to portindex. We have not yet 
>> deployed changes to the server to generate separate indexes per C++ standard 
>> library, and we have not modified MacPorts base to look for a different 
>> index on the server depending on the C++ standard library. We should make 
>> both of those changes.
> 
> Oh sure, you can multiply the number of portindexes easily enough to
> reflect one more configuration choice. It's not a sustainable design
> direction though.

We're only talking about adding a libc++ index for 10.4, 10.5, 10.6, 10.7, 
10.8. We're not talking about adding further indexes for other reasons.

Re: port listed to be upgraded but not upgraded

[Joshua Root]

On 2018-9-10 13:23 , Ryan Schmidt wrote:
> It is fine for ports to offer different versions to different platforms. Up 
> to now, a "platform" was the combination of an operating system name, major 
> version number, and architecture (PowerPC or Intel). It has been proposed 
> that the C++ standard library should be added to that definition. Code 
> implementing that has already been added to portindex. We have not yet 
> deployed changes to the server to generate separate indexes per C++ standard 
> library, and we have not modified MacPorts base to look for a different index 
> on the server depending on the C++ standard library. We should make both of 
> those changes.

Oh sure, you can multiply the number of portindexes easily enough to
reflect one more configuration choice. It's not a sustainable design
direction though.

Re: compilers on Lion

[Ryan Schmidt]

On Sep 8, 2018, at 16:31, Werner LEMBERG wrote:

>>> * Where can I get a concise and up-to-date description of
>>> portfiles?  `portfiles.7' seems to be heavily out of date...
>> 
>> What would you like to know?
> 
> A list of all available variables/keywords, with a description.

Yup, that's supposed to be what's in the guide and the manpage.

There are also many portgroups (similar concept to include files in C), which, 
when included into a port, may add new variables or keywords of their own. 
About half of the portgroups are documented in the guide.

Re: port listed to be upgraded but not upgraded

[Ryan Schmidt]

On Sep 8, 2018, at 20:00, Joshua Root wrote:

> Riccardo Mottola wrote:
>> I finished "port upgrade outdated" successfully (on Lion) and in fact 
>> I can re-run it and no action happens.
>> 
>> Kaiserin:~ multix$ sudo port -v upgrade outdated
>> Password:
>> --->  Scanning binaries for linking errors
>> --->  No broken files found.
>> --->  No broken ports found.
>> 
>> 
>> however, if I list outdated, I see:
>> Kaiserin:~ multix$ port list outdated
>> Warning: The 'list' action only shows the currently available version 
>> of each port. To see installed versions, use the 'installed' action.
>> gnome-online-accounts  @3.28.0 
>> gnome/gnome-online-accounts
>> 
>> Kaiserin:~ multix$ port installed outdated
>> The following ports are currently installed:
>>   gnome-online-accounts @3.8.5_2 (active)
>> 
>> now what is right?
> 
> Both, sort of. This port changes its version depending on the value of
> cxx_stdlib. So the version in the index which was generated on the
> server is different to the version set by the Portfile on your system.
> 
> This has been reported as a base bug, but TBH I think the solution is
> not to set ports' versions dynamically. The way ld64 handles different
> versions on different platforms works much better.

It is fine for ports to offer different versions to different platforms. Up to 
now, a "platform" was the combination of an operating system name, major 
version number, and architecture (PowerPC or Intel). It has been proposed that 
the C++ standard library should be added to that definition. Code implementing 
that has already been added to portindex. We have not yet deployed changes to 
the server to generate separate indexes per C++ standard library, and we have 
not modified MacPorts base to look for a different index on the server 
depending on the C++ standard library. We should make both of those changes.

Re: Configuring MacPorts to work via a proxy

[Ryan Schmidt]

On Sep 9, 2018, at 13:49, Andrew Luke Nesbit wrote:

> I am preparing to install and configure MacPorts on a new machine that
> has been supplied by my employer.  It will be used in a corporate
> network with strict access controls between the intranet and the Internet.
> 
> The only option is to configure MacPorts to use HTTPS through the
> official proxy.  The proxy mediates TLS connections using a MITM
> approach.  MacPorts and its subtools need to be able to find the root
> certificate, which is officially available for installation where required.
> 
> I checked the macports.org website today but I couldn't find
> instructions on how to do this.  Also, since I last configured MacPorts,
> it has moved from Subversion to GitHub.
> 
> Does anybody have any information that could help me?
> 
> I found a placemarker for an unwritten HOWTO at
> https://trac.macports.org/wiki/howto .  I would be happy to help write
> this document, or at least to get it started.
> 
> Any help would be appreciated.  Thank you!!
> 
> Andrew
> 
> P.S. Background context and past experience is as follows.
> 
> On my previous machine, I was able to configure MacPorts so that `port
> sync` worked well over SVN+HTTPS and most port installations worked
> properly.  I was never able to get `port selfupdate` working because
> rsync is blocked.

"port selfupdate" still can only use rsync for updating MacPorts base. If rsync 
is blocked on your network, you will not be able to use selfupdate, and will 
need to update MacPorts manually when a new version of MacPorts is released, 
such as by downloading and running the installer from our web site.

"port sync" has many communication methods available; hopefully one of them 
works for you.


> This was a couple of years ago.  Configuration was a complex and
> time-consuming job due to the constrained environment and lack of
> documentation.  I eventually got a mostly-working setup by aggregating
> information from blog posts, Subversion documentation, other
> documentation, and Stack Exchange.

I am not familiar with proxies that perform man-in-the-middle attacks on ssl 
connections. But if you found a way to make it work with svn+https before, 
hopefully the same methods would work with git+https now. GitHub even offers 
svn access to git repositories, so if for some reason your method only works 
with svn, you can probably still use that now that we're on GitHub.

Re: rdepof:wine-devel +x11 +universal fails on installing xattr

[Gijs Vermeulen]

Hi,

Thank you both for the answers.
In the end I ended up using Ryan's command that excludes xattr and that
worked perfectly.

Thanks again!

Regards,
Gijs

Op za 8 sep. 2018 om 02:54 schreef Ken Cunningham <
ken.cunningham.web...@gmail.com>:

>
> On 2018-09-07, at 5:33 PM, Ryan Schmidt wrote:
>
>
> > I understand that you are saying that, but I'm not convinced that's
> desirable behavior.
> >
> > What criteria do you propose to use to exclude the dependency? The
> dependency is written "bin:xattr:xattr". Do you propose to exclude all bin
> (and lib?) dependencies? Or do you only propose to exclude bin (and lib?)
> dependencies that are already satisfied by the specified program (or
> library?)? And if so, do you exclude the dependency regardless of how the
> dependency was satisfied, or only if the dependency was satisfied by a file
> outside of MacPorts? And if the latter, where in MacPorts base should that
> determination be made? (As far as I know, MacPorts base doesn't currently
> care where the file that satisfies a bin (or lib) dependency is located.)
> >
>
> Whew -- might take me a while to digest all that.
>
> In essence, I think most users would expect that:
>
> port echo rdepof:wine-devel +x11 +universal
>
> would lead to more or less the same dependencies being listed as would be
> installed if you instead did:
>
> port install wine-devel +x11 +universal
>
> But if that is not desirable behaviour for some reason, OK. I actually
> don't use rdepof.
>
> Best,
>
> Ken

Configuring MacPorts to work via a proxy

[Andrew Luke Nesbit]

Dear all,

I am preparing to install and configure MacPorts on a new machine that
has been supplied by my employer.  It will be used in a corporate
network with strict access controls between the intranet and the Internet.

The only option is to configure MacPorts to use HTTPS through the
official proxy.  The proxy mediates TLS connections using a MITM
approach.  MacPorts and its subtools need to be able to find the root
certificate, which is officially available for installation where required.

I checked the macports.org website today but I couldn't find
instructions on how to do this.  Also, since I last configured MacPorts,
it has moved from Subversion to GitHub.

Does anybody have any information that could help me?

I found a placemarker for an unwritten HOWTO at
https://trac.macports.org/wiki/howto .  I would be happy to help write
this document, or at least to get it started.

Any help would be appreciated.  Thank you!!

Andrew

P.S. Background context and past experience is as follows.

On my previous machine, I was able to configure MacPorts so that `port
sync` worked well over SVN+HTTPS and most port installations worked
properly.  I was never able to get `port selfupdate` working because
rsync is blocked.

This was a couple of years ago.  Configuration was a complex and
time-consuming job due to the constrained environment and lack of
documentation.  I eventually got a mostly-working setup by aggregating
information from blog posts, Subversion documentation, other
documentation, and Stack Exchange.

-- 
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

Re: Requesting new variant for octave and arpack

[Christopher Jones]

Hi,

For feature requests please either file a feature request in MacPorts Trac, or 
even better implement the change yourself and submit a Pull Request to GiHub 
with the changes. mails to this list are far from guaranteed to have any impact 
in these cases.

Chris

> On 9 Sep 2018, at 5:49 pm, Manav Bhatia  wrote:
> 
> Greetings! 
> 
>Please see the discussion here: 
> https://github.com/opencollab/arpack-ng/issues/149#issuecomment-419715128 
> 
> http://octave.1599824.n4.nabble.com/Issues-with-eigs-td4689314.html#a4689334 
> 
> 
>We have identified a bug in system lapack provided by the accelerate 
> framework that prevents proper functioning of arpack. 
> 
>I am writing to request the addition of a new variant in installation of 
> arpack and octave to use lapack installed from macports. Something like: 
> 
> $ port install octave +lapack 
> 
>Currently the only two variants for lapack are accelerate and atlas. 
> 
> Regards,
> Manav
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Requesting new variant for octave and arpack

[Manav Bhatia]

Greetings! 

   Please see the discussion here: 
https://github.com/opencollab/arpack-ng/issues/149#issuecomment-419715128 

http://octave.1599824.n4.nabble.com/Issues-with-eigs-td4689314.html#a4689334 


   We have identified a bug in system lapack provided by the accelerate 
framework that prevents proper functioning of arpack. 

   I am writing to request the addition of a new variant in installation of 
arpack and octave to use lapack installed from macports. Something like: 

$ port install octave +lapack 

   Currently the only two variants for lapack are accelerate and atlas. 

Regards,
Manav

Re: TeXLive distribution and macports

[Mark Anderson]

Yeah, this is specifically prohibited by our guidelines and the overall
workings of the program. There is a TeXlive minimum install, and if you
could make one smaller that works with lily pond I’m sure we’d consider it.
But this is basically a non-starter with MacPorts.

—Mark

On Sun, Sep 9, 2018 at 12:31 PM Werner LEMBERG  wrote:

>
> >> Ah, I assumed too much knowledge, sorry.  TeXLive itself comes with
> >> binaries for MacOS (both legacy platforms, i.e., 10.6-10.10, and
> >> recent versions, i.e., 10.10-10.13).  By simply prepending the path
> >> to those binaries to PATH, the `texlive-*' ports from MacPorts
> >> would be completely hidden and thus useless, more or less: TeXLive
> >> wouldn't use any data, binaries, or libraries from MacPorts.
> >>
> >> However, to build various packages like `lilypond', `port' needs to
> >> believe that some `texlive-*' ports are installed.  What certainly
> >> works is to create a small port repository similar to René Bertin's
> >> `macstrop' repository to override MacPorts with dummy ports.  My
> >> question was whether macports itself provides a simpler solution
> >> similar to `texlive-dummy-opensuse', where I have to install just a
> >> single .rpm file...  I guess the answer is no.
> >
> > Its quite simple.  The macports build of lilypond should be
> > configured to use the MacPorts provided builds of TexLive.
>
> I was still unclear, sorry.  To continue with lilypond as an example:
> This program uses only TeXLive *programs* and data, but no libraries.
> In general, this is true for all other programs within MacPorts that
> depend on texlive ports.  It is thus irrelevant whether MacPorts
> itself contains the necessary data and binaries, or whether they are
> provided externally (in this case, by the native TeXLive
> distribution).
>
> > If these ports do not provide what is needed, then just provide an
> > additional port for what is missing.
>
> There are no misses.  My `problem' is that the `texlive-*' ports
> within MacPorts use a few GByte, doubling everything native TeXLive
> already provides!  I want to use native TeXLive directly so that I can
> actually call `tlmgr' (or the SVN repository) to update the TeX stuff.
> For this reason I want to have some dummy portfiles to make `port'
> believe that the `texlive-*' ports are present.  This will take a few
> kBytes only...
>
>
> Werner
>
-- 
Sent from Gmail Mobile on iPhone

Re: TeXLive distribution and macports

[Werner LEMBERG]

>> Ah, I assumed too much knowledge, sorry.  TeXLive itself comes with
>> binaries for MacOS (both legacy platforms, i.e., 10.6-10.10, and
>> recent versions, i.e., 10.10-10.13).  By simply prepending the path
>> to those binaries to PATH, the `texlive-*' ports from MacPorts
>> would be completely hidden and thus useless, more or less: TeXLive
>> wouldn't use any data, binaries, or libraries from MacPorts.
>> 
>> However, to build various packages like `lilypond', `port' needs to
>> believe that some `texlive-*' ports are installed.  What certainly
>> works is to create a small port repository similar to René Bertin's
>> `macstrop' repository to override MacPorts with dummy ports.  My
>> question was whether macports itself provides a simpler solution
>> similar to `texlive-dummy-opensuse', where I have to install just a
>> single .rpm file...  I guess the answer is no.
> 
> Its quite simple.  The macports build of lilypond should be
> configured to use the MacPorts provided builds of TexLive.

I was still unclear, sorry.  To continue with lilypond as an example:
This program uses only TeXLive *programs* and data, but no libraries.
In general, this is true for all other programs within MacPorts that
depend on texlive ports.  It is thus irrelevant whether MacPorts
itself contains the necessary data and binaries, or whether they are
provided externally (in this case, by the native TeXLive
distribution).

> If these ports do not provide what is needed, then just provide an
> additional port for what is missing.

There are no misses.  My `problem' is that the `texlive-*' ports
within MacPorts use a few GByte, doubling everything native TeXLive
already provides!  I want to use native TeXLive directly so that I can
actually call `tlmgr' (or the SVN repository) to update the TeX stuff.
For this reason I want to have some dummy portfiles to make `port'
believe that the `texlive-*' ports are present.  This will take a few
kBytes only...


Werner

Re: TeXLive distribution and macports

[Christopher Jones]

> On 9 Sep 2018, at 4:46 pm, Werner LEMBERG  wrote:
> 
> 
>>> [...] For example, I want to create a replacement for
>>> `texlive-basic' that does nothing except fulfilling the dependency.
>>> This is, after installing this dummy `texlive-basic', `port' shall
>>> believe that `texlive-basic' is indeed installed.
>>> 
>>> Ditto for all other `texlive-*' ports.  Ideally, I would like to
>>> have all this stuff in a single file, to be automatically created
>>> from the actual list of `texlive-*' ports as in
>>> texlive-dummy-opensuse,
>>> cf. 
>>> https://github.com/rolfn/texlive-dummy-opensuse/blob/ba0bc1e2f866c379f750046439b6f4e40725805f/Makefile#L61
>>> and following lines.
>> 
>> Then I am not sure what you intention here is.
>> 
>> Note that MacPorts has a policy of not using external libraries, as
>> far as possible (apart from obvious system ones) so if you aim is to
>> have a port that basically allows something externally externally to
>> pretend to be something MacPorts provides, then no this is strictly
>> not allowed. See for instance
>> 
>> https://trac.macports.org/wiki/FAQ#ownlibs 
>> 
>> 
>> its the same deal as why we do not support using anything installed
>> outside of MacPorts, from /usr/local
> 
> Ah, I assumed too much knowledge, sorry.  TeXLive itself comes with
> binaries for MacOS (both legacy platforms, i.e., 10.6-10.10, and
> recent versions, i.e., 10.10-10.13).  By simply prepending the path to
> those binaries to PATH, the `texlive-*' ports from MacPorts would be
> completely hidden and thus useless, more or less: TeXLive wouldn't use
> any data, binaries, or libraries from MacPorts.
> 
> However, to build various packages like `lilypond', `port' needs to
> believe that some `texlive-*' ports are installed.  What certainly
> works is to create a small port repository similar to René Bertin's
> `macstrop' repository to override MacPorts with dummy ports.  My
> question was whether macports itself provides a simpler solution
> similar to `texlive-dummy-opensuse', where I have to install just a
> single .rpm file...  I guess the answer is no.

Its quite simple. The macports build of lilypond should be configured to use 
the MacPorts provided builds of TexLive. If these ports do not provide what is 
needed, then just provide an additional port for what is missing.

Chris

> 
> 
>Werner



smime.p7s
Description: S/MIME cryptographic signature

Re: TeXLive distribution and macports

[Christopher Jones]

Hi,

Then I am not sure what you intention here is.

Note that MacPorts has a policy of not using external libraries, as far as 
possible (apart from obvious system ones) so if you aim is to have a port that 
basically allows something externally externally to pretend to be something 
MacPorts provides, then no this is strictly not allowed. See for instance

https://trac.macports.org/wiki/FAQ#ownlibs 


its the same deal as why we do not support using anything installed outside of 
MacPorts, from /usr/local

cheers Chris


> On 9 Sep 2018, at 3:46 pm, Werner LEMBERG  wrote:
> 
> 
>> If I understand what you are asking correctly, you are asking how to
>> setup a port that does nothing other than depend on other ports, so
>> installing it drags in all the dependencies, in one go?
> 
> No, I want the opposite.  For example, I want to create a replacement
> for `texlive-basic' that does nothing except fulfilling the
> dependency.  This is, after installing this dummy `texlive-basic',
> `port' shall believe that `texlive-basic' is indeed installed.
> 
> Ditto for all other `texlive-*' ports.  Ideally, I would like to have
> all this stuff in a single file, to be automatically created from the
> actual list of `texlive-*' ports as in texlive-dummy-opensuse,
> cf. 
> https://github.com/rolfn/texlive-dummy-opensuse/blob/ba0bc1e2f866c379f750046439b6f4e40725805f/Makefile#L61
> and following lines.
> 
>> If so we have plenty of these in MacPorts.  [...]
> 
> Thanks; I've already seen such meta-packages.  One of them is actually
> `texlive' itself :-)
> 
> 
>Werner



smime.p7s
Description: S/MIME cryptographic signature

Re: TeXLive distribution and macports

[Werner LEMBERG]

> If I understand what you are asking correctly, you are asking how to
> setup a port that does nothing other than depend on other ports, so
> installing it drags in all the dependencies, in one go?

No, I want the opposite.  For example, I want to create a replacement
for `texlive-basic' that does nothing except fulfilling the
dependency.  This is, after installing this dummy `texlive-basic',
`port' shall believe that `texlive-basic' is indeed installed.

Ditto for all other `texlive-*' ports.  Ideally, I would like to have
all this stuff in a single file, to be automatically created from the
actual list of `texlive-*' ports as in texlive-dummy-opensuse,
cf. 
https://github.com/rolfn/texlive-dummy-opensuse/blob/ba0bc1e2f866c379f750046439b6f4e40725805f/Makefile#L61
and following lines.

> If so we have plenty of these in MacPorts.  [...]

Thanks; I've already seen such meta-packages.  One of them is actually
`texlive' itself :-)


Werner

Re: TeXLive distribution and macports

[Christopher Jones]

Hi,

If I understand what you are asking correctly, you are asking how to setup a 
port that does nothing other than depend on other ports, so installing it drags 
in all the dependencies, in one go ? If so we have plenty of these in MacPorts. 
The first that springs to mind for instance is

https://github.com/macports/macports-ports/blob/master/x11/xorg-proto/Portfile 


One trick is the port has to install *something* in order to work, for instance 
with the binary tarballs. A common trick is to create a README or similar…

cheers Chris

> On 9 Sep 2018, at 3:16 pm, Werner LEMBERG  wrote:
> 
> 
> My computer for daily use is an openSuSE GNU/Linux box; for TeX
> processing, however, I'm directly using tlmgr.[*] Regardless of this I
> don't have any dependency issues with `zypper', openSuSE's package
> manager, since I'm using the nifty `texlive-dummy-opensuse' package,
> 
>  https://github.com/rolfn/texlive-dummy-opensuse.git   .
> 
> This package tells zypper that all TeXLive packages provided by
> openSuSE are installed, without installing them actually.
> 
> I would like to have something similar for MacPorts.  My questions:
> 
> * Has anyone already written such a dummy package?
> 
> * If not, how can I construct `empty packages' that only exist to
>  fulfill package dependencies?
> 
> 
>Werner
> 
> 
> [*] To be more precise, I don't use tlmgr at all but directly
>TeXLive's SVN repository.  However, this distinction doesn't
>matter here.



smime.p7s
Description: S/MIME cryptographic signature

TeXLive distribution and macports

[Werner LEMBERG]

My computer for daily use is an openSuSE GNU/Linux box; for TeX
processing, however, I'm directly using tlmgr.[*] Regardless of this I
don't have any dependency issues with `zypper', openSuSE's package
manager, since I'm using the nifty `texlive-dummy-opensuse' package,

  https://github.com/rolfn/texlive-dummy-opensuse.git   .

This package tells zypper that all TeXLive packages provided by
openSuSE are installed, without installing them actually.

I would like to have something similar for MacPorts.  My questions:

* Has anyone already written such a dummy package?

* If not, how can I construct `empty packages' that only exist to
  fulfill package dependencies?


Werner


[*] To be more precise, I don't use tlmgr at all but directly
TeXLive's SVN repository.  However, this distinction doesn't
matter here.

Re: compilers on Lion

[Ken Cunningham]

On 2018-09-08, at 10:45 PM, Werner LEMBERG wrote:

> 
> Ken,
> 
> 

> What about adding this your explanation to the `LibcxxOnOlderSystems'
> page?  In particular, people who are mainly interested in porting C++
> GNU software to the Mac (and using it, of course) should rather stay
> with libstdc++, if I understand you correctly.  lilypond, for example,
> is a command line program and doesn't need any of the special Mac
> features...

No doubt, the best thing would be to see what is needed to make it compile with 
clang against libc++.

However, if that is not possible, and if the software doesn't provide any c++ 
libraries  or use any c++ libraries , you can build it with gcc and link it 
against libstdc++ and it will work and be internally consistent in it's own 
environment.


> 
>> There _is_ indeed a way for gcc to build against libc++, as you
>> pointed out in a subsequent email, and one of our contributors
>> (Rene) went to the trouble of patching gcc to allow it to accept the
>> "-stdlib=libc++" flag to make this easy. But in the end, he could
>> not get any purchase for his work either from MacPorts or from gcc,
>> and so it went dormant.
> 
> Please post a link.  Is Rene's patch integrated into macports?

I think this is all of it 
.
 There may be some more to it in the associated Portfile. Rene would be happy 
to hear someone found a good use for it.

It is not integrated into macports -- we tend to be very conservative with 
toolchain tweaks in case of unforeseen disasters. I know he talked with gcc 
about it, not sure where that all went.


Ken