Re: ports: clang: error: unsupported option '-dumpspecs'
-dumpspecs is a gcc internal thing that clang will never support (it doesnt use specs). It's wrong for ports to mess with the internals of the compiler and this should be fixed in a clean way. Ie. we have to replace the -dumpspec | grep something with a saner check. On Wed, Dec 14, 2011 at 08:07:43PM +0100, O. Hartmann wrote: > Since a couple of days now I see this happen on FreeBSD > 10.0-CURRENT/amd64 (CLANG) (most recent buildworld and potstree) and > also on FreeBSD 9.0-RC[2|3]/amd64 (also CLANG built, most recent portstree): > > Building new INDEX files... DESCRIBE.7 INDEX-8 not provided by portsnap > server; INDEX-7 not being generated. > done. > ===>>> Gathering distinfo list for installed ports > > ===>>> Starting check of installed ports for available updates > clang: error: unsupported option '-dumpspecs' > clang: error: no input files > > ===>>> All ports are up to date > > > Regards, > Oliver > ___ 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"
[ANNOUNCE]: clang compiling ports
Hi! Flz@ just run an exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-9-exp-latest/ A lot of these failures are trivial to fix (ie. not respecting CC setting, etc.) and prevent a lot of other ports from building. It would be great if you could skim over the list to see if some of the ports you maintain are broken and possibly try to fix them. A small introduction into the Clang+Ports can be read at: http://wiki.freebsd.org/PortsAndClang. Please focus on the biggest offenders (ie. ports that prevent the most other ports from building). Thank you for helping us! Roman Divacky pgpFKX1RRwGhM.pgp Description: PGP signature
[ANNOUNCE]: clang compiling ports, take 2
Hi! Flz@ just run another exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/ Since the last run we've managed to fix the biggest offenders but that uncovered others that need fixing. The "Reason" column was extended and now shows "assumes_gcc" which is the lowest hanging fruit :) A lot of these failures are trivial to fix (ie. assumes_gcc reason) and prevent a lot of other ports from building. It would be great if you could skim over the list to see if some of the ports you maintain are broken and possibly try to fix them. A small introduction into the Clang+Ports can be read at: http://wiki.freebsd.org/PortsAndClang. Please focus on the biggest offenders (ie. ports that prevent the most other ports from building). Thank you for helping us again! Roman Divacky pgp0lXrHcNdQ3.pgp Description: PGP signature
Re: [patch] pkg_delete(1) speedup
On Wed, Mar 26, 2008 at 05:18:29PM +0100, Pav Lucistnik wrote: > You might have noticed a thread on the mailing list called "ports system > woes". The submitter pointed out an inefficiency in pkg_delete routine, > that parses the whole /var/db/pkg over and over again for every > dependency of a package being removed. > > Attached is a patch by rdivacky that implements the idea of looking up > all the values in a single pass over /var/db/pkg content. I hacked a slightly better patch that coveres a part of pkg_add too.. please review/test on: www.vlakno.cz/~rdivacky/pkg_tools.patch comments, benchmarks more than welcome! roman pgp8r5GxqeDEV.pgp Description: PGP signature
Re: [patch] pkg_delete(1) speedup
On Thu, Mar 27, 2008 at 07:18:49PM -0700, Doug Barton wrote: > Roman Divacky wrote: > >On Wed, Mar 26, 2008 at 05:18:29PM +0100, Pav Lucistnik wrote: > >>You might have noticed a thread on the mailing list called "ports system > >>woes". The submitter pointed out an inefficiency in pkg_delete routine, > >>that parses the whole /var/db/pkg over and over again for every > >>dependency of a package being removed. > >> > >>Attached is a patch by rdivacky that implements the idea of looking up > >>all the values in a single pass over /var/db/pkg content. > > > >I hacked a slightly better patch that coveres a part of pkg_add too.. > > > >please review/test on: > > > > www.vlakno.cz/~rdivacky/pkg_tools.patch > > > >comments, benchmarks more than welcome! > > A) this is massively cool stuff, thanks for taking this on. :) > B) you should probably do two versions of the patch, one with > style(9)-only changes, and one without. The former makes it much easier > to review the actual changes, and would speed your path to getting it in > the tree. there are 3 style-only changes in the patch.. 3 lines.. I didnt consider to make two separate patches for testing/review :) I'll do it if you insist thnx! roman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] pkg_delete(1) speedup
On Sun, Mar 30, 2008 at 11:49:46PM -0700, [EMAIL PROTECTED] wrote: > > > > You might have noticed a thread on the mailing list called "ports system > > > woes". The submitter pointed out an inefficiency in pkg_delete routine, > > > that parses the whole /var/db/pkg over and over again for every > > > dependency of a package being removed. > > > > > > Attached is a patch by rdivacky that implements the idea of looking up > > > all the values in a single pass over /var/db/pkg content. > > > > I hacked a slightly better patch that coveres a part of pkg_add too.. > > > > please review/test on: > > > > www.vlakno.cz/~rdivacky/pkg_tools.patch > > > > comments, benchmarks more than welcome! > > All right, I've been gone to the Real World for a while, but I returned %-) > > First, allow me to note that it's rather impressing to see the level of > interest and responses my half-baked email about my little digs into pkg_* > tools produced. Before I even finished thinking whether I will have enough > time to fix the tools proper, patches started appearing on the horizon (the > same day, practically)! This is quite reassuring, as it shows that > developers still care about code and algorithm quality, even if things work > OK on modern hardware (just lack of developer time, that's all, I suppose). > For that I'm grateful -- way to go :) you provided excellent analysis... that couldnt go unpunished ;) > Now, here are the same tests on the same hardware, but > with pkg_tools.patch applied: I updated the patch in place several times.. please make sure you have the latest version or bad things can happen :( I'll respond to the rest of the mail later... thnx for caring about this! roman > [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# make > [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# time make install > > ===> Generating temporary packing list > ===> Checking if x11/rxvt-unicode already installed > load: 0.53 cmd: pkg_info 25799 [biord] 0.06u 0.07s 0% 1532k > /usr/bin/install -c -o root -g wheel -d /usr/local/bin > > ===> Documentation installed in /usr/local/share/doc/rxvt-unicode. > ===> Compressing manual pages for rxvt-unicode-9.02_1 > ===> Registering installation for rxvt-unicode-9.02_1 > load: 0.29 cmd: sed 26266 [biord] 0.00u 0.00s 0% 728k > load: 0.27 cmd: sh 26568 [runnable] 0.00u 0.00s 0% 164k > load: 0.24 cmd: sh 25951 [biord] 0.14u 0.09s 0% 1228k > load: 0.22 cmd: grep 27026 [runnable] 0.00u 0.00s 0% 256k > ===> SECURITY REPORT: >This port has installed the following binaries which execute with > > real1m13.885s > user0m3.903s > sys 0m4.870s > [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# s; sleep 300 && echo -e > "\n" > > > [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# time pkg_delete > /var/db/pkg/rxvt-unicode-9.02_1/ > load: 0.36 cmd: pkg_delete 27480 [biord] 0.35u 0.40s 1% 972k > > real0m37.218s > user0m0.448s > sys 0m0.509s > [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# make reinstall > /dev/null; > sync > [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# time pkg_delete > /var/db/pkg/rxvt-unicode-9.02_1/ > > real0m20.261s > user0m0.349s > sys 0m0.476s > [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# > > So, the time drops from over 7 minutes to 20 seconds -- sweet! :) > > Notice pkg_info in ^T output during "Checking if x11/rxvt-unicode already > installed" phase. This one takes awhile. The actual command is: > `/usr/sbin/pkg_info -q -O x11/rxvt-unicode` > real0m37.697s > user0m0.125s > sys 0m0.360s > > find_pkgs_by_origin() in info/perform.c uses the same matchbyorigin() > in lib/match.c. What's interesting here, however, is that simple > `time grep ORIGIN /var/db/pkg/*/+CONTENTS` takes ~7 sec (XXX re-test on > that same notebook XXX), while find_pkgs_by_origin() incarnation of > practically the same functionality takes over 30 sec. > > To my eye, it doesn't look like matchbyorigin() could be re-implemented > to be faster with little effort, but could somebody have a quick look > as well? Would doing mmap() instead of scanning file line-by-line be > any faster? (though I'm not saying it's a great idea) > > BTW, I have a feeling that the "Registering installation" should be made > more verbose. It takes more time that anything else now, and one's left > to wonder what exactly is going on (seems like quite a few different > things). > > Also, I found that during the "Checking if <*> already installed" step, > 'mtree' (XXX find out exact command here XXX) is called (from bsd.port.mk?), > which can be skipped by setting NO_MTREE. What effect does [not] calling > mtree have? > > And to conclude, here we have a benchmark from my faster machine (Core2 > Dual 2.72GHz, 2G RAM, MK2018GAS 4200RPM HDD with 2M buffer), > BEFORE patch was applied: > > [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# time make install > /dev/null > real0m23.097s
Re: net/skype, linux_base-fc6 and the missing linux-alsa-lib...
> Note: almost all linuxolator changes where merged from 8-CURRENT to > 7-STABLE. But I'm not sure if the default compat.linux.osrelease is > ever changed to 7.x. I am against ever switching to 2.6 on default in 7.x ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [HEADSUP] FYI: patch to ports that do not build with clang has been committed
Can we arrange exp builds with FORCE_BASE_CC_FOR_TESTING=clang that will report all ports with USE_GCC=* but build with clang? Lets say every three months or so? On Tue, Oct 09, 2012 at 07:45:23PM -0500, Mark Linimon wrote: > The commit mail hasn't gone through yet, so I guess I need to post this > first and reference the commit mail later. > > Sometime in the near future, the default CC on -current will be switched > to clang. The patch I have committed is a workaround -- an interim measure -- > to get ready for this transition. > > I have made changes to ports/Mk/bsd.gcc.mk that allow the addition of > "USE_GCC=any" to a port's Makefile, and then committed that change to > various ports. In most (but not all!) cases this will tell the port > "build with gcc instead of clang" (*) . > > For those users with CC installed as gcc (including -stable), this > patch should have no effect. Variations of combinations have been > heavily tested on pointyhat-west. If there are any regressions, please > contact me. > > You can see the difference in the errorlogs here: > > With USE_GCC=any: > > > http://pointyhat-west.isc.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp-clang.20121007231359.pointyhat-west/index-category.html > > Without USE_GCC=any: > > > http://pointyhat-west.isc.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp-clang.20121005165436.pointyhat-west/index-category.html > > While the absolute number of errors is not that much different, that > is a false indication: over 2500 more packages are built "with" than > "without". > > For those who wish to build *only* with clang, and thus defeat the > workaround, simply set FORCE_BASE_CC_FOR_TESTING=anything, either > in the Makefile line, or, if you are adventurous, in your /etc/make.conf. > We appreciate all the testing that we can get (it is too much for any > small group of people, much less one person.) > > In the long run, I would like to see as many ports built natively with > clang as possible, and I appreciate the work that people have been doing > to move us towards that goal. However, once the switch is made, it > would have been a burden to everyone tracking -current to have suddenly > found themselves "enlisted" in that effort :-) So, for the medium-term, > this workaround should reduce the POLA violation. > > *Note* that due to the high number (over a thousand!) ports that do not > build with clang, I arbitrarily decided to apply the workaround only to > "ports that block 2 or more other ports from building" union "important > ports". This does not mean that the workaround shouldn't be applied to > other ports that are too hard to fix. > > This is part 1 of a set of patches that are being proposed to deal with > the switchover. As I merge and test them some more, I will put them out > for further review. > > Thanks. > > mcl > > * several ports are very, very, clever, and detect clang anyways; others > build with gcc if CC is unset, but don't with CC=gcc. These ports are > broken, and need to be fixed as we continue the process of switching over. > ___ > freebsd-curr...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ 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: Printing with Acrobat Reader
> Acroread will use linux system calls to start the shell. This results > in the linux shell (/compat/linux/bin/sh) to start (linuxulator > directory prefixing). The linux shell will use the same linuxulator > directory prefixing to start /compat/linux/usr/bin/lpr. So we're in > the same situation like with Acroread. So when you play around with it > also try to not specify a path to the lpr call and tell us which one > works. this is not entirely true (or I just read it wrong). it works like this any binary (fbsd or linux) can run any binary (fbsd or linux). its just that when linux binary wants to run "xyz" it searches /compat/linux first and then falls back to / just a clarification ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Looking for speed increases in "make index" and pkg_version for ports
On Mon, May 28, 2007 at 11:34:24AM -0500, Stephen Montgomery-Smith wrote: > Jeremy Chadwick wrote: > >On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith wrote: > >> I have been thinking a lot about looking for speed increases for "make > >> index" and pkg_version and things like that. So for example, in > >> pkg_version, it calls "make -V PKGNAME" for every installed package. Now > >> "make -V PKGNAME" should be a speedy operation, but the make has to load > >> in and analyze bsd.port.mk, a quite complicated file with about 200,000 > >> characters in it, when all it is needing to do is to figure out the > >> value of the variable PKGNAME. > > > >I have a related question, pertaining to "make all-depends-list" and the > >utter atrocity that is the make variable ALL-DEPENDS-LIST. If you don't > >know what it is, look for ^ALL-DEPENDS-LIST around line 5175, in > >bsd.ports.mk. > > I posted this to [EMAIL PROTECTED], but now I am realizing that it is > [EMAIL PROTECTED] that gets more responses. Anyway, here is a > multithreaded program "all-depends-list" that can get you double the > speed on dual processor systems, and even some small speed gains on > single processor systems. E.g. > > all-depends-list /usr/ports/x11/xorg > > http://www.math.missouri.edu/~stephen/all-depends-list.c btw.. stehpen, when are you getting a commit bit? :) I certainly hope that soon enough ;) roman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Moving to a more recent linux base, when?
> If you find a glibc-2.4 for FC4 we can import it somehow. If you no we cant. glibc-2.4 requires 2.6 kernel. ie. its the same operation as switching to newer FC > don't, we need to wait for the possibility to go to FC^ or newer. But > as from FC5 on, we need 2.6.x emulation for the linuxulator. This will > only be available in 7.x with x >= 1 (there's some support now, but it > is not finished), and only if activated by the user. So by default we > can not install FC6+ on 7.x (I doubt we will change the linuxulator > default to 2.6.x in the 7.x-timeframe). let me clarify things a little. the 2.6 support in 7-current is good enough. I am not aware of panics and the only "does not work because of 2.6" program I know is java which I have sent a patch to kib@ to commit it (so it should be in before 7.0R) yet, 7.x wont ship 2.6 emulation on default so any newer FC is out of question. otoh I'd like to switch 2.6 emulation on default right after 7.0R is released in 8-current. to uncover new bugs and test stuff etc. hopefully I can also get someone (kib? netchild?) to commit most of the stuff I did over this summer (epoll is ready, *at will hopefully settle soon, some minor fixes can be commited with just a little discussion etc.) based on the results from the "2.6 on default" testing in 8-current we'll see if we can ship 8.0R with 2.6 on defaul (my personal guess is yes we can)2 my view of things... roman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Moving to a more recent linux base, when?
On Thu, Aug 23, 2007 at 02:46:39PM +0800, Thomas Zander wrote: > Hi, > > recently I had a look at the upcoming version of the PCB layout tool > eagle, in beta test at the moment. I am currently maintaining both the > international (cad/linux-eagle) and german ports of this tool. > This new beta version however refuses to run as it depends on > glibc-2.4 while our linux_base-fc4 ships glibc 2.3.6. > Do we have a roadmap or an estimated timeframe as to when a more > recent linux_base and their extra packages (linux-xorg and such) > becomes standard for the ports tree? first we have to have 2.6 emulation on default, then we can switch to default linux-base-fc6. I plan to do the switch to 2.6 emulation on default when 7.0R is shipped. roman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: The scandalous status of linux-flashplugin9
> > There was a report on -current a while ago that a preliminary patch > > to fix the non-threadsafeness of mmap(2) MAP_FIXED also makes flash9 work, > > > > http://lists.freebsd.org/pipermail/freebsd-current/2007-August/075968.html I wrote that and I was wrong... it doesnt seem to fix the flash9 problem for me. > > a fix for that seems to have been committed (kib 2007-08-20) and also > > mfc'd to RELENG_6 by now (kib 2007-09-09), so, can anyone running either > > verify that flash9 still crashes for them? > > Ok I now have a sucess story for RELENG_7 using linux-base-fc4 > (hi wallshot! :) - he couldnt get it to work with linux-base-f7), and > I myself (he tested too) couldnt get it working by merging the RELENG_6 > commit to 6.2, or by testing a RELENG_6 kernel and linux.ko on 6.2 userland. > So it looks like you need 7, and there's still work to be done for the > linux 2.6 emulation there also. I dont understand what you say.. you have working flash9 on RELENG_7/fc4? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: The scandalous status of linux-flashplugin9
On Thu, Oct 18, 2007 at 07:02:47PM -0700, Zephiris wrote: > Sam Fourman Jr. wrote: > > > > I too am confused, if you have flash 9 working in firefox on RELENG_7 > > please give us a detailed how to there are just a TON of people > > looking for this. I have 5 systems I would test it out on right now, 2 > > of them are teenager computers so they would get a workout on youtube > > , among other sites that require flash 8 :) > > > > Sam Fourman Jr. > > I saw this floating around before, and tried it. It "works" with Flash9 on > RELENG_7, but lots of things will still crash it. Back on the > freebsd-multimedia mailing from Feb, Michael Nottebrock <[EMAIL PROTECTED]> > (I don't want to take credit or anything) noticed libflashsupport.so > helped to some degree. I have to run Gentoo on /compat/linux (am I the > only one for which Nvidia linux drivers won't do anything with FC4 X11 > libraries?), but it's the same with the binary libflashsupport.so posted > ([1], it goes into /compat/linux/usr/lib), and compiled according to > instructions from the Adobe Beta site[2]. > > It's good enough to play many flash videos, it doesn't look like many games > will work, or that things that use 'streaming video' will work, either. > > I'm not quite sure why it's crashing. Since the source code is available > for this[3], perhaps someone better versed with internal details of > FreeBSD and in particular the Linux compatibility mode can take an > examination of this sort of thing so we might have a chance at a flash9 > that will, say, actually work with YouTube (although gnash does a fine job > on that for now). this is a nice information by a chance can you try to recompile the flashsupport.c with gcc 4.0.3 as they suggest in the source code? you never know with gcc ;) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Which "linux emulation" works with which programs or the inverse?
on the state of flash9 in linuxulator... I tried to debug it but it's (firefox+flash9) a huge program that generates like 1.5 million of lines of trace. I spend several hours staring at that but didn't find anything obvious... I would be more than happy if someone proved I am stupid and I overlooked something trivial :) now the flash9 work is mostly stalled (on my side) as I have some personal life issues + I am clueless about how to crack the flash9 nut. I guess once dtrace is imported to FreeBSD I'll be curious enough to try it on the flash9 problem.. thats how it is :( roman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 32-bit powerpc system-clang based builds of devel/llvm40 and devel/llvm50: fails via "Host compiler appears to require libatomic, but cannot find it"
The cmake test just tries to compile:
#include
std::atomic x;
int main() {
return x;
}
What happens if you try to compile this small code with your host compiler?
Roman
On Tue, Dec 05, 2017 at 10:42:49AM -0800, Mark Millard wrote:
> [I experiment with system-clang based
> buildworld and/or buildkernel based
> TARGET_ARCH=powerpc64 and
> TARGET_ARCH=powerpc environments.]
>
> For TARGET_ARCH=powerpc devel/llvm40 and
> devel/llvm50 get failure reports like:
>
> -- Looking for __atomic_load_8 in atomic - not found
> CMake Error at cmake/modules/CheckAtomic.cmake:74 (message):
> Host compiler appears to require libatomic, but cannot find it.
> Call Stack (most recent call first):
> cmake/config-ix.cmake:307 (include)
> CMakeLists.txt:582 (include)
>
>
> I had tried to avoid any need for 8-Byte atomics
> (among other things) by avoiding LIT, LLD, and LLDB:
>
> # more /usr/local/etc/poudriere.d/options/devel_llvm50/options
> # This file is auto-generated by 'make config'.
> # Options for llvm50-5.0.0_1
> _OPTIONS_READ=llvm50-5.0.0_1
> _FILE_COMPLETE_OPTIONS_LIST=CLANG DOCS EXTRAS LIT LLD LLDB
> OPTIONS_FILE_SET+=CLANG
> OPTIONS_FILE_SET+=DOCS
> OPTIONS_FILE_SET+=EXTRAS
> OPTIONS_FILE_UNSET+=LIT
> OPTIONS_FILE_UNSET+=LLD
> OPTIONS_FILE_UNSET+=LLDB
>
> # more /usr/local/etc/poudriere.d/options/devel_llvm40/options
> # This file is auto-generated by 'make config'.
> # Options for llvm40-4.0.1_1
> _OPTIONS_READ=llvm40-4.0.1_1
> _FILE_COMPLETE_OPTIONS_LIST=CLANG DOCS EXTRAS LIT LLD LLDB
> OPTIONS_FILE_SET+=CLANG
> OPTIONS_FILE_SET+=DOCS
> OPTIONS_FILE_SET+=EXTRAS
> OPTIONS_FILE_UNSET+=LIT
> OPTIONS_FILE_UNSET+=LLD
> OPTIONS_FILE_UNSET+=LLDB
>
> For clang-based buildworld avoiding such things
> prevents running into the 8-Byte atomics based
> build failures:
>
> WITH_LIBCPLUSPLUS=
> WITH_BINUTILS_BOOTSTRAP=
> WITH_ELFTOOLCHAIN_BOOTSTRAP=
> #WITH_CLANG_BOOTSTRAP=
> WITH_CLANG=
> WITH_CLANG_IS_CC=
> WITH_CLANG_FULL=
> WITH_CLANG_EXTRAS=
> WITH_LLD=
> # lldb requires missing atomic 8-byte operations for powerpc (non-64)
> WITHOUT_LLDB=
> #
> WITH_BOOT=
>
> (Note: buildkernel currently fails.)
>
> # clang++ --version
> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM
> 5.0.0svn)
> Target: powerpc-unknown-freebsd12.0
> Thread model: posix
> InstalledDir: /usr/bin
>
> # uname -apKU
> FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT r326192M powerpc powerpc
> 1200054 1200054
>
> # svnlite info /usr/ports/ | grep "Re[plv]"
> Relative URL: ^/head
> Repository Root: https://svn.freebsd.org/ports
> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
> Revision: 455204
> Last Changed Rev: 455204
>
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
> ___
> freebsd-toolch...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
