2nd MacPorts Meeting & Online Meeting

[Mojca Miklavec]

Hi,

Me and Aljaž would be willing to host the MacPorts meeting in 2017 again.

If you have any particular requests about the desired time / place /
or anything else, we can discuss it before we fix the dates, but we
should probably fix it some time soon.


In addition to the face-to-face meeting, I would like to propose
trying out some online meeting some time in mid-November (or any other
time, according to your wishes). I would propose to discuss:

- creating timeline(s) with most important features that we might want
to implement & get into next releases

- how to improve the ticket system

- and/or any other pressing topic (just not too much all at once)

I'm not sure about the best format of the online meeting though
(IRC?). Any suggestions welcome. It would be nice to prepare proposals
/ agenda for discussion in advance though. I would limit the meeting
to 2 hours max and repeat it if necessary.

Mojca

-

PS: The second point includes things like:

- marking tickets as "upstream problem": tickets that would be neither
closed nor open (= not being actively worked on), but something
"inbetween"; problems that we don't have time or don't know how to
solve, but interested users could still search for them or look into
ways to fix them

- even if the ticket is marked as "maintainer", it's often not clear
whether a ticket just needs a review (and is already considered
"perfect" by maintainer) or if it still needs quite a bit of work; I
would like to see a tag "needs review" for things that just need a
confirmation from a fellow developer

- I would like to see a tag like "needs help"; there might be bug
reports where none of the involved parties knows how to fix the
problem

- I would like to see a tag like "needs approval" meaning that the
patch is ready, only waiting for the maintainer to confirm it or for
the 72-hours to pass (perhaps longer if the patch is not trivial)

- perhaps a tag like "contains a patch, but not yet ready; needs further work"

- when a new version of a port is needed, we need to distinguish
several cases: user just requested an upgrade, but there is no patch;
there is a patch awaiting approval; there is a patch, but the port
cannot be upgraded yet because of known bugs / incompatibilities /
whatever, ...

...

- strategies to classify thousands of old tickets

If you plan to discuss just tickets any further, please let's discuss
that under a different subject, not under "Meeting". I just wanted to
add a bit of explanation. Let's keep the topic of this thread about
the meeting, either online or the real one.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Documentation overhaul

[Lawrence Velázquez]

> On Oct 9, 2016, at 7:23 PM, Ryan Schmidt  wrote:
> 
> I've been with MacPorts for around 10 years and have thought of
> rewriting the documentation for several years so I feel I might be
> able to do it.

+1

> I'm just not doing it right this second because I'm busy trying to
> move us to new hosting. And also because we don't yet know how how we
> will work on GitHub, so we can't fully document that yet.

A lot of our process will be changing very shortly. It's probably a good
idea to hold off for a bit.

> I like markdown but it is missing a lot of things. There is an opinion
> piece I found online about who you should never try to write
> documentation using markdown for this reason.

One problem with Markdown vis-à-vis documentation is that it was
specifically designed to be transformed into HTML. That is why it
permits inline HTML and does not try to do everything in syntax; the
intention was that complex content be written in raw HTML.

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

Re: Documentation overhaul

[Ryan Schmidt]

> On Oct 9, 2016, at 15:23, Rainer Müller  wrote:
> 
> Hello Marcel,
> 
>> On 2016-10-09 15:53, Marcel Bischoff wrote:
>> As Ryan has identified that the online documentation needs work, I'm
>> hereby volunteering to give it a go. Since there appear to be quite
>> specific views on how everthing here needs to be, I'm asking in advance:
>> 
>> - Is that in everyone's interest?
> 
> Of course! :-)

Thanks for your interest, Marcel, but do you feel you would be able to lead 
such an effort, since you seem to be new to MacPorts? I've been with MacPorts 
for around 10 years and have thought of rewriting the documentation for several 
years so I feel I might be able to do it. I'm just not doing it right this 
second because I'm busy trying to move us to new hosting. And also because we 
don't yet know how how we will work on GitHub, so we can't fully document that 
yet. 

My plan is to read all documentation, maybe even print it all out on paper 
(guide, wiki, web site), cut it up, group related information together, remove 
duplication (like the three different sets of install documentation we 
currently have), remove superfluous language, simplify, and also add new 
documentation for things that currently aren't documented, like newer 
portgroups. Also review the organization and content of the documentation of 
other projects that I consider well done, such as svnbook.org. If you know of 
other good documentation I should review let me know. 

