On 2022/04/14 08:03, Mikhail wrote: > Hello, this is proposal to add net/epic5 irc client to the ports tree, > currently we have net/epic4, but it's previous generation of the client, > all development activity and users long ago had moved to epic5. > > The client distinguishes itself by extremely high ability to customize > IRC experience with ircII scripting language. > > EPIC5 also has gained pledge/unveil support in master branch recently, > the patches are included in current port, because next software update > won't be released soon. > > More info about the software and pledge/unveil usage is in pkg/README. > > The port will be maintained by me and Joey (cc'ed). > > Comments, suggestions and testing are welcome.
Date: Fri, 8 Apr 2022 20:41:26 +0100 From: Stuart Henderson <[email protected]> To: Mikhail <[email protected]> Cc: Christian Weisgerber <[email protected]> Subject: Re: Ports tree close to lock Message-ID: <[email protected]> References: <[email protected]> <YlBr2JDjVsSTiDSS@raspberrypi> <1800a8f2150.2869.545c230b3f27d53b49609e7db7068...@spacehopper.org> <[email protected]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <[email protected]> On 2022/04/08 22:14, Mikhail wrote: > On Fri, Apr 08, 2022 at 08:03:14PM +0100, Stuart Henderson wrote: > > It's too late for 7.1 release. > > > > Re: the -O2 issue, does setting -std=c89 fix the problem? > > I think epic developers won't take the risk, the software has very old > history and we didn't receive any random crashes reports while being > simply with '-O' (epic4 and epic5 are still actively maintained, all > efforts are on the later, though). > > I've plans to submit net/epic5 port, because it has gained pledge/unveil > support, does -O will be considered as an issue by committers? - don't set MODPY_MAJOR_VERSION - my previous comments about the CFLAGS handing stand: # You must not try to compile epic with "gcc -O2" because -O2 will # generate bad code that leads to random crashes. When you use -O2, gcc # assumes the source is conformant to ISO C99's requirements about # alias-safety, and EPIC, being a C90 program, does not conform, so the # result is undefined behavior (which means it crashes randomly.) CFLAGS:= ${CFLAGS:C/-O2/-O/g} --snip-- My thinking is that, if the code has behaviour which is considered undefined by the C standard assumed by the compiler, no level of optimization is safe. Maybe now you get lucky and -O works (on whichever architecture you've tested) but I don't think it's reasonable to assume that this is the case everywhere, or will be the case following compiler updates. (Of course on many OpenBSD architectures the relevant compiler is not GCC anyway). --snip-- and your proposal doesn't work if the user builds from ports with CFLAGS=-O3
