As mentioned earlier, I updated base and the ports to defer dropping support for these legacy compilers.
I also did an audit of the ports that are blacklisting clang and fixed a few
along the way to remove the blacklisting. It's not surprising that most of the
remainder are dead ports, over half of which don't even build on current OS
versions despite the blacklisting of clang. Here's my summary:
# Projects bugs: Misc
./devel/inform/Portfile:compiler.blacklist *clang*
./lang/gprolog/Portfile:compiler.blacklist-append *clang* *llvm-gcc-4.2
# Project bugs: clang strictness is helping to find real project errors and
it's likely newer gcc fail as well
./sysutils/apt/Portfile:compiler.blacklist *clang*
# Projects bugs: Misc C++
./news/nget/Portfile:compiler.blacklist *clang*
./science/coinor-liblemon/Portfile:compiler.blacklist *clang*
./science/solid/Portfile:compiler.blacklist *clang*
./textproc/irstlm/Portfile:compiler.blacklist *clang*
./textproc/stardict/Portfile:compiler.blacklist *clang*
# Project bugs: Bad gnulib-tool hacks
./lang/g-wrap/Portfile:compiler.blacklist-append *clang*
# Project bugs: ccdep.pl
./graphics/sam2p/Portfile:compiler.blacklist-append *clang*
# Project bugs: gcc extension that clang does not implement: -fnested-functions
./games/frozenbubble2/Portfile:compiler.blacklist *clang*
# Project bugs: gcc extension that clang does not implement: __builtin_apply,
etc.
./science/swarm/Portfile:compiler.blacklist *clang*
# Not sure if these are project issues or an llvm bug
./lang/pfe/Portfile:compiler.blacklist *clang* *llvm-gcc-4.2
# Only done a non-default variant
./science/nds2-client/Portfile: compiler.blacklist-append *clang*
# Don't seem to build despite (and sometimes because of) the blacklisting
./aqua/SIDPLAY/Portfile:compiler.blacklist *clang*
./aqua/TeXShop/Portfile:compiler.blacklist *clang*
./cross/arm-elf-gcc3/Portfile:compiler.blacklist *clang* *llvm-gcc-4.2
./cross/i386-mingw32-gcc/Portfile:compiler.blacklist *llvm-gcc-4.2 *clang*
./cross/m68k-elf-gcc/Portfile:compiler.blacklist *clang* *llvm-gcc-4.2
./cross/msp430-gcc-devel/Portfile:compiler.blacklist *clang*
./cross/msp430-gdb/Portfile:compiler.blacklist *clang*
./cross/msp430-gdb-devel/Portfile:compiler.blacklist *clang*
./editors/texstudio/Portfile:compiler.blacklist *clang*
./finance/taxbird/Portfile:compiler.blacklist *clang*
./gis/grass/Portfile:# compiler.blacklist *clang*
./lang/hugs98/Portfile:compiler.blacklist *clang*
./net/sobby/Portfile:compiler.blacklist *clang*
./science/alps/Portfile: compiler.blacklist *clang*
# Listed as not supported on recent OS versions anyways. Does anyone care? If
not, we should just remove these ports.
./graphics/agave/Portfile:compiler.blacklist *clang*
./graphics/exact-image/Portfile:compiler.blacklist-append *clang*
./math/classias/Portfile:compiler.blacklist *clang*
./net/mediatomb/Portfile:compiler.blacklist *clang*
./science/bali-phy/Portfile:compiler.blacklist *clang*
./science/eo/Portfile:compiler.blacklist *clang*
./textproc/mgizapp/Portfile:compiler.blacklist *clang*
./textproc/pialign/Portfile:compiler.blacklist *clang*
./textproc/sword/Portfile:compiler.blacklist-append *clang*
# The gcc-4.2 ports don't help because they're blacklisted as well (most are
libstdc++ C++11 hacks that should be done differently)
./python/py-healpy/Portfile: compiler.blacklist *gcc-4.2 *clang*
./science/gnuradio/Portfile: compiler.blacklist-append *clang* {*gcc-3*}
{*gcc-4.[0-6]}
./science/gr-foo/Portfile: compiler.blacklist-append *clang* {*gcc-3*}
{*gcc-4.[0-6]}
./science/gr-ieee802-11/Portfile: compiler.blacklist-append *clang*
{*gcc-3*} {*gcc-4.[0-6]}
./science/gr-ieee802-15-4/Portfile: compiler.blacklist-append *clang*
{*gcc-3*} {*gcc-4.[0-6]}
./science/seqan-apps/Portfile:compiler.blacklist *gcc-4.2 *clang*
macports-gcc-4.9
./science/volk/Portfile: compiler.blacklist-append *clang* *gcc-3.*
{*gcc-4.[0-6]}
# There ports are for legacy versions. Current versions aren't blacklisted.
./databases/mysql5/Portfile: compiler.blacklist-append *clang*
./databases/mysql51/Portfile: compiler.blacklist-append *clang*
./lang/ruby186/Portfile:compiler.blacklist *clang* *llvm-gcc-4.2
# Blacklisting done conditionally such that it doesn't matter here
./databases/rethinkdb/Portfile: compiler.blacklist-append *clang*
> On Oct 12, 2015, at 13:14, Jeremy Huddleston Sequoia <[email protected]>
> wrote:
>
>
>> On Oct 12, 2015, at 11:28, Joshua Root <[email protected]> wrote:
>>
>> On Mon, Oct 12, 2015 at 1:49 PM, Jeremy Huddleston Sequoia
>> <[email protected]> wrote:
>>>
>>>> On Oct 11, 2015, at 23:15, Ryan Schmidt <[email protected]> wrote:
>>>>
>>>> On Oct 11, 2015, at 11:14 AM, [email protected] wrote:
>>>>
>>>>> Revision
>>>>> 141132
>>>>> Author
>>>>> [email protected]
>>>>> Date
>>>>> 2015-10-11 09:14:38 -0700 (Sun, 11 Oct 2015)
>>>>> Log Message
>>>>>
>>>>> apple-gcc42: Drop support on ElCap
>>>>
>>>>
>>>> On Oct 11, 2015, at 11:15 AM, [email protected] wrote:
>>>>
>>>>> Revision
>>>>> 141133
>>>>> Author
>>>>> [email protected]
>>>>> Date
>>>>> 2015-10-11 09:15:20 -0700 (Sun, 11 Oct 2015)
>>>>> Log Message
>>>>>
>>>>> llvm-gcc42: Drop support on ElCap
>>>>
>>>>
>>>> On Oct 11, 2015, at 12:09 PM, [email protected] wrote:
>>>>
>>>>> Revision
>>>>> 141134
>>>>> Author
>>>>> [email protected]
>>>>> Date
>>>>> 2015-10-11 10:09:05 -0700 (Sun, 11 Oct 2015)
>>>>> Log Message
>>>>>
>>>>> Refactor and update portconfigure::get_compiler_fallback
>>>>>
>>>>> Separate out list generation into stages for easier updates in the future.
>>>>> Use newer clang versions when using libc++ as our default C++ runtime.
>>>>> Don't add legacy gcc fallbacks on El Capitan.
>>>>
>>>>
>>>> Any particular reason you removed apple-gcc42 and llvm-gcc42 on El
>>>> Capitan? We only just released MacPorts 2.3.4 which finally returned
>>>> apple-gcc42 and llvm-gcc42 to the list of available compilers for Xcode 6
>>>> and later (r140687). Reverting r141132, apple-gcc42 builds fine for me on
>>>> 10.11, and reverting r141133, llvm-gcc42 builds fine for me with
>>>> apple-gcc42 on 10.11. Are there situations where these compilers don't
>>>> work correctly because of a change in El Capitan?
>>>
>>> They don't support C11
>>> They don't support C++11
>>> They don't support libc++
>>
>> None of that has changed since Yosemite.
>
> Yes, and I was quite happy that the compilers failed to work in Yosemite,
> allowing me to mark them as unavailable. Unfortunately, some life was
> breathed into them again, preventing them from slipping off to their well
> deserved graev.
>
>>> They've been deprecated for almost 5 years now.
>>> I don't want to give the impression that we actually support this legacy
>>> toolchain on modern systems; it's only purpose was to help build ports that
>>> weren't building with clang.
>>> If you don't want to drop support for them now, what do you consider a good
>>> time? I'd prefer to not keep around legacy compilers if they're not
>>> actually needed. So I guess I'll flip the question to you and ask if
>>> there's any compelling reason why one would still need them on El Cap.
>>> Xcode 7's clang (and indeed macports-clang-3.7) is a much more mature,
>>> robust, and reliable compiler on El Cap than gcc-4.2.
>>
>> Nobody's suggesting putting them anywhere but last in the fallback list.
>> There are still ports that won't build without them. Refusing to build
>> them at all when they do work isn't helpful.
>
> Last I checked, the ports that are still blacklisting clang outright also
> fail to build in general. I went through all the remaining ports that listed
> *clang* or clang in compiler.blacklist and updated most of them to build with
> clang. libpar2 was the only one that built that I didn't fix. The rest
> didn't even build with apple-gcc-4.2.
>
> Are there any ports other than libpar2 that you are aware of that have issues
> when built with clang?
>
> I'll do another audit today and send out a summary.
>
> I'll update base to allow the fallback for now while we discuss.
>
>> Add notes if you want to
>> make it crystal clear that nobody should be using these on recent
>> systems if they can help it.
>>
>> If they break again in future, I doubt anyone will bother fixing them,
>> and that's fine.
>>
>> - Josh
>
>
>> On Oct 12, 2015, at 11:40, Jack Howarth <[email protected]>
>> wrote:
>>
>> In the fink project, the llvm-gcc42 package is kept only to provide a
>> compiler which fully supports traditional mode cpp for use with the
>> legacy xmkf package.
>
> That's a bit overkill. fink should look into using tradcpp instead.
>
>> The fink llvm-gcc42 packaging also builds against
>> clang with the appropriate patching. As for when to discard the
>> llvm-gcc42 package entirely, the outer limit would seem to be whenever
>> Apple removes the legacy libstdc++ support and associated
>> compatibility unwinder from the system.
>
> libstdc++ does not exist on new platforms (eg: tvOS and watchOS). Projects
> should not be using libstdc++ any more and should have migrated by now
> (unless, of course, they need to support Snow Leopard users still). I
> wouldn't be surprised if the headers disappeared from a future SDK or had
> markup preventing them from being used with a deployment target of 10.7 or
> higher.
>
>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