My plan is to do this after redoing the web site. I intend to keep the 
installation instructions that have to do with the default installation using 
the macOS Installer on the web site, so rewriting that will be a good beginning 
to rewriting the documentation. 


>> - Is there already someone working on it?
> 
> We have a new help system on trunk. Each command has a separate man page
> that can be reached with 'port help install' and similar. Eventually
> these should also end up on on the web, for example at man.macports.org.
> 
> https://trac.macports.org/wiki/NewHelpSystem
> 
> The source of the new man pages can be found in base/doc/*.txt in
> AsciiDoc format:
> 
> https://trac.macports.org/browser/trunk/base/doc
> 
>> - Where should the final documentation be located: separate website,
>> GitHub wiki, GitHub pages, readthedocs.org, something else?
> 
> The best would be to overhaul/replace https:///guide.macports.org with
> something new and better structure.
> 
> The existing guide can be found here:
> https://trac.macports.org/browser/trunk/doc-new
> 
> Hosting the site should be the least concern, we have resources for that
> now.
> 
>> - In what format should the documentation be written: HTML, Markdown,
>> TeX, whatever? I prefer Markdown.
> 
> I think one of the main reasons why nobody likes updating the guide is
> the DocBook XML syntax.
> 

That is my problem, yes. I don't recall why docbook xml was originally chosen, 
but I would change it now. 


> Back in 2009 (sic!), I started the new help system in AsciiDoc, inspired
> by the git help system. AsciiDoc is more complex than Markdown, but
> supports syntax elements such as includes and macros, that are very
> helpful in reusing the some content in multiple pages and keeping the
> layout consistent. Also, macros can be defined per output device,
> expanding to specific syntax in roff/html/pdf/etc.
> 
> I am fine with using Markdown, as it is the dominant markup syntax
> today. However, it is also very limited, but that might just be enough
> for the guide.

I like markdown but it is missing a lot of things. There is an opinion piece I 
found online about who you should never try to write documentation using 
markdown for this reason. 

Based on Rainer's choice to use asciidoc for the new help system, I suggest we 
convert the guide to asciidoc and use that as the basis for new documentation. 
I already did a trial conversion of the guide to asciidoc which seemed fine for 
the page or two I looked at. Asciidoc is hostable on github pages, which is 
what I will want to do. 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: llvm / clang and thread_local storage problems

[Jack Howarth]

On Sun, Oct 9, 2016 at 6:02 PM, Jack Howarth
 wrote:
> On Sun, Oct 9, 2016 at 5:57 PM, Jack Howarth
>  wrote:
>> On Sun, Oct 9, 2016 at 4:46 PM, Jack Howarth
>>  wrote:
>>> On Sun, Oct 9, 2016 at 3:20 PM, Jeremy Huddleston Sequoia
>>>  wrote:

> On Oct 9, 2016, at 09:47, Jack Howarth  
> wrote:
>
> On Sun, Oct 9, 2016 at 3:53 AM, Jeremy Huddleston Sequoia
>  wrote:
>> thread_local support was added in OS X 10.9 (along with 
>> __cxa_thread_atexit being added to Libc as part of that support).  As 
>> long as your minimum deployment target is 10.9, you should be fine.  The 
>> issue is that you're on 10.6, so you don't have __cxa_thread_atexit.
>>
>> There is active conversation right now about adding a fallback 
>> implementation of __cxa_thread_atexit directly into libcxxabi.  See 
>> https://reviews.llvm.org/D21803 as that might be quite useful for your 
>> needs.  If so, provide a patch to libcxxabi that incorporates it, and 
>> I'll get it in.
>
> On the topic of thread local support, the failures in the guile 2.0.x
> test suite should be looked at...
>
> https://trac.macports.org/ticket/52556
>
> to determine if Apple's thread-local-storage implementation is buggy
> as upstream guile claims.

 Radar?
>>>
>>> radar://28688091 "guile 2.0.12 exposes potential thread-local-storage
>>> bug on Mac OS X"
>>
>> One other piece of information is the following comments placed in
>> libguile/threads.c that should give you a rough picture of what guile
>> is doing with thread-local-storage (in case anything there seems
>> outside the scope of the Apple implementation).
>>
>> /* When thread-local storage (TLS) is available, a pointer to the
>>current-thread object is kept in TLS.  Note that storing the thread-object
>>itself in TLS (rather than a pointer to some malloc'd memory) is not
>>possible since thread objects may live longer than the actual thread they
>>represent.  */
>>
>> /* Cache the current thread in TLS for faster lookup.  */
>>
>
> One other comment in libguile/async.c
>
> /* These are function variants of the same-named macros (uppercase) for use
>outside of libguile.  This is so that `SCM_I_CURRENT_THREAD', which may
>reside in TLS, is not accessed from outside of libguile.  It thus allows
>libguile to be built with the "local-dynamic" TLS model.  */
>

