Re: Compiling ports in a post-9.0-RELEASE world
In our previous episode, Matthias Andree said: So far I've found clang surprisingly good in that it revealed a few quirks in my own software (in C) that GCC or ICC had silently accepted, and the static analyzer has a few rough edges, but I have found bugs in my own software, not in clang 2.8 so far, although I suspect that a few might linger there. How much changes for non-(GC)C ports? In other words, ports that directly use AS and LD to generate binaries, but might also link to C libraries outside of gcc's control. (I'm thinking about e.g. lang/fpc here) Issues like - Are there fundamental startup code (CSU) changes due to this in 9? - libraries that might need to be implicitely linked when linking against C code (like libgcc,c) - Do certain libc internal macros change (like __errno_location) - Do lowlevel details of stuff like TLS change? Of course I'll load up some RC or DP in a VM if necessary to find my own answers. But if somebody knows some details, it would help guestimating the effort. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling ports in a post-9.0-RELEASE world
On Fri, Mar 18, 2011 at 11:40:38AM +0100, Marco van de Voort wrote: In our previous episode, Matthias Andree said: So far I've found clang surprisingly good in that it revealed a few quirks in my own software (in C) that GCC or ICC had silently accepted, and the static analyzer has a few rough edges, but I have found bugs in my own software, not in clang 2.8 so far, although I suspect that a few might linger there. How much changes for non-(GC)C ports? In other words, ports that directly use AS and LD to generate binaries, but might also link to C libraries outside of gcc's control. (I'm thinking about e.g. lang/fpc here) Issues like - Are there fundamental startup code (CSU) changes due to this in 9? csu consists of two pieces. One, living in lib/csu, provides the system startup for activated image, and it is not compiler-depended in any way. The other part, implemented by crtbegin.o/crtend.o in gcc, is compiler-depended and arranges the ctr/dtr calls at proper time. - libraries that might need to be implicitely linked when linking against C code (like libgcc,c) libc is system library, it is compiler-agnostic and shall provide the same ABI regardless of the compiler. libgcc is compiler-depended, but clang claims to conform to gcc ABI there. - Do certain libc internal macros change (like __errno_location) Errno is part of libc, see above. - Do lowlevel details of stuff like TLS change? TLS is implemented according to ELF ABI (some sort of ABI, there). It is mostly implemented in rtld, and compiler just need to follow the ABI. Of course I'll load up some RC or DP in a VM if necessary to find my own answers. But if somebody knows some details, it would help guestimating the effort. It should be plug and play, modulo the bugs. pgp08T42Udd3D.pgp Description: PGP signature
Re: Compiling ports in a post-9.0-RELEASE world
Am 18.03.2011 15:17, schrieb Konstantin Tokarev: 17.03.2011, 20:33, Matthias Andreematthias.and...@gmx.de: Not necessarily. If it's a documented extension that you'd allowed (and even by sticking to the implicit gnu89 language default of GCC) then you'll hardly hear back anything else than invalid, works as documented. Note that Clang supports c89 and gnu89 modes[1] [1] http://clang.llvm.org/docs/UsersManual.html#c_modes With reservations, namely extensions not implemented yet, or intentionally unsupported extensions - and the list does not claim to be complete. BTW, please configure your software to not quote addresses. -- Matthias Andree ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling ports in a post-9.0-RELEASE world
16.03.2011, 11:33, Alberto Villa avi...@freebsd.org: On Wednesday 16 March 2011 09:15:07 Konstantin Tokarev wrote: From http://clang.llvm.org/docs/LanguageExtensions.html In addition to the language extensions listed here, Clang aims to support a broad range of GCC extensions. So GCC extensions may also be considered as missing features. gcc-isms also means bad code which is nonetheless supported by gcc In this case don't hesitate to file a bug against gcc :) -- Regards, Konstantin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling ports in a post-9.0-RELEASE world
17.03.2011, 15:39, Konstantin Tokarev annu...@yandex.ru: 16.03.2011, 11:33, Alberto Villa avi...@freebsd.org;: On Wednesday 16 March 2011 09:15:07 Konstantin Tokarev wrote: From http://clang.llvm.org/docs/LanguageExtensions.html In addition to the language extensions listed here, Clang aims to support a broad range of GCC extensions. So GCC extensions may also be considered as missing features. gcc-isms also means bad code which is nonetheless supported by gcc In this case don't hesitate to file a bug against gcc :) Let me elaborate my idea a bit. One may think that reporting bugs on GCC he supports development of technology that FreeBSD does not endorse [1]. I don't think so. 1) Latest versions of GCC are more standard-compliant than earlier ones, and bad written code tends to produce compilation errors with newer GCC. For example, I've seen lots of legacy code written for GCC 3.x but failing to compile with 4.x. 4.x branch is also being improved. 2) Active upstreams and Linux distributions try to make code compatible with latest and greatest GCC. So if newer version is fixed not to compile some kind of broken code, there will be big chances that upstreams will fix it themselves. 3) Projects with dead upstreams should be excluded from ports collection someday, unless maintainers are willing to do upstream job. Folks using this software will be able to build it using right GCC version which is known to compile this crap properly. And last but not least, GCC is still great compiler, despite of its drawbacks and licensing issues. [1] Bugs could be reported only for latest GCC version, i.e. 4.5.2, and 4.2.x will never get fixes. -- Regards, Konstantin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling ports in a post-9.0-RELEASE world
Am 12.03.2011 23:00, schrieb Doug Barton: Howdy, As many of you are no doubt already aware, much work has been undertaken to make clang the default compiler for the src tree starting with 9.0-RELEASE. It is not 100% certain that this change will be made, but it's looking more likely every day. This raises an interesting question for how to deal with compiling ports after 9.0 is released. So far there are 2 main ideas for how to deal with this: 1. Fix all ports to compile with both gcc 4.2 (for RELENG_[78]) and clang. 2. Adopt an official ports compiler, which would likely be one of the gcc versions from the ports tree itself, and update all ports to work with it. Both options have pros and cons, but rather than front-load the conversation about them I'd like to throw open the topic for discussion and see what people think about these options, and whether someone has a better idea. The question is how many ports will silently assume they're running under GCC, and how compatible clang is. So far I've found clang surprisingly good in that it revealed a few quirks in my own software (in C) that GCC or ICC had silently accepted, and the static analyzer has a few rough edges, but I have found bugs in my own software, not in clang 2.8 so far, although I suspect that a few might linger there. We have USE_GCC, currently often used to use a newer GCC version than what is in the base system, and I suppose this feature will remain there for a lng time. So my proposal is: 3. Stronly prefer (1), fix the ports. If the port can't be made to work with clang with reasonable effort, we have a fallback solution and can set USE_GCC until the port gets fixed (which the important ones probably will). Add support for USE_GCC=yes to set a sane default, f. i. 4.2+). For simpler upgrades, that makes the port GCC version agnostic but still states clang won't work. Rationale: NOT adopting a particular ports compiler is a unique chance to get upstream software more portable (on the assumption that the majority of portability patches will sooner or later travel and get integrated upstream) and possibly get a few bugs resolved. For C89-style software that I've seen, if it didn't compile with clang, the software was buggy, not clang lacking. I know things may be different with corner cases for C99 or C++, and surely some C++0x features will require GCC, as will Fortran, Java, and thereabouts. Best regards -- Matthias Andree ports committer ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling ports in a post-9.0-RELEASE world
Am 17.03.2011 14:07, schrieb Konstantin Tokarev: 17.03.2011, 15:39, Konstantin Tokarevannu...@yandex.ru: 16.03.2011, 11:33, Alberto Villaavi...@freebsd.org;: On Wednesday 16 March 2011 09:15:07 Konstantin Tokarev wrote: From http://clang.llvm.org/docs/LanguageExtensions.html In addition to the language extensions listed here, Clang aims to support a broad range of GCC extensions. So GCC extensions may also be considered as missing features. gcc-isms also means bad code which is nonetheless supported by gcc In this case don't hesitate to file a bug against gcc :) Not necessarily. If it's a documented extension that you'd allowed (and even by sticking to the implicit gnu89 language default of GCC) then you'll hardly hear back anything else than invalid, works as documented. Let me elaborate my idea a bit. One may think that reporting bugs on GCC he supports development of technology that FreeBSD does not endorse [1]. I don't think so. 1) Latest versions of GCC are more standard-compliant than earlier ones, and bad written code tends to produce compilation errors with newer GCC. For example, I've seen lots of legacy code written for GCC 3.x but failing to compile with 4.x. 4.x branch is also being improved. This is based on the implicit assumption that the code were to be compiled with -std=c99 -pedantic-errors [-Wall] or similar. The majority of upstream packages doesn't follow such a purity paradigm, but knowingly or unbeknownst use -std=gnu89, and often GNU libc, extensions. Documented extensions have NOT USUALLY gone away in newer GCC minor releases. 3) Projects with dead upstreams should be excluded from ports collection someday, unless maintainers are willing to do upstream job. Folks using That's a separate discussion under the deprecation campaign subject. Please discuss that there. -- Matthias Andree ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling ports in a post-9.0-RELEASE world
Am 16.03.2011 12:02, schrieb Ade Lovett: On Mar 16, 2011, at 05:45 , Konstantin Tokarev wrote: 16.03.2011, 13:33, Ade Lovetta...@freebsd.org: On Mar 16, 2011, at 04:39 , Anton Shterenlikht wrote: What will happen to ports in non-clang arches (sparc64, ia64) after 9.0R? With any luck, they will die a silent death and be pointed in the direction of NetBSD that likes to look after irrelevant architectures. i386/amd64 for primary use, arm/mips for embedded. Anything else is just ridiculous. What about Power Architecrure (formerly PowerPC)? It's widely used both for embedded and enterprise (pSeries, Blue Gene, etc.) Surprisingly enough, there is an _enormous_ difference between making FreeBSD/src run on a particular platform (which is pretty much self-contained), and then making FreeBSD (src+22,000 ports) run on a particular platform (which isn't). Let's take the embedded example at random (well, not so much, since we both brought it up). Forcibly define WITHOUT_X11 on those platforms -- that'll nuke a whole bunch of stuff. That's the low hanging fruit. In fact, it may well be easier to define ONLY_FOR_ARCHES?= i386 amd64 in bsd.port.mk and then _override_ it for those few ports, and dependencies, that actually make sense on an embedded system. With 9.0-RELEASE, as far as ports/packages go, we'll be back to trying to support 4 major releases (7.4, 8.2, 9.0)-STABLE, 9.1-CURRENT (or will it be 10.0), two fundamentally different compilers (between 7.x/8.x and 9.0), eleventy-billion ports, with perhaps 2 people in the entire universe wanting to run doxygen on a mips box. Enough is enough. To make a very clear point: We wouldn't be having this discussion if authors would write proper and portable code in general. Not make silent assumptions about data width. Use proper POSIX headers rather than guess endianness or type width from arch-dependent preprocessor macros. Forget about pre-SUSv3 systems, or at least pre-SUSV2. Don't second guess from high-level system feature, but query the actual low level feature, or hardcode type widths if we're talking about binary data layout (file systems, file formats, or wire protocols, for instance). I don't mean to offend anyone or this to be taken reproachful, but it's just an observation: I've seen so much code make implicit assumptions such as sizeof(long) == 4, endianness being little, OS being Linux, or if it's not i386 or alpha then foo and all that when in fact all the support such as inttypes.h or sys/endian.h for the few bytes that needed it had been in place when the code was newly written. I'm not asking about the reasons, but as an example: don't look at __i386__ if you need to know type widths and endianness. Getting this stuff shaken out and done right usually means not supporting one more platform per iteration but usually the whole lot. And it often also removes other system dependencies. Yes the releases * arches * compilers diversity is worrisome with expectations of lots of work, but the way to handle it is getting the code right. I expect that upstreams will be more attentive, too, as more core code might want to be ported to Android, for instance. And usually portable code is also better code in the sense that it is more robust and has fewer branches (or the branches are encapsulated in the magic under /usr/include). Pointing people to NetBSD and/or pkgsrc isn't helping anyone. If some arcane Java port fails on an architecture that's typically used for low-power, battery-powered, embedded stuff, so be it. But quite a lot of the console/infrastructure stuff can be fixed with little effort, and I'm not supporting artificial limitations. -- Matthias Andree ports committer ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling ports in a post-9.0-RELEASE world
16.03.2011, 02:27, Alberto Villa avi...@freebsd.org: On Tuesday 15 March 2011 19:20:40 Konstantin Tokarev wrote: 3. Fix Clang to compile more ports lots of problems are due to gcc-isms in software, so it's not always possible From http://clang.llvm.org/docs/LanguageExtensions.html In addition to the language extensions listed here, Clang aims to support a broad range of GCC extensions. So GCC extensions may also be considered as missing features. -- Regards, Konstantin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling ports in a post-9.0-RELEASE world
On Wednesday 16 March 2011 09:15:07 Konstantin Tokarev wrote: From http://clang.llvm.org/docs/LanguageExtensions.html In addition to the language extensions listed here, Clang aims to support a broad range of GCC extensions. So GCC extensions may also be considered as missing features. gcc-isms also means bad code which is nonetheless supported by gcc -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla A pipe gives a wise man time to think and a fool something to stick in his mouth. signature.asc Description: This is a digitally signed message part.
Re: Compiling ports in a post-9.0-RELEASE world
On Tue, Mar 15, 2011 at 09:20:40PM +0300, Konstantin Tokarev wrote: 13.03.2011, 01:00, Doug Barton do...@freebsd.org: Howdy, As many of you are no doubt already aware, much work has been undertaken to make clang the default compiler for the src tree starting with 9.0-RELEASE. It is not 100% certain that this change will be made, but it's looking more likely every day. This raises an interesting question for how to deal with compiling ports after 9.0 is released. So far there are 2 main ideas for how to deal with this: 1. Fix all ports to compile with both gcc 4.2 (for RELENG_[78]) and clang. 2. Adopt an official ports compiler, which would likely be one of the gcc versions from the ports tree itself, and update all ports to work with it. 3. Fix Clang to compile more ports Note that these 3 are not mutually exclusive. The clang developers have been very responsive on earlier bugs we found and they are usually fixed quickly, so I'm sure that if real bugs in clang are found they will be happy to hear about them. Fixing ports to work with both gcc and clang should also be a good target to reach for, but given the amount of ports this is unrealistic to be finished before 9.0 is released. There are a few PRs already in GNATS that generalize the compiler settings for ports that portmgr have been looking into, but more work is needed. The idea is to extend the USE_GCC framework to a USE_COMPILER (or similar) macro that can force a port to use gcc, clang or another compiler with a default compiler that easily can be flipped. I've also run a few full builds on the pointyhat cluster with clang as the default compiler, mostly to check for clang bugs and we'll do more rounds with the results posted here to get help with fixing individual ports. -erwin -- Erwin Lansing http://droso.org Prediction is very difficult especially about the futureer...@freebsd.org pgpYkgwWjZFsk.pgp Description: PGP signature
Re: Compiling ports in a post-9.0-RELEASE world
On Wed, Mar 16, 2011 at 10:19:48AM +0100, Erwin Lansing wrote: On Tue, Mar 15, 2011 at 09:20:40PM +0300, Konstantin Tokarev wrote: 13.03.2011, 01:00, Doug Barton do...@freebsd.org: Howdy, As many of you are no doubt already aware, much work has been undertaken to make clang the default compiler for the src tree starting with 9.0-RELEASE. It is not 100% certain that this change will be made, but it's looking more likely every day. This raises an interesting question for how to deal with compiling ports after 9.0 is released. So far there are 2 main ideas for how to deal with this: 1. Fix all ports to compile with both gcc 4.2 (for RELENG_[78]) and clang. 2. Adopt an official ports compiler, which would likely be one of the gcc versions from the ports tree itself, and update all ports to work with it. 3. Fix Clang to compile more ports Note that these 3 are not mutually exclusive. The clang developers have been very responsive on earlier bugs we found and they are usually fixed quickly, so I'm sure that if real bugs in clang are found they will be happy to hear about them. Fixing ports to work with both gcc and clang should also be a good target to reach for, but given the amount of ports this is unrealistic to be finished before 9.0 is released. What will happen to ports in non-clang arches (sparc64, ia64) after 9.0R? -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling ports in a post-9.0-RELEASE world
On Wed, Mar 16, 2011 at 09:39:38AM +, Anton Shterenlikht wrote: Note that these 3 are not mutually exclusive. The clang developers have been very responsive on earlier bugs we found and they are usually fixed quickly, so I'm sure that if real bugs in clang are found they will be happy to hear about them. Fixing ports to work with both gcc and clang should also be a good target to reach for, but given the amount of ports this is unrealistic to be finished before 9.0 is released. What will happen to ports in non-clang arches (sparc64, ia64) after 9.0R? Good point I forgot to mention, the default compiler will of course depend on architecture and FreeBSD version. We'll have to see how many ports will build with clang whether we want to change the default ports compiler to clang, but even if we do we'll have to stay with gcc for non-clang archs and older FreeBSD versions. -erwin -- Erwin Lansing (o_ _o) http://droso.org Ceterum censeo \\\_\ /_/// Carthaginem esse delendam) (er...@lansing.dk pgpbDbF2aIS5d.pgp Description: PGP signature
Re: Compiling ports in a post-9.0-RELEASE world
On Mar 16, 2011, at 04:39 , Anton Shterenlikht wrote: What will happen to ports in non-clang arches (sparc64, ia64) after 9.0R? With any luck, they will die a silent death and be pointed in the direction of NetBSD that likes to look after irrelevant architectures. i386/amd64 for primary use, arm/mips for embedded. Anything else is just ridiculous. -aDe ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling ports in a post-9.0-RELEASE world
16.03.2011, 13:33, Ade Lovett a...@freebsd.org: On Mar 16, 2011, at 04:39 , Anton Shterenlikht wrote: What will happen to ports in non-clang arches (sparc64, ia64) after 9.0R? With any luck, they will die a silent death and be pointed in the direction of NetBSD that likes to look after irrelevant architectures. i386/amd64 for primary use, arm/mips for embedded. Anything else is just ridiculous. What about Power Architecrure (formerly PowerPC)? It's widely used both for embedded and enterprise (pSeries, Blue Gene, etc.) -- Regards, Konstantin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling ports in a post-9.0-RELEASE world
On Mar 16, 2011, at 05:45 , Konstantin Tokarev wrote: 16.03.2011, 13:33, Ade Lovett a...@freebsd.org: On Mar 16, 2011, at 04:39 , Anton Shterenlikht wrote: What will happen to ports in non-clang arches (sparc64, ia64) after 9.0R? With any luck, they will die a silent death and be pointed in the direction of NetBSD that likes to look after irrelevant architectures. i386/amd64 for primary use, arm/mips for embedded. Anything else is just ridiculous. What about Power Architecrure (formerly PowerPC)? It's widely used both for embedded and enterprise (pSeries, Blue Gene, etc.) Surprisingly enough, there is an _enormous_ difference between making FreeBSD/src run on a particular platform (which is pretty much self-contained), and then making FreeBSD (src+22,000 ports) run on a particular platform (which isn't). Let's take the embedded example at random (well, not so much, since we both brought it up). Forcibly define WITHOUT_X11 on those platforms -- that'll nuke a whole bunch of stuff. That's the low hanging fruit. In fact, it may well be easier to define ONLY_FOR_ARCHES?= i386 amd64 in bsd.port.mk and then _override_ it for those few ports, and dependencies, that actually make sense on an embedded system. With 9.0-RELEASE, as far as ports/packages go, we'll be back to trying to support 4 major releases (7.4, 8.2, 9.0)-STABLE, 9.1-CURRENT (or will it be 10.0), two fundamentally different compilers (between 7.x/8.x and 9.0), eleventy-billion ports, with perhaps 2 people in the entire universe wanting to run doxygen on a mips box. Enough is enough. -aDe ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling ports in a post-9.0-RELEASE world
On Wed, Mar 16, 2011 at 06:02:55AM -0500, Ade Lovett wrote: On Mar 16, 2011, at 05:45 , Konstantin Tokarev wrote: 16.03.2011, 13:33, Ade Lovett a...@freebsd.org: On Mar 16, 2011, at 04:39 , Anton Shterenlikht wrote: What will happen to ports in non-clang arches (sparc64, ia64) after 9.0R? With any luck, they will die a silent death and be pointed in the direction of NetBSD that likes to look after irrelevant architectures. i386/amd64 for primary use, arm/mips for embedded. Anything else is just ridiculous. What about Power Architecrure (formerly PowerPC)? It's widely used both for embedded and enterprise (pSeries, Blue Gene, etc.) Surprisingly enough, there is an _enormous_ difference between making FreeBSD/src run on a particular platform (which is pretty much self-contained), and then making FreeBSD (src+22,000 ports) run on a particular platform (which isn't). Let's take the embedded example at random (well, not so much, since we both brought it up). Forcibly define WITHOUT_X11 on those platforms -- that'll nuke a whole bunch of stuff. That's the low hanging fruit. In fact, it may well be easier to define ONLY_FOR_ARCHES?= i386 amd64 in bsd.port.mk and then _override_ it for those few ports, and dependencies, that actually make sense on an embedded system. With 9.0-RELEASE, as far as ports/packages go, we'll be back to trying to support 4 major releases (7.4, 8.2, 9.0)-STABLE, 9.1-CURRENT (or will it be 10.0), two fundamentally different compilers (between 7.x/8.x and 9.0), eleventy-billion ports, with perhaps 2 people in the entire universe wanting to run doxygen on a mips box. Enough is enough. -aDe Is this your personal view? Or the view of the Ports Management Team? Are you, or the Ports Management Team, going to actively encourage silent death? -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling ports in a post-9.0-RELEASE world
On 03/16/2011 02:39 AM, Anton Shterenlikht wrote: On Wed, Mar 16, 2011 at 10:19:48AM +0100, Erwin Lansing wrote: On Tue, Mar 15, 2011 at 09:20:40PM +0300, Konstantin Tokarev wrote: 13.03.2011, 01:00, Doug Bartondo...@freebsd.org: Howdy, As many of you are no doubt already aware, much work has been undertaken to make clang the default compiler for the src tree starting with 9.0-RELEASE. It is not 100% certain that this change will be made, but it's looking more likely every day. This raises an interesting question for how to deal with compiling ports after 9.0 is released. So far there are 2 main ideas for how to deal with this: 1. Fix all ports to compile with both gcc 4.2 (for RELENG_[78]) and clang. 2. Adopt an official ports compiler, which would likely be one of the gcc versions from the ports tree itself, and update all ports to work with it. 3. Fix Clang to compile more ports Note that these 3 are not mutually exclusive. The clang developers have been very responsive on earlier bugs we found and they are usually fixed quickly, so I'm sure that if real bugs in clang are found they will be happy to hear about them. Fixing ports to work with both gcc and clang should also be a good target to reach for, but given the amount of ports this is unrealistic to be finished before 9.0 is released. What will happen to ports in non-clang arches (sparc64, ia64) after 9.0R? This is a good reason that number 2 above is likely a necessary step regardless of what other work is done. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling ports in a post-9.0-RELEASE world
13.03.2011, 01:00, Doug Barton do...@freebsd.org: Howdy, As many of you are no doubt already aware, much work has been undertaken to make clang the default compiler for the src tree starting with 9.0-RELEASE. It is not 100% certain that this change will be made, but it's looking more likely every day. This raises an interesting question for how to deal with compiling ports after 9.0 is released. So far there are 2 main ideas for how to deal with this: 1. Fix all ports to compile with both gcc 4.2 (for RELENG_[78]) and clang. 2. Adopt an official ports compiler, which would likely be one of the gcc versions from the ports tree itself, and update all ports to work with it. 3. Fix Clang to compile more ports My $0.02 -- Regards, Konstantin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling ports in a post-9.0-RELEASE world
On Tue 15 Mar 2011 at 11:20:40 PDT Konstantin Tokarev wrote: 3. Fix Clang to compile more ports That would be my vote too, but we should probably focus on solutions the ports team can control. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling ports in a post-9.0-RELEASE world
15.03.2011, 21:32, Charlie Kester corky1...@comcast.net: On Tue 15 Mar 2011 at 11:20:40 PDT Konstantin Tokarev wrote: 3. Fix Clang to compile more ports That would be my vote too, but we should probably focus on solutions the ports team can control. You can post bug reports to Clang team. maybe some of them will be solved before the release of 9.0 -- Regards, Konstantin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling ports in a post-9.0-RELEASE world
On Tue 15 Mar 2011 at 11:39:28 PDT Konstantin Tokarev wrote: 15.03.2011, 21:32, Charlie Kester corky1...@comcast.net: On Tue 15 Mar 2011 at 11:20:40 PDT Konstantin Tokarev wrote: 3. Fix Clang to compile more ports That would be my vote too, but we should probably focus on solutions the ports team can control. You can post bug reports to Clang team. maybe some of them will be solved before the release of 9.0 Of course, we should definitely do that. But ports team should have a plan in place, in case those PR's aren't resolved in time. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling ports in a post-9.0-RELEASE world
On Mar 15, 2011, at 14:14 , Charlie Kester wrote: Of course, we should definitely do that. But ports team should have a plan in place, in case those PR's aren't resolved in time. A single, really small boot/livefs/install with no packages (half-smiley) In all seriousness, with a change of this complexity, in order to get more eyes on the prize, some form of slightly-hardened functional snapshot would be useful to load up on virtualbox/vmware/whatever slaves, install the necessary components for a ports-tinderbox client system and then start building. On personal machines (not the package building clusters), package building and testing can take a non-trivial amount of time to run, so everyone interested in participating running from the same snapshot (base, dict, proflibs, src/sys [and, for amd64, lib32] sets are all that's needed to run a ports-tinderbox) will considerably ease the situation. -aDe ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling ports in a post-9.0-RELEASE world
On Tuesday 15 March 2011 19:20:40 Konstantin Tokarev wrote: 3. Fix Clang to compile more ports lots of problems are due to gcc-isms in software, so it's not always possible -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla The yankees, son, are up north. The damnyankees are down here. signature.asc Description: This is a digitally signed message part.
Re: Compiling ports in a post-9.0-RELEASE world
On Sat, Mar 12, 2011 at 02:00:33PM -0800, Doug Barton wrote: 1. Fix all ports to compile with both gcc 4.2 (for RELENG_[78]) and clang. I do not believe we have enough time before 9.0R to accomplish this; especially as I understand that there is pressure within the src committer community to simply throw the switch. 2. Adopt an official ports compiler, which would likely be one of the gcc versions from the ports tree itself, and update all ports to work with it. I think this is our only reasonable alternative medium-term. Let me add on to this discussion the attempts to do this so far. (Note: I have not worked on any of them; this is all just FYI). PR ports/155408 [PATCH] add support for USE_GCC_BUILD to bsd.port.mk IMHO, necessary but insufficient. http://wiki.freebsd.org/PortsAndClang A status report on a package run vs. the clang compiler. Some of the data may be stale; updates are welcome. This is probably the best place to start updating data. fwiw, it includes a link to patches to not only various ports, but also the infrastructure: http://rainbow-runner.nl/clang/patches/ http://wiki.freebsd.org/SOC2010AndriusMorkunas This was a Google Summer of Code project: making ports work with clang. I do not know the status of this project. I hope that someone will update the wiki with the latest status on the latter two projects. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling ports in a post-9.0-RELEASE world
On Sat, Mar 12, 2011 at 02:00:33PM -0800, Doug Barton wrote: Howdy, As many of you are no doubt already aware, much work has been undertaken to make clang the default compiler for the src tree starting with 9.0-RELEASE. It is not 100% certain that this change will be made, but it's looking more likely every day. This raises an interesting question for how to deal with compiling ports after 9.0 is released. So far there are 2 main ideas for how to deal with this: 1. Fix all ports to compile with both gcc 4.2 (for RELENG_[78]) and clang. This perhaps would be bst, but...(see below) 2. Adopt an official ports compiler, which would likely be one of the gcc versions from the ports tree itself, and update all ports to work with it. Since most of the software in the ports tree tends to be quite linux or gcc centric I think 2 is the only viable option. BTW I'd suggest a variation to 2. I think some option like CLANG_SAFE or USE_CLANG(just saying, perhaps a better name can be found) should be added to the infrastructure so, on 9.x and newer systems, maintainer can sign that their port does build using the system compiler. Obviously for ports having dependencies, especially libraries, some extra testing should be performed to make sure depending ports, which could use a different compiler, link correctly. -- Guido Falsi m...@madpilot.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling ports in a post-9.0-RELEASE world
Hi, I think some option like CLANG_SAFE or USE_CLANG (just saying, perhaps a better name can be found) should be added [...] I also think that it would be very useful to go the same route as with MAKE_JOBS, i.e., ports can opt in, and in the long run opt out, of being build with clang. In my opinion, that should also include a variable like FORCE_MAKE_JOBS, say FORCE_CLANG, that makes all undecided ports (i.e., those neither CLANG_SAFE nor CLANG_UNSAFE) chose clang. Best, Klaus ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