FYI, rebuilding guile-2.0.12 with -ftls-model=local-dynamic passed on
CPPFLAGS doesn't suppress the regressions.

>>>
>>> Note that currently the guile Portfile in MacPorts lacks the support
>>> for 'sudo port -d test guile' to work.
>>>

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

Re: llvm / clang and thread_local storage problems

[Jack Howarth]

On Sun, Oct 9, 2016 at 5:57 PM, Jack Howarth
 wrote:
> On Sun, Oct 9, 2016 at 4:46 PM, Jack Howarth
>  wrote:
>> On Sun, Oct 9, 2016 at 3:20 PM, Jeremy Huddleston Sequoia
>>  wrote:
>>>
 On Oct 9, 2016, at 09:47, Jack Howarth  
 wrote:

 On Sun, Oct 9, 2016 at 3:53 AM, Jeremy Huddleston Sequoia
  wrote:
> thread_local support was added in OS X 10.9 (along with 
> __cxa_thread_atexit being added to Libc as part of that support).  As 
> long as your minimum deployment target is 10.9, you should be fine.  The 
> issue is that you're on 10.6, so you don't have __cxa_thread_atexit.
>
> There is active conversation right now about adding a fallback 
> implementation of __cxa_thread_atexit directly into libcxxabi.  See 
> https://reviews.llvm.org/D21803 as that might be quite useful for your 
> needs.  If so, provide a patch to libcxxabi that incorporates it, and 
> I'll get it in.

 On the topic of thread local support, the failures in the guile 2.0.x
 test suite should be looked at...

 https://trac.macports.org/ticket/52556

 to determine if Apple's thread-local-storage implementation is buggy
 as upstream guile claims.
>>>
>>> Radar?
>>
>> radar://28688091 "guile 2.0.12 exposes potential thread-local-storage
>> bug on Mac OS X"
>
> One other piece of information is the following comments placed in
> libguile/threads.c that should give you a rough picture of what guile
> is doing with thread-local-storage (in case anything there seems
> outside the scope of the Apple implementation).
>
> /* When thread-local storage (TLS) is available, a pointer to the
>current-thread object is kept in TLS.  Note that storing the thread-object
>itself in TLS (rather than a pointer to some malloc'd memory) is not
>possible since thread objects may live longer than the actual thread they
>represent.  */
>
> /* Cache the current thread in TLS for faster lookup.  */
>

One other comment in libguile/async.c

/* These are function variants of the same-named macros (uppercase) for use
   outside of libguile.  This is so that `SCM_I_CURRENT_THREAD', which may
   reside in TLS, is not accessed from outside of libguile.  It thus allows
   libguile to be built with the "local-dynamic" TLS model.  */

>>
>> Note that currently the guile Portfile in MacPorts lacks the support
>> for 'sudo port -d test guile' to work.
>>
>>>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: llvm / clang and thread_local storage problems

[Jack Howarth]

On Sun, Oct 9, 2016 at 4:46 PM, Jack Howarth
 wrote:
> On Sun, Oct 9, 2016 at 3:20 PM, Jeremy Huddleston Sequoia
>  wrote:
>>
>>> On Oct 9, 2016, at 09:47, Jack Howarth  
>>> wrote:
>>>
>>> On Sun, Oct 9, 2016 at 3:53 AM, Jeremy Huddleston Sequoia
>>>  wrote:
 thread_local support was added in OS X 10.9 (along with 
 __cxa_thread_atexit being added to Libc as part of that support).  As long 
 as your minimum deployment target is 10.9, you should be fine.  The issue 
 is that you're on 10.6, so you don't have __cxa_thread_atexit.

 There is active conversation right now about adding a fallback 
 implementation of __cxa_thread_atexit directly into libcxxabi.  See 
 https://reviews.llvm.org/D21803 as that might be quite useful for your 
 needs.  If so, provide a patch to libcxxabi that incorporates it, and I'll 
 get it in.
>>>
>>> On the topic of thread local support, the failures in the guile 2.0.x
>>> test suite should be looked at...
>>>
>>> https://trac.macports.org/ticket/52556
>>>
>>> to determine if Apple's thread-local-storage implementation is buggy
>>> as upstream guile claims.
>>
>> Radar?
>
> radar://28688091 "guile 2.0.12 exposes potential thread-local-storage
> bug on Mac OS X"

One other piece of information is the following comments placed in
libguile/threads.c that should give you a rough picture of what guile
is doing with thread-local-storage (in case anything there seems
outside the scope of the Apple implementation).

/* When thread-local storage (TLS) is available, a pointer to the
   current-thread object is kept in TLS.  Note that storing the thread-object
   itself in TLS (rather than a pointer to some malloc'd memory) is not
   possible since thread objects may live longer than the actual thread they
   represent.  */

/* Cache the current thread in TLS for faster lookup.  */

>
> Note that currently the guile Portfile in MacPorts lacks the support
> for 'sudo port -d test guile' to work.
>
>>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Clemens Lang]

Hi,

On Fri, Oct 07, 2016 at 09:13:11AM -0500, Ryan Schmidt wrote:
> Regarding updating pandoc, see https://trac.macports.org/ticket/48324
> Regarding updating ghc, see https://trac.macports.org/ticket/48899
> Regarding old llvm on Sierra, see https://trac.macports.org/ticket/52424

As a follow-up on the whole GHC vs. LLVM (and thus Pandoc) topic: In the
past, we packaged a subset of GHC and Haskell ports that did not match
the versions in haskell-platform. Feedback back then was that we should
stay with the haskell platform, so we did.

For this reason, I cannot simply update GHC without updating
haskell-platform (unless we want to re-visit this decision). I have the
update of GHC and the platform ports to version 8.0.1 [1] done, expect
for stack [2]. Haskell Platform without Stack seems less useful, since
Stack is supposed to become a de-facto dev environment management tool,
if I understand things correctly. Unfortunately, stack has a gazillion
dependencies we haven't packaged yet, at which point it makes little
sense for me to attempt to write all those Portfiles by hand. So either:
 - a group of people splits the work
 - generation of haskell portfiles needs to be automated
I'd welcome help with both. Let me know if you know a Haskell or two and
want to help out with the latter.

[1] https://www.haskell.org/platform/contents.html
[2] http://hackage.haskell.org/package/stack

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

Re: CMake issue: binary (needed during build) links againts /opt/local/lib/foo.dylib

[Clemens Lang]

On Sat, Oct 08, 2016 at 04:10:34PM +0200, Mojca Miklavec wrote:
> >> The command "otool -L cfg" reports
> >>@rpath/libMiKTeX209-core.1.dylib
> >
> > That looks correct, but really depends on what "cfg"'s rpath is.
> 
> "cfg" is a binary. I'm not sure whether it gets installed, but it
> does, then the path is definitely wrong.

The settings I gave you tell CMake to re-link the binary without an
rpath on 'make install', so if you ran this in the build tree (which I
assumed because you mentioned destroot was broken) it was correct.

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

Re: llvm / clang and thread_local storage problems

[Jack Howarth]

On Sun, Oct 9, 2016 at 4:46 PM, Jack Howarth
 wrote:
> On Sun, Oct 9, 2016 at 3:20 PM, Jeremy Huddleston Sequoia
>  wrote:
>>
>>> On Oct 9, 2016, at 09:47, Jack Howarth  
>>> wrote:
>>>
>>> On Sun, Oct 9, 2016 at 3:53 AM, Jeremy Huddleston Sequoia
>>>  wrote:
 thread_local support was added in OS X 10.9 (along with 
 __cxa_thread_atexit being added to Libc as part of that support).  As long 
 as your minimum deployment target is 10.9, you should be fine.  The issue 
 is that you're on 10.6, so you don't have __cxa_thread_atexit.

 There is active conversation right now about adding a fallback 
 implementation of __cxa_thread_atexit directly into libcxxabi.  See 
 https://reviews.llvm.org/D21803 as that might be quite useful for your 
 needs.  If so, provide a patch to libcxxabi that incorporates it, and I'll 
 get it in.
>>>
>>> On the topic of thread local support, the failures in the guile 2.0.x
>>> test suite should be looked at...
>>>
>>> https://trac.macports.org/ticket/52556
>>>
>>> to determine if Apple's thread-local-storage implementation is buggy
>>> as upstream guile claims.
>>
>> Radar?
>
> radar://28688091 "guile 2.0.12 exposes potential thread-local-storage
> bug on Mac OS X"
>
> Note that currently the guile Portfile in MacPorts lacks the support
> for 'sudo port -d test guile' to work.
>

Also added a Portfile diff to https://trac.macports.org/ticket/52556
to add the missing test support and suppress tls to pass it.

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

Re: llvm / clang and thread_local storage problems

[Jack Howarth]

On Sun, Oct 9, 2016 at 3:20 PM, Jeremy Huddleston Sequoia
 wrote:
>
>> On Oct 9, 2016, at 09:47, Jack Howarth  wrote:
>>
>> On Sun, Oct 9, 2016 at 3:53 AM, Jeremy Huddleston Sequoia
>>  wrote:
>>> thread_local support was added in OS X 10.9 (along with __cxa_thread_atexit 
>>> being added to Libc as part of that support).  As long as your minimum 
>>> deployment target is 10.9, you should be fine.  The issue is that you're on 
>>> 10.6, so you don't have __cxa_thread_atexit.
>>>
>>> There is active conversation right now about adding a fallback 
>>> implementation of __cxa_thread_atexit directly into libcxxabi.  See 
>>> https://reviews.llvm.org/D21803 as that might be quite useful for your 
>>> needs.  If so, provide a patch to libcxxabi that incorporates it, and I'll 
>>> get it in.
>>
>> On the topic of thread local support, the failures in the guile 2.0.x
>> test suite should be looked at...
>>
>> https://trac.macports.org/ticket/52556
>>
>> to determine if Apple's thread-local-storage implementation is buggy
>> as upstream guile claims.
>
> Radar?

radar://28688091 "guile 2.0.12 exposes potential thread-local-storage
bug on Mac OS X"

Note that currently the guile Portfile in MacPorts lacks the support
for 'sudo port -d test guile' to work.

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

Re: Documentation overhaul

[Rainer Müller]

Hello Marcel,

On 2016-10-09 15:53, Marcel Bischoff wrote:
> As Ryan has identified that the online documentation needs work, I'm
> hereby volunteering to give it a go. Since there appear to be quite
> specific views on how everthing here needs to be, I'm asking in advance:
> 
> - Is that in everyone's interest?

Of course! :-)

> - Is there already someone working on it?

We have a new help system on trunk. Each command has a separate man page
that can be reached with 'port help install' and similar. Eventually
these should also end up on on the web, for example at man.macports.org.

https://trac.macports.org/wiki/NewHelpSystem

The source of the new man pages can be found in base/doc/*.txt in
AsciiDoc format:

https://trac.macports.org/browser/trunk/base/doc

> - Where should the final documentation be located: separate website,
>  GitHub wiki, GitHub pages, readthedocs.org, something else?

The best would be to overhaul/replace https:///guide.macports.org with
something new and better structure.

The existing guide can be found here:
https://trac.macports.org/browser/trunk/doc-new

Hosting the site should be the least concern, we have resources for that
now.

> - In what format should the documentation be written: HTML, Markdown,
>  TeX, whatever? I prefer Markdown.

I think one of the main reasons why nobody likes updating the guide is
the DocBook XML syntax.

Back in 2009 (sic!), I started the new help system in AsciiDoc, inspired
by the git help system. AsciiDoc is more complex than Markdown, but
supports syntax elements such as includes and macros, that are very
helpful in reusing the some content in multiple pages and keeping the
layout consistent. Also, macros can be defined per output device,
expanding to specific syntax in roff/html/pdf/etc.

I am fine with using Markdown, as it is the dominant markup syntax
today. However, it is also very limited, but that might just be enough
for the guide.

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

Re: llvm / clang and thread_local storage problems

[Jeremy Huddleston Sequoia]

> On Oct 9, 2016, at 09:47, Jack Howarth  wrote:
> 
> On Sun, Oct 9, 2016 at 3:53 AM, Jeremy Huddleston Sequoia
>  wrote:
>> thread_local support was added in OS X 10.9 (along with __cxa_thread_atexit 
>> being added to Libc as part of that support).  As long as your minimum 
>> deployment target is 10.9, you should be fine.  The issue is that you're on 
>> 10.6, so you don't have __cxa_thread_atexit.
>> 
>> There is active conversation right now about adding a fallback 
>> implementation of __cxa_thread_atexit directly into libcxxabi.  See 
>> https://reviews.llvm.org/D21803 as that might be quite useful for your 
>> needs.  If so, provide a patch to libcxxabi that incorporates it, and I'll 
>> get it in.
> 
> On the topic of thread local support, the failures in the guile 2.0.x
> test suite should be looked at...
> 
> https://trac.macports.org/ticket/52556
> 
> to determine if Apple's thread-local-storage implementation is buggy
> as upstream guile claims.

Radar?



smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: llvm / clang and thread_local storage problems

[Jack Howarth]

On Sun, Oct 9, 2016 at 3:53 AM, Jeremy Huddleston Sequoia
 wrote:
> thread_local support was added in OS X 10.9 (along with __cxa_thread_atexit 
> being added to Libc as part of that support).  As long as your minimum 
> deployment target is 10.9, you should be fine.  The issue is that you're on 
> 10.6, so you don't have __cxa_thread_atexit.
>
> There is active conversation right now about adding a fallback implementation 
> of __cxa_thread_atexit directly into libcxxabi.  See 
> https://reviews.llvm.org/D21803 as that might be quite useful for your needs. 
>  If so, provide a patch to libcxxabi that incorporates it, and I'll get it in.

On the topic of thread local support, the failures in the guile 2.0.x
test suite should be looked at...

https://trac.macports.org/ticket/52556

to determine if Apple's thread-local-storage implementation is buggy
as upstream guile claims.
   Jack

>
> Thanks,
> Jeremy
>
>
>> On Oct 8, 2016, at 23:06, Ken Cunningham  
>> wrote:
>>
>>
>> On 2016-10-08, at 10:03 PM, Stephen J. Butler wrote:
>>
>>> FYI, it's in the Xcode 8 release notes:
>>>
>>> https://developer.apple.com/library/content/releasenotes/DeveloperTools/RN-Xcode/Introduction.html
>>>
>>> I did a quick test file and it seems to compile with Apple clang. No clue 
>>> on compatibility issues though.
>>>
>>
>> Thanks!
>>
>>
>>> Thanks for finding and sharing that information. It sounds like you could 
>>> get TLS by using MacPorts clang instead of Xcode clang, but that it will be 
>>> incompatible with whatever TLS implementation Apple eventually creates.
>>
>>
>> I had hoped it would be in the macports-clang-3.7 build I'm using, but it 
>> seems to error out.
>>
>> However, I noticed this bit in the the libcxxabi port
>>
>> libcxxabi-3.7.0.src/include/cxxabi.h
>>
>>
>> #ifdef __linux__
>> // Linux TLS support. Not yet an official part of the Itanium ABI.
>> // 
>> https://sourceware.org/glibc/wiki/Destructor%20support%20for%20thread_local%20variables
>> extern int __cxa_thread_atexit(void (*)(void *), void *, void *) throw();
>> #endif
>>
>> and - if I open up that guard, it actually builds cleanly on MacOSX.
>>
>> I wonder if TLS support was just disabled on all but Linux...perhaps I'll 
>> try installing this new version I just built and see what happens. --- after 
>> I back everything up :>
>>
>> Ken
>> ___
>> macports-dev mailing list
>> macports-dev@lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Documentation overhaul

[Marcel Bischoff]

On 16/10/09, Ken Cunningham wrote:


On 2016-10-09, at 6:53 AM, Marcel Bischoff wrote:


there appear to be quite specific views on how everthing here needs to be



This is true, and it doesn't take long to notice -- but over 20,000 ports hang 
tight together and almost all of them work all the way back to Tiger. And that 
is no accident.

So there are big payoffs to a guiding hand. And there are ready teachers around 
here who know an awful lot.

Maybe that is part of what the new kids will need to see and absorb as
well...


Especially regarding the last point I'd suggest adding a short
introduction explaining those things concisely as to help newcomers
understand why things are like they are.

As I am kind of new around here (but don't cosider me a kid), maybe my
experiences with questions regarding The Way It Is(tm) can help here.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Documentation overhaul

[Ken Cunningham]

On 2016-10-09, at 6:53 AM, Marcel Bischoff wrote:

> there appear to be quite specific views on how everthing here needs to be


This is true, and it doesn't take long to notice -- but over 20,000 ports hang 
tight together and almost all of them work all the way back to Tiger. And that 
is no accident.

So there are big payoffs to a guiding hand. And there are ready teachers around 
here who know an awful lot.

Maybe that is part of what the new kids will need to see and absorb as well...

K___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Documentation overhaul

[Marcel Bischoff]

Hi all.

As Ryan has identified that the online documentation needs work, I'm
hereby volunteering to give it a go. Since there appear to be quite
specific views on how everthing here needs to be, I'm asking in advance:

- Is that in everyone's interest?

- Is there already someone working on it?

- Where should the final documentation be located: separate website,
 GitHub wiki, GitHub pages, readthedocs.org, something else?

- In what format should the documentation be written: HTML, Markdown,
 TeX, whatever? I prefer Markdown.

Please let me know what you think.

Best,
Marcel
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Of C++ (and other) runtimes

[René J . V . Bertin]

On Sunday October 09 2016 01:04:39 Jeremy Huddleston Sequoia wrote:

>That being said, it's technically possible and they should be binary 
>compatible.

Oh, and what about using DYLD_LIBRARY_PRELOAD? Not for systematic use, but 
shouldn't it be useful for testing purposes, or for debugging for instance when 
your code triggers one of those dynamic_cast errors (cf. 
https://llvm.org/svn/llvm-project/libcxxabi/trunk/src/private_typeinfo.cpp)?

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

Re: Of C++ (and other) runtimes

[René J . V . Bertin]

On Sunday October 09 2016 01:04:39 Jeremy Huddleston Sequoia wrote:

>My advice is to not mess with the base OS.  There is a very good reason why I 
>force the user to use a variant and don't even give instructions on how to use 
>darwinup to install the libcxxabi and libcxx tarballs.
>
>That being said, it's technically possible and they should be binary 
>compatible.

>> And since we're talking about runtimes: is it even possible to upgrade the 
>> ObjectiveC runtime, as far as that is of any interest when you don't upgrade 
>> the rest of the SDK using it?
>
>It's all code and objc4 is OSS.  Go nuts 
>(http://opensource.apple.com/source/objc4/objc4-680/).  Make backups.  YMMV.

Heh. I see no mention of ARC in the release notes; is that not part of 
(supported in) the runtime?

Still, is there a point in taking the risk? Not that it should be particularly 
hard to back out as long as you keep copies of the originals as well as a way 
to boot the system so you can mount the updated root and restore those original 
copies. I suppose that building with more than the standard optimisation 
settings will not make a significant difference in runtime performance?

Are these supposed to be signed, btw?

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

gcr requires gtk to be installed with +x11 (was: Epiphany requires gnupg and does not accept gnupg21?)

[Johannes Kastl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi David,

thanks for the help.

On 09.10.16 07:50 David Evans wrote:

> I've confirmed that gcr's dependency on gnupg is unnecessary --
> works fine without it.  Removed in r153722. Let me know if you
> have any further problems upgrading gimp2.

I tried to install gcr to confirm that it does no longer conflict
with gnupg21. But I could not.

I had gimp2 installed with +quartz variant, thus gtk3 is being built
with +quartz. Now gcr tells me:

> --->  Computing dependencies for gcr --->  Fetching archive for
> gcr Error: org.macports.archivefetch for port gcr returned: gtk3
> must be installed with +x11.

I'll try to install gtk3 with +x11, and see what happens, but I
guess then I can't install gimp2 with +quartz...

Johannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/

iEYEARECAAYFAlf5/qIACgkQzi3gQ/xETbJJoQCgjNuKATTfDv6bBbGiXPaSmsqE
Wy0An3I8dd14WKE9LVGe9CO3//uZI6KF
=EE/W
-END PGP SIGNATURE-

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

Re: Of C++ (and other) runtimes

[Jeremy Huddleston Sequoia]

> On Oct 7, 2016, at 08:59, René J.V. Bertin  wrote:
> 
> On Friday October 07 2016 11:43:48 Lawrence Velázquez wrote:
> 
> [was Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of 
> using libstdc++]
> 
>> it might be useful to refine this mechanism to allow something like
>> "configure.compiler.cxx macports-gcc-XYZ", which would add a direct
>> library dependency on libgcc (among other things).
> 
> Yep, that sounds like a good idea, but can that not be handled by the 
> existing configure.cxx syntax?
> 
> BTW: how risky is it to replace libc++ on newer OS X versions which do in 
> fact provide them?

My advice is to not mess with the base OS.  There is a very good reason why I 
force the user to use a variant and don't even give instructions on how to use 
darwinup to install the libcxxabi and libcxx tarballs.

That being said, it's technically possible and they should be binary compatible.

I was actually using the newer libcxxabi and libcxx ports on Lion and Mountain 
Lion for a while.  The only issue I saw was that a system process (helpd or 
something like that) was crashing (I think on ML).  I didn't dig into the 
issue, but it's possible it was just a bug in the daemon that was revealed by 
the newer C++ runtime.  It's also quite possible there was a serious regression 
in the C++ runtime.  I never got around to looking into it more closely.

> And since we're talking about runtimes: is it even possible to upgrade the 
> ObjectiveC runtime, as far as that is of any interest when you don't upgrade 
> the rest of the SDK using it?

It's all code and objc4 is OSS.  Go nuts 
(http://opensource.apple.com/source/objc4/objc4-680/).  Make backups.  YMMV.

> 
> R.
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev



smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: llvm / clang and thread_local storage problems

[Jeremy Huddleston Sequoia]

thread_local support was added in OS X 10.9 (along with __cxa_thread_atexit 
being added to Libc as part of that support).  As long as your minimum 
deployment target is 10.9, you should be fine.  The issue is that you're on 
10.6, so you don't have __cxa_thread_atexit.

There is active conversation right now about adding a fallback implementation 
of __cxa_thread_atexit directly into libcxxabi.  See 
https://reviews.llvm.org/D21803 as that might be quite useful for your needs.  
If so, provide a patch to libcxxabi that incorporates it, and I'll get it in.

Thanks,
Jeremy


> On Oct 8, 2016, at 23:06, Ken Cunningham  
> wrote:
> 
> 
> On 2016-10-08, at 10:03 PM, Stephen J. Butler wrote:
> 
>> FYI, it's in the Xcode 8 release notes:
>> 
>> https://developer.apple.com/library/content/releasenotes/DeveloperTools/RN-Xcode/Introduction.html
>> 
>> I did a quick test file and it seems to compile with Apple clang. No clue on 
>> compatibility issues though.
>> 
> 
> Thanks!
> 
> 
>> Thanks for finding and sharing that information. It sounds like you could 
>> get TLS by using MacPorts clang instead of Xcode clang, but that it will be 
>> incompatible with whatever TLS implementation Apple eventually creates.
> 
> 
> I had hoped it would be in the macports-clang-3.7 build I'm using, but it 
> seems to error out.
> 
> However, I noticed this bit in the the libcxxabi port 
> 
> libcxxabi-3.7.0.src/include/cxxabi.h
> 
> 
> #ifdef __linux__
> // Linux TLS support. Not yet an official part of the Itanium ABI.
> // 
> https://sourceware.org/glibc/wiki/Destructor%20support%20for%20thread_local%20variables
> extern int __cxa_thread_atexit(void (*)(void *), void *, void *) throw();
> #endif
> 
> and - if I open up that guard, it actually builds cleanly on MacOSX.
> 
> I wonder if TLS support was just disabled on all but Linux...perhaps I'll try 
> installing this new version I just built and see what happens. --- after I 
> back everything up :>
> 
> Ken
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev



smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: llvm / clang and thread_local storage problems

[Ken Cunningham]

On 2016-10-08, at 10:03 PM, Stephen J. Butler wrote:

> FYI, it's in the Xcode 8 release notes:
> 
> https://developer.apple.com/library/content/releasenotes/DeveloperTools/RN-Xcode/Introduction.html
> 
> I did a quick test file and it seems to compile with Apple clang. No clue on 
> compatibility issues though.
> 

Thanks!


> Thanks for finding and sharing that information. It sounds like you could get 
> TLS by using MacPorts clang instead of Xcode clang, but that it will be 
> incompatible with whatever TLS implementation Apple eventually creates.


I had hoped it would be in the macports-clang-3.7 build I'm using, but it seems 
to error out.

However, I noticed this bit in the the libcxxabi port 

libcxxabi-3.7.0.src/include/cxxabi.h


#ifdef __linux__
// Linux TLS support. Not yet an official part of the Itanium ABI.
// 
https://sourceware.org/glibc/wiki/Destructor%20support%20for%20thread_local%20variables
extern int __cxa_thread_atexit(void (*)(void *), void *, void *) throw();
#endif

and - if I open up that guard, it actually builds cleanly on MacOSX.

I wonder if TLS support was just disabled on all but Linux...perhaps I'll try 
installing this new version I just built and see what happens. --- after I back 
everything up :>

Ken___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev