From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 20 17:54:38 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F12E55D for ; Mon, 20 Jan 2014 17:54:38 +0000 (UTC) Received: from mail-pb0-x241.google.com (mail-pb0-x241.google.com [IPv6:2607:f8b0:400e:c01::241]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 37EFA191E for ; Mon, 20 Jan 2014 17:54:38 +0000 (UTC) Received: by mail-pb0-f65.google.com with SMTP id rq2so2536203pbb.8 for ; Mon, 20 Jan 2014 09:54:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:reply-to:subject:date; bh=Iyk2K6fvYNLbDPkOF2p5SQgAED667GVP56ua58RI4bE=; b=PW3CUoGb8ABGnat9Rc3iLOAsN/2ChnPnxZ41IPzghY+pf6VDDAzQLCcXuIzDVfZm9j /PNjlGxbGZZEtdeXZd2wCoOYuiu5QPF2BHbWFmODo6Phkg8JybjW6YZ/HGW9xQjcfzdr 25zoXS72kxc7RXkSbdHzOQvubDUEVM1X2Yx2grWzUjEiX7aufCZoMN6skMXatLR7Xnp8 /ES8AT0p02JWkiY60SjcroyE0+K4ODW5xxCyJDfBf6Yili3Jt4rlE9jbeB7pb1p0uFO6 KJD5ywl2DmZe+r8mHMXifNRG7rRQ65DbeWb75ZyUt2ErbpPGgA7Puog5McMfk7C+JZm9 +V6g== X-Received: by 10.67.5.233 with SMTP id cp9mr4346103pad.147.1390240477904; Mon, 20 Jan 2014 09:54:37 -0800 (PST) Received: from localhost.localdomain ([124.253.33.120]) by mx.google.com with ESMTPSA id z10sm7618255pas.6.2014.01.20.09.54.35 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 20 Jan 2014 09:54:36 -0800 (PST) Message-ID: <52dd62dc.ca41420a.6d54.ffffd590@mx.google.com> From: bombshell11281@gmail.com To: freebsd-toolchain@freebsd.org Subject: RE: LOCAL MAP OPTIMIZATION FOR : mail-archive.com (Less Than $99/Month) Date: Mon, 20 Jan 2014 23:24:38 +0530 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: LORI76557@gmail.com List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 17:54:38 -0000 Good Morning Sir / Mam Is your business ranking in local maps shown on PAGE 1 of google ? With new google policies they have specifically asked local business owners to optimize their website for local maps rather than JUST organics. Do you know the reason why you are not ranked well on google MAPs or why there is drop in your website rankings? Prime reason for bad rankings for a busniess is lack of local presence and local citations ie getting your business listed on directories like YELP, MANTA & Many more. These websites not just give your business a push but also help you Maintain a good Online Reputation. Why you need to optimize your website for local MAP Listings ? - MAP listings get 10 times more clicks than organic listings - Increased conversions because of real reviews posted on your Google Plus Page - Every year there is 30% increase in searches for local keywords - Increases legitimacy of a Business We will help you get your website ranked well on google for the related keywords in your niche. We specialize in LOCAL SEARCH ENGINE OPTIMIZATION increasing visibility for small businesses by ranking them for geographically-related keywords. Say for eg-: you want to search a plumber in your city, You will be typing in keywords like Plumbers + City Or Plumbers + IN + City. We make sure your website comes in google MAP listings shown on page 1 for each such keyword. Now Google believes in - BE ORIGINAL, HAVE ORIGINAL AND GIVE ORIGINAL which means that google wants to end up that frustrating experience of users who are searching for Service Or Product and seeing the results that are not even close to what they are looking for. Google only wants to give their user original and relevant results. This makes it even more important that we showcase our business in the best possible way and make sure our website in valued high by google. We at TheLOCALIST will make google feel the importance of your business by following their guidelines thus ranking your website higher in serach results. We are presently offering LOCAL OPTIMIZATION to more than 400 websites and they all rank page 1 for all possible keywords !!! Each month your website is submitted to more than 50 citations and social presence is controlled by posting videos and blogs all over the web. Email us back with your website & phone number so we can discuss this further with you. Our Packages start from as low as 99$/month. Thanks For Taking Time To Read Our Email Polly Martin Local SEO Manager ( THE Localist ) Address : 24 ST Suite 32 Downtown Provo Utah ------------------- NOT INTERESTED ? REPLY WITH NOT INTERESTED IN THE SUBJECT LINE From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 20 20:04:39 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15F02E78 for ; Mon, 20 Jan 2014 20:04:39 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AF3A715BD for ; Mon, 20 Jan 2014 20:04:38 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::94c5:fb70:43a8:65e3] (unknown [IPv6:2001:7b8:3a7:0:94c5:fb70:43a8:65e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A90C45C44 for ; Mon, 20 Jan 2014 21:04:36 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_25AFC3CB-4FF1-4539-BCF5-0DFA390DFE40"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: [CFT] Update to clang 3.4 X-Pgp-Agent: GPGMail 2.1 (6062eb4) From: Dimitry Andric In-Reply-To: <541C998A-071A-4917-9D91-DD00CB0E2689@FreeBSD.org> Date: Mon, 20 Jan 2014 21:04:20 +0100 Message-Id: References: <541C998A-071A-4917-9D91-DD00CB0E2689@FreeBSD.org> To: freebsd-toolchain@freebsd.org X-Mailer: Apple Mail (2.1827) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 20:04:39 -0000 --Apple-Mail=_25AFC3CB-4FF1-4539-BCF5-0DFA390DFE40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 01 Jan 2014, at 23:32, Dimitry Andric wrote: > I have almost completed the preliminary work to import clang 3.4 into > FreeBSD 11-CURRENT. The official clang 3.4 release has not yet been > announced, but I do not expect any more changes from upstream for now. >=20 > However, since this version introduces a bunch of new warnings, and a > more strict options parser, I would like to call for some additional > testing by anyone who is interested. >=20 > Specifically, the following: > * Building and installing world with non-standard settings in = make.conf > and/or src.conf. > * Compiling your favorite set of ports. (I will request a ports > exp-run too). > * Fixing any kernel source with LINT that has not yet been fixed. (I > am still working on some of the things that are not in GENERIC.) > * Any other problems you may encounter with optimization, > incompatibilities, and so on. >=20 > One thing to look out for, in particular with ports, is the more = strict > option parsing introduced with clang 3.4. In earlier releases, = unknown > or unsupported command line options were ignored, with just a = "argument > unused during compilation" warning. =46rom 3.4 onwards, such options = will > result in a "unknown argument" error. >=20 > Another important new issue is that clang 3.4 now outputs DWARF4 as > default format when using -g. Our ancient version of gdb in base does > not support this, so you must either install the gdb port, or build = lldb > and use it (very experimental at this time!). >=20 > Moreover, our CTF tools such as ctfconvert use a quite old version of > libdwarf in our base system, which also does not support DWARF4. So > ctfconvert processing of kernel objects doe not work at the moment. This particular problem has now been fixed, thanks to Kai Wang. With his fix, the CTF tools now work correctly on a kernel compiled with clang 3.4, and DTrace works again. (However, see footnote [1].) I have rebased the patch against head r260893, and included Kai's fix. It is located here: http://www.andric.com/freebsd/clang/head-r260893-clang34-2.diff.xz SHA256 (head-r260893-clang34-2.diff.xz) =3D = d9b5316d701f6b52d9563c025ce9fb81f6e5aa3c0881ee36a895d14cc8744014 To apply, unxz the file into a fresh head checkout, and run: svn patch head-r260893-clang34-2.diff -Dimitry [1] Note that there is still an open issue with the CTF tools: they are not yet built as part of the kernel-tools stage, so any fixes to them are only effective after installing world. See also: = http://lists.freebsd.org/pipermail/freebsd-hackers/2014-January/044103.htm= l --Apple-Mail=_25AFC3CB-4FF1-4539-BCF5-0DFA390DFE40 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlLdgVMACgkQsF6jCi4glqOjHwCgq4+yZ5+AlpVB4EoL459yOuQZ il4AoMtrydZnklS26VxIoz4pkdzbtIV5 =HDWJ -----END PGP SIGNATURE----- --Apple-Mail=_25AFC3CB-4FF1-4539-BCF5-0DFA390DFE40-- From owner-freebsd-toolchain@FreeBSD.ORG Tue Jan 21 08:50:08 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 583CA5AB for ; Tue, 21 Jan 2014 08:50:08 +0000 (UTC) Received: from mail-ie0-x246.google.com (mail-ie0-x246.google.com [IPv6:2607:f8b0:4001:c03::246]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2A78212EF for ; Tue, 21 Jan 2014 08:50:08 +0000 (UTC) Received: by mail-ie0-f198.google.com with SMTP id ar20so17967718iec.9 for ; Tue, 21 Jan 2014 00:50:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:message-id:date:subject:from:to:content-type; bh=hsWuH38CasZsdQNhHI1/ypZktovMPjTLdjolhpONFVs=; b=v1X96+gMzvRfkgwWX8J7FxLGzNcmeJx5pdKZtvkjzdfO0yKTnYxA3SViFosS09zv8B JBey3g3pCk5FmVZqlLteup5ybH+YfqUOaFFDOHUPRhBCfnbXClq4lETrwFUWJSWNj0dP Ya9nUmxk3LuSXP+lIfxhdElNWduAitGbWX4iSyuu2Z8TwXka0NR1ikYOp8aBC6gAQ4d7 51Z6VNGpPOCWtCE1/uZgKZ6QLKlbzq0okEsvvAqIhCdnoy+9NsZnu5P2TY/lCqkYci1p 4ypRCKqaUyrdaSNp9vx+O/5oY0ahRnyJzelV6FCdm2EQSwu/jBQlS/Flnu03OHr8qbkG tApg== MIME-Version: 1.0 X-Received: by 10.182.22.133 with SMTP id d5mr8625544obf.27.1390294207689; Tue, 21 Jan 2014 00:50:07 -0800 (PST) Message-ID: <001a11c2ef8661fd1104f07718f3@google.com> Date: Tue, 21 Jan 2014 08:50:07 +0000 Subject: www.freebsd.org From: Anna Garcia To: freebsd-toolchain@freebsd.org Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 08:50:08 -0000 SGksDQoNCkkganVzdCB3YW50ZWQgdG8gc2VuZCB5b3UgYSBxdWljayBub3RlLiBXaXRoIGEgZmV3 IHNpbXBsZSBjaGFuZ2VzIHRvIG1ha2UNCnlvdXIgc2l0ZSBtb3JlIFNFTy1mcmllbmRseSBJkm0g c3VyZSB5b3UgY2FuIGNvbnZlcnQgbW9yZSB2aXNpdG9ycyBpbnRvDQpsZWFkcyBhbmQgZ2V0IGl0 IHBsYWNlZCBoaWdoZXIgaW4gdGhlIG9yZ2FuaWMgc2VhcmNoIHJlc3VsdHMsIGZvciBrZXl3b3Jk cw0KdGhhdCBtYXR0ZXIgdG8geW91IHRoZSBtb3N0Lg0KDQpXZSBhcmUgYW4gQXVzdHJhbGlhbiBi YXNlZCBjb21wYW55IHdpdGggYSBncmVhdCBpbi1ob3VzZSB0ZWNobmljYWwgdGVhbSB3aG8NCnJl YWxseSBrbm93IHRoZWlyIHN0dWZmIGFib3V0IHNlYXJjaCBlbmdpbmUgb3B0aW1pemF0aW9uLg0K DQpXb3VsZCB5b3UgbGlrZSBhIGJpdCBtb3JlIGluZm9ybWF0aW9uIGFib3V0IGhvdyB0byBnaXZl IHlvdXIgd2Vic2l0ZSBhDQpib29zdCB3aXRoIGJldHRlciBTRU8/DQoNCkJlc3QgcmVnYXJkcywN Cg0KQW5uYSBHYXJjaWENClNFTy9XRUIgU3BlY2lhbGlzdA0KDQpbaW1hZ2U6IExpbmtlZEluXSBb aW1hZ2U6IEZhY2Vib29rXSBbaW1hZ2U6IFR3aXR0ZXJdIFtpbWFnZTogU2t5cGVdDQogICAgICAg ICAgICAgUyAgIEUgIE8gICAgICAgICAgICAqU2VhcmNoIEVuZ2luZSBPcHRpbWl6YXRpb24qDQoN CldlIHJlc3BlY3QgeW91ciBwcml2YWN5IGFuZCB3YW50IHRvIG1ha2Ugc3VyZSB5b3UgYXJlIGF3 YXJlIG9mIGEgZmV3DQp0aGluZ3MuIEJ5IHJlcGx5aW5nIHRvIHRoaXMgZW1haWwsIHlvdSBhdXRo b3JpemUgb3VyIEF1c3RyYWxpYW4gYWZmaWxpYXRlcw0KdGhhdCBjYW4gaGVscCB3aXRoIHlvdXIg cHJvamVjdCB0byBjYWxsIHlvdSBhdCB0aGUgbnVtYmVyIHlvdSBwcm92aWRlZCwgYW5kDQp5b3Ug dW5kZXJzdGFuZCB0aGF0IHRoZXkgbWF5IHVzZSBhdXRvbWF0ZWQgcGhvbmUgdGVjaG5vbG9neSB0 byBjYWxsIHlvdS4gQXQNCm5vIHRpbWUgYXJlIHlvdSByZXF1aXJlZCB0byBtYWtlIGEgcHVyY2hh c2UuDQo= From owner-freebsd-toolchain@FreeBSD.ORG Tue Jan 21 23:29:12 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FD798D1 for ; Tue, 21 Jan 2014 23:29:12 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D369D14BD for ; Tue, 21 Jan 2014 23:29:11 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id q8so6624312lbi.0 for ; Tue, 21 Jan 2014 15:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=prGXHRrmhtzbNf+pAcLf9mjRysf7h5eTnf5QGa15nQI=; b=NxTyOXfa4tE9mqCoFKOZA75W/GmQvavjWbQbYN6Kk2u2N/gfkY1d7uS/M84MmcFJMW XC/WpjDaAz8sFmplTGRsU6VdiulaH/WNPVo5hj+fZtqYOIdXERNgBRs1y8dbvK1tEDCl 7iVmDR/bq5Wmeo+HoM2kemU9/OsyJuBXG+DvBb0nf9v86pEkebpwn73KISjaMRG0LZt9 wHWW1wgmbvUwb0JGAPT+h4tesIrU32+uLkpbsAg9T0zm3t6TCzV3iW3g4MuvuzGJIXCr SVevm5qMhnuPj7kNVdQRnwIdotbWHnnizey/0FL7q4w+WeYA9zKyF+OyMqkEdsptHWFQ dGpQ== X-Received: by 10.112.150.100 with SMTP id uh4mr17357435lbb.3.1390346949881; Tue, 21 Jan 2014 15:29:09 -0800 (PST) Received: from localhost (s83-179-26-16.cust.tele2.se. [83.179.26.16]) by mx.google.com with ESMTPSA id c15sm5547533lbq.11.2014.01.21.15.29.08 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 21 Jan 2014 15:29:09 -0800 (PST) Sender: Kai Wang Received: from localhost.localdomain ([127.0.0.1] helo=localhost.my.domain) by localhost with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1W5kkR-000DqR-Ji for freebsd-toolchain@freebsd.org; Wed, 22 Jan 2014 00:28:47 +0100 Received: (from kaiw@localhost) by localhost.my.domain (8.14.5/8.14.5/Submit) id s0LNSlsU053222 for freebsd-toolchain@freebsd.org; Wed, 22 Jan 2014 00:28:47 +0100 (CET) (envelope-from kaiw27@gmail.com) X-Authentication-Warning: localhost.my.domain: kaiw set sender to kaiw27@gmail.com using -f Date: Wed, 22 Jan 2014 00:28:47 +0100 From: Kai Wang To: freebsd-toolchain@freebsd.org Subject: [CFT] libelf/libdwarf import and ctfconvert update Message-ID: <20140121232847.GA53197@soulhacker> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 23:29:12 -0000 Hi list, As some of you might already know, I'm working on integrating new versions of libelf and libdwarf from elftoolchain project back to FreeBSD and updating the ctfconvert tool for Clang 3.4 import. The patch is available below and applies to head@r260988: (It could be applied/tested together with dim@'s Clang 3.4 patch) http://people.freebsd.org/~kaiw/head-r260988-libdwarf-libelf-ctfconvert.diff.gz Tests/reviews/comments are appreciated! A short changelog: * libelf and libdwarf in base is replaced by their counterparts in elftoolchain. The elftoolchain versions of these libraries originated from FreeBSD and have being maintained and furthur developed outside of FreeBSD source tree. * The new version of libelf includes a few new APIs and numerous bug fixes (some of them have been merged back in the past years) * The new version of libdwarf is based on jb@'s libdwarf in our src/ tree and has support for dwarf call frame, line number info, among other things. Currently it supports reading DWARF[23] and partial DWARF4, and writing DWARF2. The APIs are 99% compatible with the LGPL libdwarf and are fully documented. Some of incompatible APIs from jb@'s libdwarf are kept as our own extensions. * The ctfconvert tool is updated to use the API from the new libdwarf. Improvements were made so it can properly read/process dwarf info generated by Clang 3.4. (see r260880 and r260897 for details) Thanks, Kai From owner-freebsd-toolchain@FreeBSD.ORG Wed Jan 22 13:52:46 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C238FD6B; Wed, 22 Jan 2014 13:52:46 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6376C1A44; Wed, 22 Jan 2014 13:52:46 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id EDB0140016; Wed, 22 Jan 2014 14:52:44 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id E3DF640015; Wed, 22 Jan 2014 14:52:44 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (unknown [94.254.45.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id D51A240014; Wed, 22 Jan 2014 14:52:43 +0100 (CET) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3f8Sj94j9tz8ggx; Wed, 22 Jan 2014 14:52:13 +0100 (CET) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([10.1.0.3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [10.1.0.6]) (amavisd-new, port 10025) with ESMTPS id 6U4L5Zx-sQCz; Wed, 22 Jan 2014 14:52:10 +0100 (CET) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 3f8Sj64Dwyz8ggv; Wed, 22 Jan 2014 14:52:10 +0100 (CET) Received: from vivi.daemonic.se (vivi.daemonic.se [IPv6:2001:470:dca9:1::4]) by mail.daemonic.se (Postfix) with ESMTPSA id 3f8Sj536wMz9CvV; Wed, 22 Jan 2014 14:52:09 +0100 (CET) Message-ID: <52DFCCFF.8080002@daemonic.se> Date: Wed, 22 Jan 2014 14:51:59 +0100 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: [CFT] Update to clang 3.4 References: <541C998A-071A-4917-9D91-DD00CB0E2689@FreeBSD.org> <63BD3165-A62E-4FE7-9817-4A2692584916@bsdimp.com> <264FAA6E-871A-48AF-A8D9-EC431A537195@FreeBSD.org> <6766B735-98CB-4F1D-B3B5-A43D81BB558A@FreeBSD.org> <52D286BE.7000102@kbh.biglobe.ne.jp> <50EAAC3C-2D38-4409-B525-2608D39BFE70@FreeBSD.org> In-Reply-To: <50EAAC3C-2D38-4409-B525-2608D39BFE70@FreeBSD.org> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 13:52:46 -0000 On 01/12/14 17:21, Dimitry Andric wrote: > On 12 Jan 2014, at 13:12, Yamaya Takashi wrote: >> buildworld is failed when WITH_LLDB= > > Yes, this is a known issue. I discussed it with Ed Maste. Clang 3.4 > will have to be imported first, afterwards we can fix lldb. > > >> some ports cannot build. >> >> reason1: clang cannot handle some options. >> (libmad build) >> cc: error: unknown argument: '-fforce-addr' >> cc: error: unknown argument: '-fthread-jumps' >> cc: error: unknown argument: '-fcse-follow-jumps' >> cc: error: unknown argument: '-fcse-skip-blocks' >> cc: error: unknown argument: '-fregmove' >> cc: error: unknown argument: '-fschedule-insns2' >> (libtheora build) >> cc: error: unknown argument: '-fforce-addr' >> (poppler build) >> c++: error: unknown argument: '-fno-check-new' >> (py27-sqlite build) >> cc: error: unknown argument: '-R/usr/local/lib' >> (tbb build) >> c++: error: unknown argument: '-fno-schedule-insns2' >> (gstreamer-ffmpeg build) >> cc: error: unknown argument: '-fno-force-addr' > > Indeed, this is likely the most troublesome aspect of the upgrade. > > Most of the above options, like "-fcse-follow-jumps", "-fno-check-new", > etc are gcc-specific, and will never be supported by clang. These > options will have to be removed, or made conditional on the compiler. > > The -R option is not a compiler option, but an ld option, and is also > ambiguous: ld interprets it as --just-symbols when it is followed by the > name of a file, but as -rpath when it is followed by the name of a > directory. In all cases, this should be replaced with -Wl,-rpath. > > >> reason2: c++ -std=c++11 detect bad c++ code which older clang cannot detect. >> (libproxy build) >> /usr/ports/net/libproxy/work/libproxy-0.4.6/libproxy/modules/wpad_dns_alias.cpp:30:23: >> error: cannot initialize return object of type 'libproxy::url *' with an >> rvalue of type 'bool' >> if (lasturl) return false; >> ^~~~~ >> (liveMedia build) > > I have not looked in detail at this one, but this looks like a simple > bug. The code should not return a boolean when the return type of the > function is a libproxy::url pointer. Should be easy to fix. > > The new C++11 rules make it possible to avoid 'casting' a false value to > a NULL pointer, and clang 3.4 detects this. > > >> c++ -c -Iinclude -I../UsageEnvironment/include -I../groupsock/include >> -I. -DBSD=1 -DSOCKLEN_T=socklen_t -D_LARGEFILE_SOURCE=1 >> -D_FILE_OFFSET_BITS=64 -DHAVE_SOCKADDR_LEN=1 -Wall -DBSD=1 -O2 -pipe >> -Qunused-arguments -march=native -fPIC -fno-strict-aliasing -std=c++11 >> -Wno-c++11-narrowing -stdlib=libc++ -Wno-deprecated RTSPRegisterSender.cpp >> RTSPClient.cpp:916:25: error: comparison between pointer and integer >> ('const char *' and 'int') >> if (&line[paramIndex] == '\0') return False; // the header is assumed >> to be bad if it has no parameters >> ~~~~~~~~~~~~~~~~~ ^ ~~~~ >> (mp4v2 build) > > This looks like an incorrect comparison: a pointer is compared with a > literal character. Should be easy to fix. > > >> c++ -DHAVE_CONFIG_H -I./include -I./include -I. -I. -Wall -Wformat -O2 >> -pipe -Qunused-arguments -march=native -fno-strict-aliasing -std=c++11 >> -Wno-c++11-narrowing -stdlib=libc++ -fvisibility=hidden -c >> src/mp4container.cpp -fPIC -DPIC -o src/.libs/mp4container.o >> src/mp4.cpp:679:20: error: cannot initialize return object of type >> 'mp4v2_ismacrypParams *' (aka 'mp4v2_ismacryp_session_params *') with an >> rvalue of type 'MP4TrackId' (aka 'unsigned int') >> return MP4_INVALID_TRACK_ID; >> ^~~~~~~~~~~~~~~~~~~~ >> ./include/mp4v2/general.h:45:33: note: expanded from macro >> 'MP4_INVALID_TRACK_ID' >> #define MP4_INVALID_TRACK_ID ((MP4TrackId)0) /**< Constant: >> invalid MP4TrackId. */ >> ^~~~~~~~~~~~~~~ >> (thunderbird build) > > Again, an attempt is made to use an incorrect type for the return value > of a function. Either the value should be explicitly cast to the > correct type (mp4v2_ismacrypParams *), or the MP4_INVALID_TRACK_ID > define should be fixed to be of the correct type. > > >> clang++ -o jsoptparse.o -c -I../../../dist/system_wrappers_js -include >> /usr/ports/mail/thunderbird/work/comm-esr24/mozilla/js/src/config/gcc_hidden.h >> -DEXPORT_JS_API -DIMPL_MFBT -DMOZ_GLUE_IN_PROGRAM -DNO_NSPR_10_SUPPORT >> -I/usr/ports/mail/thunderbird/work/comm-esr24/mozilla/js/src -I.. >> -I/usr/ports/mail/thunderbird/work/comm-esr24/mozilla/js/src/shell -I. >> -I../../../dist/include -I/usr/local/include/nspr -fPIC >> -Qunused-arguments -isystem/usr/local/include -Qunused-arguments -Wall >> -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits >> -Wempty-body -Werror=conversion-null -Wsign-compare >> -Wno-invalid-offsetof -Wno-c++0x-extensions -Wno-extended-offsetof >> -Wno-unknown-warning-option -Wno-return-type-c-linkage >> -Wno-mismatched-tags -O2 -pipe -Qunused-arguments -march=native -O3 >> -fno-strict-aliasing -std=c++11 -Wno-c++11-narrowing -stdlib=libc++ >> -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -pipe >> -DNDEBUG -DTRIMMED -O2 -O3 -fomit-frame-pointer -Qunused-arguments >> -isystem/usr/local/include -DMOZILLA_CLIENT -include ../js-confdefs.h >> -MD -MP -MF .deps/jsoptparse.o.pp /usr/ports/mail/thunderbir >> d/work/comm-esr24/mozilla/js/src/shell/jsoptparse.cpp >> /usr/ports/mail/thunderbird/work/comm-esr24/mozilla/js/src/shell/jsoptparse.cpp:256:22: >> error: comparison between pointer and integer ('char *' and 'int') >> if (value[0] == '\0') >> ~~~~~~~~ ^ ~~~~ > > Like the mp4v2 build, this is probably a simple bug. The code should > not compare a pointer to an integer. Most likely, the right side was > supposed to be NULL instead? > I'm probably late to the party, as always... But, have you or Yamaya Takashi tried to punt these issues to the respective port managers for investigation? Regards! -- Niclas From owner-freebsd-toolchain@FreeBSD.ORG Wed Jan 22 17:26:11 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F781CF7; Wed, 22 Jan 2014 17:26:11 +0000 (UTC) Received: from rcpt-expgw.biglobe.ne.jp (rcpt-expgw.biglobe.ne.jp [IPv6:2001:260:401:16::2]) by mx1.freebsd.org (Postfix) with ESMTP id C19211F0F; Wed, 22 Jan 2014 17:26:10 +0000 (UTC) Received: from vc-gw.biglobe.ne.jp by rcpt-expgw.biglobe.ne.jp (shby/5910021009) with SMTP id s0MHPrC7027939; Thu, 23 Jan 2014 02:25:53 +0900 Received: from smtp-gw.biglobe.ne.jp ([172.30.161.159]) by vc-gw.biglobe.ne.jp (kbkr/0716090908) with ESMTP id s0MHPr8Z020461; Thu, 23 Jan 2014 02:25:53 +0900 X-Biglobe-Sender: Received: from [192.168.0.100] (KD027083060020.ppp-bb.dion.ne.jp [27.83.60.20]) by smtp-gw.biglobe.ne.jp id CUZlAC1EB41F; Thu, 23 Jan 2014 02:25:53 +0900 (JST) Message-ID: <52DFFF20.9000809@kbh.biglobe.ne.jp> Date: Thu, 23 Jan 2014 02:25:52 +0900 From: Yamaya Takashi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Niclas Zeising Subject: Re: [CFT] Update to clang 3.4 References: <541C998A-071A-4917-9D91-DD00CB0E2689@FreeBSD.org> <63BD3165-A62E-4FE7-9817-4A2692584916@bsdimp.com> <264FAA6E-871A-48AF-A8D9-EC431A537195@FreeBSD.org> <6766B735-98CB-4F1D-B3B5-A43D81BB558A@FreeBSD.org> <52D286BE.7000102@kbh.biglobe.ne.jp> <50EAAC3C-2D38-4409-B525-2608D39BFE70@FreeBSD.org> <52DFCCFF.8080002@daemonic.se> In-Reply-To: <52DFCCFF.8080002@daemonic.se> Content-Type: multipart/mixed; boundary="------------080501070209050709030102" Cc: freebsd-toolchain@freebsd.org, Dimitry Andric X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 17:26:11 -0000 This is a multi-part message in MIME format. --------------080501070209050709030102 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit On 2014/01/22 22:51, Niclas Zeising wrote: > On 01/12/14 17:21, Dimitry Andric wrote: >> On 12 Jan 2014, at 13:12, Yamaya Takashi wrote: >>> buildworld is failed when WITH_LLDB= >> Yes, this is a known issue. I discussed it with Ed Maste. Clang 3.4 >> will have to be imported first, afterwards we can fix lldb. >> >> >>> some ports cannot build. >>> >>> reason1: clang cannot handle some options. >>> (libmad build) >>> cc: error: unknown argument: '-fforce-addr' >>> cc: error: unknown argument: '-fthread-jumps' >>> cc: error: unknown argument: '-fcse-follow-jumps' >>> cc: error: unknown argument: '-fcse-skip-blocks' >>> cc: error: unknown argument: '-fregmove' >>> cc: error: unknown argument: '-fschedule-insns2' >>> (libtheora build) >>> cc: error: unknown argument: '-fforce-addr' >>> (poppler build) >>> c++: error: unknown argument: '-fno-check-new' >>> (py27-sqlite build) >>> cc: error: unknown argument: '-R/usr/local/lib' >>> (tbb build) >>> c++: error: unknown argument: '-fno-schedule-insns2' >>> (gstreamer-ffmpeg build) >>> cc: error: unknown argument: '-fno-force-addr' >> Indeed, this is likely the most troublesome aspect of the upgrade. >> >> Most of the above options, like "-fcse-follow-jumps", "-fno-check-new", >> etc are gcc-specific, and will never be supported by clang. These >> options will have to be removed, or made conditional on the compiler. >> >> The -R option is not a compiler option, but an ld option, and is also >> ambiguous: ld interprets it as --just-symbols when it is followed by the >> name of a file, but as -rpath when it is followed by the name of a >> directory. In all cases, this should be replaced with -Wl,-rpath. >> >> >>> reason2: c++ -std=c++11 detect bad c++ code which older clang cannot detect. >>> (libproxy build) >>> /usr/ports/net/libproxy/work/libproxy-0.4.6/libproxy/modules/wpad_dns_alias.cpp:30:23: >>> error: cannot initialize return object of type 'libproxy::url *' with an >>> rvalue of type 'bool' >>> if (lasturl) return false; >>> ^~~~~ >>> (liveMedia build) >> I have not looked in detail at this one, but this looks like a simple >> bug. The code should not return a boolean when the return type of the >> function is a libproxy::url pointer. Should be easy to fix. >> >> The new C++11 rules make it possible to avoid 'casting' a false value to >> a NULL pointer, and clang 3.4 detects this. >> >> >>> c++ -c -Iinclude -I../UsageEnvironment/include -I../groupsock/include >>> -I. -DBSD=1 -DSOCKLEN_T=socklen_t -D_LARGEFILE_SOURCE=1 >>> -D_FILE_OFFSET_BITS=64 -DHAVE_SOCKADDR_LEN=1 -Wall -DBSD=1 -O2 -pipe >>> -Qunused-arguments -march=native -fPIC -fno-strict-aliasing -std=c++11 >>> -Wno-c++11-narrowing -stdlib=libc++ -Wno-deprecated RTSPRegisterSender.cpp >>> RTSPClient.cpp:916:25: error: comparison between pointer and integer >>> ('const char *' and 'int') >>> if (&line[paramIndex] == '\0') return False; // the header is assumed >>> to be bad if it has no parameters >>> ~~~~~~~~~~~~~~~~~ ^ ~~~~ >>> (mp4v2 build) >> This looks like an incorrect comparison: a pointer is compared with a >> literal character. Should be easy to fix. >> >> >>> c++ -DHAVE_CONFIG_H -I./include -I./include -I. -I. -Wall -Wformat -O2 >>> -pipe -Qunused-arguments -march=native -fno-strict-aliasing -std=c++11 >>> -Wno-c++11-narrowing -stdlib=libc++ -fvisibility=hidden -c >>> src/mp4container.cpp -fPIC -DPIC -o src/.libs/mp4container.o >>> src/mp4.cpp:679:20: error: cannot initialize return object of type >>> 'mp4v2_ismacrypParams *' (aka 'mp4v2_ismacryp_session_params *') with an >>> rvalue of type 'MP4TrackId' (aka 'unsigned int') >>> return MP4_INVALID_TRACK_ID; >>> ^~~~~~~~~~~~~~~~~~~~ >>> ./include/mp4v2/general.h:45:33: note: expanded from macro >>> 'MP4_INVALID_TRACK_ID' >>> #define MP4_INVALID_TRACK_ID ((MP4TrackId)0) /**< Constant: >>> invalid MP4TrackId. */ >>> ^~~~~~~~~~~~~~~ >>> (thunderbird build) >> Again, an attempt is made to use an incorrect type for the return value >> of a function. Either the value should be explicitly cast to the >> correct type (mp4v2_ismacrypParams *), or the MP4_INVALID_TRACK_ID >> define should be fixed to be of the correct type. >> >> >>> clang++ -o jsoptparse.o -c -I../../../dist/system_wrappers_js -include >>> /usr/ports/mail/thunderbird/work/comm-esr24/mozilla/js/src/config/gcc_hidden.h >>> -DEXPORT_JS_API -DIMPL_MFBT -DMOZ_GLUE_IN_PROGRAM -DNO_NSPR_10_SUPPORT >>> -I/usr/ports/mail/thunderbird/work/comm-esr24/mozilla/js/src -I.. >>> -I/usr/ports/mail/thunderbird/work/comm-esr24/mozilla/js/src/shell -I. >>> -I../../../dist/include -I/usr/local/include/nspr -fPIC >>> -Qunused-arguments -isystem/usr/local/include -Qunused-arguments -Wall >>> -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits >>> -Wempty-body -Werror=conversion-null -Wsign-compare >>> -Wno-invalid-offsetof -Wno-c++0x-extensions -Wno-extended-offsetof >>> -Wno-unknown-warning-option -Wno-return-type-c-linkage >>> -Wno-mismatched-tags -O2 -pipe -Qunused-arguments -march=native -O3 >>> -fno-strict-aliasing -std=c++11 -Wno-c++11-narrowing -stdlib=libc++ >>> -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -pipe >>> -DNDEBUG -DTRIMMED -O2 -O3 -fomit-frame-pointer -Qunused-arguments >>> -isystem/usr/local/include -DMOZILLA_CLIENT -include ../js-confdefs.h >>> -MD -MP -MF .deps/jsoptparse.o.pp /usr/ports/mail/thunderbir >>> d/work/comm-esr24/mozilla/js/src/shell/jsoptparse.cpp >>> /usr/ports/mail/thunderbird/work/comm-esr24/mozilla/js/src/shell/jsoptparse.cpp:256:22: >>> error: comparison between pointer and integer ('char *' and 'int') >>> if (value[0] == '\0') >>> ~~~~~~~~ ^ ~~~~ >> Like the mp4v2 build, this is probably a simple bug. The code should >> not compare a pointer to an integer. Most likely, the right side was >> supposed to be NULL instead? >> > I'm probably late to the party, as always... But, have you or Yamaya > Takashi tried to punt these issues to the respective port managers for > investigation? > Regards! I have patches for libproxy, liveMedia, mp4v2 and thunderbird. --------------080501070209050709030102 Content-Type: text/plain; charset=UTF-8; name="thunderbird.patch.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="thunderbird.patch.txt" SW5kZXg6IG1haWwvdGh1bmRlcmJpcmQvZmlsZXMvcGF0Y2gtbW96aWxsYS1qcy1zcmMtc2hl bGwtanNvcHRwYXJzZS5jcHAKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gbWFpbC90aHVuZGVyYmlyZC9m aWxlcy9wYXRjaC1tb3ppbGxhLWpzLXNyYy1zaGVsbC1qc29wdHBhcnNlLmNwcAkocmV2aXNp b24gMCkKKysrIG1haWwvdGh1bmRlcmJpcmQvZmlsZXMvcGF0Y2gtbW96aWxsYS1qcy1zcmMt c2hlbGwtanNvcHRwYXJzZS5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTAsMCArMSwxMSBAQAor LS0tIG1vemlsbGEvanMvc3JjL3NoZWxsL2pzb3B0cGFyc2UuY3BwLm9yaWcJMjAxNC0wMS0x NCAwMTowNjozOS4xMzc4NjQ4NzUgKzA5MDAKKysrKyBtb3ppbGxhL2pzL3NyYy9zaGVsbC9q c29wdHBhcnNlLmNwcAkyMDE0LTAxLTE0IDAxOjE3OjQwLjc3NTgyMjQ5MiArMDkwMAorQEAg LTI1Myw3ICsyNTMsNyBAQAorICAgICBjaGFyICplcSA9IHN0cmNocihhcmd2WyppXSwgJz0n KTsKKyAgICAgaWYgKGVxKSB7CisgICAgICAgICAqdmFsdWUgPSBlcSArIDE7CistICAgICAg ICBpZiAodmFsdWVbMF0gPT0gJ1wwJykKKysgICAgICAgIGlmICgqKnZhbHVlID09ICdcMCcp CisgICAgICAgICAgICAgcmV0dXJuIGVycm9yKCJBIHZhbHVlIGlzIHJlcXVpcmVkIGZvciBv cHRpb24gJS4qcyIsIGVxIC0gYXJndlsqaV0sIGFyZ3ZbKmldKTsKKyAgICAgICAgIHJldHVy biBPa2F5OworICAgICB9CgpQcm9wZXJ0eSBjaGFuZ2VzIG9uOiBtYWlsL3RodW5kZXJiaXJk L2ZpbGVzL3BhdGNoLW1vemlsbGEtanMtc3JjLXNoZWxsLWpzb3B0cGFyc2UuY3BwCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KQWRkZWQ6IHN2bjptaW1lLXR5cGUKIyMgLTAsMCArMSAjIwordGV4dC9wbGFp bgpcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIHByb3BlcnR5CkFkZGVkOiBmYnNkOm5va2V5d29y ZHMKIyMgLTAsMCArMSAjIworeWVzClwgTm8gbmV3bGluZSBhdCBlbmQgb2YgcHJvcGVydHkK QWRkZWQ6IHN2bjplb2wtc3R5bGUKIyMgLTAsMCArMSAjIworbmF0aXZlClwgTm8gbmV3bGlu ZSBhdCBlbmQgb2YgcHJvcGVydHkK --------------080501070209050709030102 Content-Type: text/plain; charset=UTF-8; name="mp4v2.patch.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mp4v2.patch.txt" SW5kZXg6IG11bHRpbWVkaWEvbXA0djIvZmlsZXMvcGF0Y2gtc3JjX19tcDQuY3BwCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KLS0tIG11bHRpbWVkaWEvbXA0djIvZmlsZXMvcGF0Y2gtc3JjX19tcDQuY3Bw CShyZXZpc2lvbiAwKQorKysgbXVsdGltZWRpYS9tcDR2Mi9maWxlcy9wYXRjaC1zcmNfX21w NC5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTAsMCArMSwxMSBAQAorLS0tIHNyYy9tcDQuY3Bw Lm9yaWcJMjAxNC0wMS0xNCAwMDozNjoxNy45MTI5OTMyMDggKzA5MDAKKysrKyBzcmMvbXA0 LmNwcAkyMDE0LTAxLTE0IDAwOjQzOjQxLjEwMzk2ODU5NyArMDkwMAorQEAgLTY3Niw3ICs2 NzYsNyBAQAorICAgICAgICAgfQorIAorICAgICAgICAgY2F0Y2ggKC4uLikgeworLSAgICAg ICAgICAgIHJldHVybiBNUDRfSU5WQUxJRF9UUkFDS19JRDsKKysgICAgICAgICAgICByZXR1 cm4gTlVMTDsKKyAgICAgICAgIH0KKyAgICAgfQorIAoKUHJvcGVydHkgY2hhbmdlcyBvbjog bXVsdGltZWRpYS9tcDR2Mi9maWxlcy9wYXRjaC1zcmNfX21wNC5jcHAKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwpBZGRlZDogZmJzZDpub2tleXdvcmRzCiMjIC0wLDAgKzEgIyMKK3llcwpcIE5vIG5ld2xp bmUgYXQgZW5kIG9mIHByb3BlcnR5CkFkZGVkOiBzdm46ZW9sLXN0eWxlCiMjIC0wLDAgKzEg IyMKK25hdGl2ZQpcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIHByb3BlcnR5CkFkZGVkOiBzdm46 bWltZS10eXBlCiMjIC0wLDAgKzEgIyMKK3RleHQvcGxhaW4KXCBObyBuZXdsaW5lIGF0IGVu ZCBvZiBwcm9wZXJ0eQpJbmRleDogbXVsdGltZWRpYS9tcDR2Mi9maWxlcy9wYXRjaC1zcmNf X3J0cGhpbnQuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIG11bHRpbWVkaWEvbXA0djIvZmlsZXMv cGF0Y2gtc3JjX19ydHBoaW50LmNwcAkocmV2aXNpb24gMCkKKysrIG11bHRpbWVkaWEvbXA0 djIvZmlsZXMvcGF0Y2gtc3JjX19ydHBoaW50LmNwcAkod29ya2luZyBjb3B5KQpAQCAtMCww ICsxLDExIEBACistLS0gc3JjL3J0cGhpbnQuY3BwLm9yaWcJMjAxNC0wMS0xNCAwMDo0Nzoy OC45ODM5NDkyMjMgKzA5MDAKKysrKyBzcmMvcnRwaGludC5jcHAJMjAxNC0wMS0xNCAwMDo1 NDowNi43OTE5MzEzODMgKzA5MDAKK0BAIC0zNDUsNyArMzQ1LDcgQEAKKyAgICAgICAgICAg ICAgICAgcFNsYXNoID0gc3RyY2hyKHBTbGFzaCwgJy8nKTsKKyAgICAgICAgICAgICAgICAg aWYgKHBTbGFzaCAhPSBOVUxMKSB7CisgICAgICAgICAgICAgICAgICAgICBwU2xhc2grKzsK Ky0gICAgICAgICAgICAgICAgICAgIGlmIChwU2xhc2ggIT0gJ1wwJykgeworKyAgICAgICAg ICAgICAgICAgICAgaWYgKCpwU2xhc2ggIT0gJ1wwJykgeworICAgICAgICAgICAgICAgICAg ICAgICAgIGxlbmd0aCA9IHN0cmxlbihwUnRwTWFwKSAtIChwU2xhc2ggLSBwUnRwTWFwKTsK KyAgICAgICAgICAgICAgICAgICAgICAgICAqcHBFbmNvZGluZ1BhcmFtcyA9IChjaGFyICop TVA0Q2FsbG9jKGxlbmd0aCArIDEpOworICAgICAgICAgICAgICAgICAgICAgICAgIHN0cm5j cHkoKnBwRW5jb2RpbmdQYXJhbXMsIHBTbGFzaCwgbGVuZ3RoKTsKClByb3BlcnR5IGNoYW5n ZXMgb246IG11bHRpbWVkaWEvbXA0djIvZmlsZXMvcGF0Y2gtc3JjX19ydHBoaW50LmNwcApf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCkFkZGVkOiBzdm46bWltZS10eXBlCiMjIC0wLDAgKzEgIyMKK3RleHQv cGxhaW4KXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBwcm9wZXJ0eQpBZGRlZDogZmJzZDpub2tl eXdvcmRzCiMjIC0wLDAgKzEgIyMKK3llcwpcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIHByb3Bl cnR5CkFkZGVkOiBzdm46ZW9sLXN0eWxlCiMjIC0wLDAgKzEgIyMKK25hdGl2ZQpcIE5vIG5l d2xpbmUgYXQgZW5kIG9mIHByb3BlcnR5Cg== --------------080501070209050709030102 Content-Type: text/plain; charset=UTF-8; name="liveMedia.patch.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="liveMedia.patch.txt" SW5kZXg6IG5ldC9saXZlTWVkaWEvZmlsZXMvcGF0Y2gtbGl2ZU1lZGlhLVJUU1BDbGllbnQu Y3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KLS0tIG5ldC9saXZlTWVkaWEvZmlsZXMvcGF0Y2gtbGl2ZU1l ZGlhLVJUU1BDbGllbnQuY3BwCShyZXZpc2lvbiAwKQorKysgbmV0L2xpdmVNZWRpYS9maWxl cy9wYXRjaC1saXZlTWVkaWEtUlRTUENsaWVudC5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTAs MCArMSwxMSBAQAorLS0tIGxpdmVNZWRpYS9SVFNQQ2xpZW50LmNwcC5vcmlnCTIwMTQtMDEt MTQgMDA6MjE6MTAuNjE2Mzc2NDQzICswOTAwCisrKysgbGl2ZU1lZGlhL1JUU1BDbGllbnQu Y3BwCTIwMTQtMDEtMTQgMDA6MjQ6MTEuNTQxMzQ5NzI5ICswOTAwCitAQCAtOTEzLDcgKzkx Myw3IEBACisgICAvLyBUaGUgbGluZSBiZWdpbnMgd2l0aCB0aGUgZGVzaXJlZCBoZWFkZXIg bmFtZS4gIFRyaW0gb2ZmIGFueSB3aGl0ZXNwYWNlLCBhbmQgcmV0dXJuIHRoZSBoZWFkZXIg cGFyYW1ldGVyczoKKyAgIHVuc2lnbmVkIHBhcmFtSW5kZXggPSBoZWFkZXJOYW1lTGVuZ3Ro OworICAgd2hpbGUgKGxpbmVbcGFyYW1JbmRleF0gIT0gJ1wwJyAmJiAobGluZVtwYXJhbUlu ZGV4XSA9PSAnICcgfHwgbGluZVtwYXJhbUluZGV4XSA9PSAnXHQnKSkgKytwYXJhbUluZGV4 OworLSAgaWYgKCZsaW5lW3BhcmFtSW5kZXhdID09ICdcMCcpIHJldHVybiBGYWxzZTsgLy8g dGhlIGhlYWRlciBpcyBhc3N1bWVkIHRvIGJlIGJhZCBpZiBpdCBoYXMgbm8gcGFyYW1ldGVy cworKyAgaWYgKGxpbmVbcGFyYW1JbmRleF0gPT0gJ1wwJykgcmV0dXJuIEZhbHNlOyAvLyB0 aGUgaGVhZGVyIGlzIGFzc3VtZWQgdG8gYmUgYmFkIGlmIGl0IGhhcyBubyBwYXJhbWV0ZXJz CisgCisgICBoZWFkZXJQYXJhbXMgPSAmbGluZVtwYXJhbUluZGV4XTsKKyAgIHJldHVybiBU cnVlOwoKUHJvcGVydHkgY2hhbmdlcyBvbjogbmV0L2xpdmVNZWRpYS9maWxlcy9wYXRjaC1s aXZlTWVkaWEtUlRTUENsaWVudC5jcHAKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpBZGRlZDogZmJzZDpub2tl eXdvcmRzCiMjIC0wLDAgKzEgIyMKK3llcwpcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIHByb3Bl cnR5CkFkZGVkOiBzdm46ZW9sLXN0eWxlCiMjIC0wLDAgKzEgIyMKK25hdGl2ZQpcIE5vIG5l d2xpbmUgYXQgZW5kIG9mIHByb3BlcnR5CkFkZGVkOiBzdm46bWltZS10eXBlCiMjIC0wLDAg KzEgIyMKK3RleHQvcGxhaW4KXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBwcm9wZXJ0eQo= --------------080501070209050709030102 Content-Type: text/plain; charset=UTF-8; name="libproxy.patch.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="libproxy.patch.txt" SW5kZXg6IG5ldC9saWJwcm94eS9maWxlcy9wYXRjaC1saWJwcm94eV9tb2R1bGVfd3BhZF9k bnNfYWxpYXMuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIG5ldC9saWJwcm94eS9maWxlcy9wYXRj aC1saWJwcm94eV9tb2R1bGVfd3BhZF9kbnNfYWxpYXMuY3BwCShyZXZpc2lvbiAwKQorKysg bmV0L2xpYnByb3h5L2ZpbGVzL3BhdGNoLWxpYnByb3h5X21vZHVsZV93cGFkX2Ruc19hbGlh cy5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTAsMCArMSwxMSBAQAorLS0tIGxpYnByb3h5L21v ZHVsZXMvd3BhZF9kbnNfYWxpYXMuY3BwLm9yaWcJMjAxNC0wMS0xNCAwMDowNDoxMi41MjQ0 MTk3ODQgKzA5MDAKKysrKyBsaWJwcm94eS9tb2R1bGVzL3dwYWRfZG5zX2FsaWFzLmNwcAky MDE0LTAxLTE0IDAwOjA0OjI3LjMxMTQyMjQ2MiArMDkwMAorQEAgLTI3LDcgKzI3LDcgQEAK KyAJdm9pZCByZXdpbmQoKSAgICAgICAgICAgICAgeyBsYXN0dXJsID0gTlVMTDsgbGFzdHBh YyA9IE5VTEw7IH0KKyAKKyAJdXJsKiBuZXh0KGNoYXIqKiBwYWMpIHsKKy0JCWlmIChsYXN0 dXJsKSByZXR1cm4gZmFsc2U7CisrCQlpZiAobGFzdHVybCkgcmV0dXJuIE5VTEw7CisgCisg CQlsYXN0dXJsID0gbmV3IHVybCgiaHR0cDovL3dwYWQvd3BhZC5kYXQiKTsKKyAJCWxhc3Rw YWMgPSAqcGFjID0gbGFzdHVybC0+Z2V0X3BhYygpOwoKUHJvcGVydHkgY2hhbmdlcyBvbjog bmV0L2xpYnByb3h5L2ZpbGVzL3BhdGNoLWxpYnByb3h5X21vZHVsZV93cGFkX2Ruc19hbGlh cy5jcHAKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpBZGRlZDogc3ZuOm1pbWUtdHlwZQojIyAtMCwwICsxICMj Cit0ZXh0L3BsYWluClwgTm8gbmV3bGluZSBhdCBlbmQgb2YgcHJvcGVydHkKQWRkZWQ6IGZi c2Q6bm9rZXl3b3JkcwojIyAtMCwwICsxICMjCit5ZXMKXCBObyBuZXdsaW5lIGF0IGVuZCBv ZiBwcm9wZXJ0eQpBZGRlZDogc3ZuOmVvbC1zdHlsZQojIyAtMCwwICsxICMjCituYXRpdmUK XCBObyBuZXdsaW5lIGF0IGVuZCBvZiBwcm9wZXJ0eQo= --------------080501070209050709030102-- From owner-freebsd-toolchain@FreeBSD.ORG Wed Jan 22 17:27:52 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 438E4D58; Wed, 22 Jan 2014 17:27:52 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D7A991F23; Wed, 22 Jan 2014 17:27:51 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 93D9A4001E; Wed, 22 Jan 2014 18:27:49 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 89B1540019; Wed, 22 Jan 2014 18:27:49 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (unknown [94.254.45.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id C0E8E40017; Wed, 22 Jan 2014 18:27:46 +0100 (CET) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3f8YTt2r1wz8ggx; Wed, 22 Jan 2014 18:27:46 +0100 (CET) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([10.1.0.3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [10.1.0.6]) (amavisd-new, port 10025) with ESMTPS id as3BICPIvN8k; Wed, 22 Jan 2014 18:27:43 +0100 (CET) Received: from mail.daemonic.se (mail.daemonic.se [10.1.0.4]) by mx.daemonic.se (Postfix) with ESMTPS id 3f8YTp2tGmz8gh0; Wed, 22 Jan 2014 18:27:42 +0100 (CET) Received: from vivi.daemonic.se (vivi.daemonic.se [IPv6:2001:470:dca9:1::4]) by mail.daemonic.se (Postfix) with ESMTPSA id 3f8YTp2M6qz9Cvr; Wed, 22 Jan 2014 18:27:42 +0100 (CET) Message-ID: <52DFFF8E.70000@daemonic.se> Date: Wed, 22 Jan 2014 18:27:42 +0100 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Yamaya Takashi Subject: Re: [CFT] Update to clang 3.4 References: <541C998A-071A-4917-9D91-DD00CB0E2689@FreeBSD.org> <63BD3165-A62E-4FE7-9817-4A2692584916@bsdimp.com> <264FAA6E-871A-48AF-A8D9-EC431A537195@FreeBSD.org> <6766B735-98CB-4F1D-B3B5-A43D81BB558A@FreeBSD.org> <52D286BE.7000102@kbh.biglobe.ne.jp> <50EAAC3C-2D38-4409-B525-2608D39BFE70@FreeBSD.org> <52DFCCFF.8080002@daemonic.se> <52DFFF20.9000809@kbh.biglobe.ne.jp> In-Reply-To: <52DFFF20.9000809@kbh.biglobe.ne.jp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-toolchain@freebsd.org, Dimitry Andric X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 17:27:52 -0000 On 01/22/14 18:25, Yamaya Takashi wrote: > On 2014/01/22 22:51, Niclas Zeising wrote: >> On 01/12/14 17:21, Dimitry Andric wrote: >>> On 12 Jan 2014, at 13:12, Yamaya Takashi wrote: >>>> buildworld is failed when WITH_LLDB= >>> Yes, this is a known issue. I discussed it with Ed Maste. Clang 3.4 >>> will have to be imported first, afterwards we can fix lldb. >>> >>> >>>> some ports cannot build. >>>> >>>> reason1: clang cannot handle some options. >>>> (libmad build) >>>> cc: error: unknown argument: '-fforce-addr' >>>> cc: error: unknown argument: '-fthread-jumps' >>>> cc: error: unknown argument: '-fcse-follow-jumps' >>>> cc: error: unknown argument: '-fcse-skip-blocks' >>>> cc: error: unknown argument: '-fregmove' >>>> cc: error: unknown argument: '-fschedule-insns2' >>>> (libtheora build) >>>> cc: error: unknown argument: '-fforce-addr' >>>> (poppler build) >>>> c++: error: unknown argument: '-fno-check-new' >>>> (py27-sqlite build) >>>> cc: error: unknown argument: '-R/usr/local/lib' >>>> (tbb build) >>>> c++: error: unknown argument: '-fno-schedule-insns2' >>>> (gstreamer-ffmpeg build) >>>> cc: error: unknown argument: '-fno-force-addr' >>> Indeed, this is likely the most troublesome aspect of the upgrade. >>> >>> Most of the above options, like "-fcse-follow-jumps", "-fno-check-new", >>> etc are gcc-specific, and will never be supported by clang. These >>> options will have to be removed, or made conditional on the compiler. >>> >>> The -R option is not a compiler option, but an ld option, and is also >>> ambiguous: ld interprets it as --just-symbols when it is followed by the >>> name of a file, but as -rpath when it is followed by the name of a >>> directory. In all cases, this should be replaced with -Wl,-rpath. >>> >>> >>>> reason2: c++ -std=c++11 detect bad c++ code which older clang cannot detect. >>>> (libproxy build) >>>> /usr/ports/net/libproxy/work/libproxy-0.4.6/libproxy/modules/wpad_dns_alias.cpp:30:23: >>>> error: cannot initialize return object of type 'libproxy::url *' with an >>>> rvalue of type 'bool' >>>> if (lasturl) return false; >>>> ^~~~~ >>>> (liveMedia build) >>> I have not looked in detail at this one, but this looks like a simple >>> bug. The code should not return a boolean when the return type of the >>> function is a libproxy::url pointer. Should be easy to fix. >>> >>> The new C++11 rules make it possible to avoid 'casting' a false value to >>> a NULL pointer, and clang 3.4 detects this. >>> >>> >>>> c++ -c -Iinclude -I../UsageEnvironment/include -I../groupsock/include >>>> -I. -DBSD=1 -DSOCKLEN_T=socklen_t -D_LARGEFILE_SOURCE=1 >>>> -D_FILE_OFFSET_BITS=64 -DHAVE_SOCKADDR_LEN=1 -Wall -DBSD=1 -O2 -pipe >>>> -Qunused-arguments -march=native -fPIC -fno-strict-aliasing -std=c++11 >>>> -Wno-c++11-narrowing -stdlib=libc++ -Wno-deprecated RTSPRegisterSender.cpp >>>> RTSPClient.cpp:916:25: error: comparison between pointer and integer >>>> ('const char *' and 'int') >>>> if (&line[paramIndex] == '\0') return False; // the header is assumed >>>> to be bad if it has no parameters >>>> ~~~~~~~~~~~~~~~~~ ^ ~~~~ >>>> (mp4v2 build) >>> This looks like an incorrect comparison: a pointer is compared with a >>> literal character. Should be easy to fix. >>> >>> >>>> c++ -DHAVE_CONFIG_H -I./include -I./include -I. -I. -Wall -Wformat -O2 >>>> -pipe -Qunused-arguments -march=native -fno-strict-aliasing -std=c++11 >>>> -Wno-c++11-narrowing -stdlib=libc++ -fvisibility=hidden -c >>>> src/mp4container.cpp -fPIC -DPIC -o src/.libs/mp4container.o >>>> src/mp4.cpp:679:20: error: cannot initialize return object of type >>>> 'mp4v2_ismacrypParams *' (aka 'mp4v2_ismacryp_session_params *') with an >>>> rvalue of type 'MP4TrackId' (aka 'unsigned int') >>>> return MP4_INVALID_TRACK_ID; >>>> ^~~~~~~~~~~~~~~~~~~~ >>>> ./include/mp4v2/general.h:45:33: note: expanded from macro >>>> 'MP4_INVALID_TRACK_ID' >>>> #define MP4_INVALID_TRACK_ID ((MP4TrackId)0) /**< Constant: >>>> invalid MP4TrackId. */ >>>> ^~~~~~~~~~~~~~~ >>>> (thunderbird build) >>> Again, an attempt is made to use an incorrect type for the return value >>> of a function. Either the value should be explicitly cast to the >>> correct type (mp4v2_ismacrypParams *), or the MP4_INVALID_TRACK_ID >>> define should be fixed to be of the correct type. >>> >>> >>>> clang++ -o jsoptparse.o -c -I../../../dist/system_wrappers_js -include >>>> /usr/ports/mail/thunderbird/work/comm-esr24/mozilla/js/src/config/gcc_hidden.h >>>> -DEXPORT_JS_API -DIMPL_MFBT -DMOZ_GLUE_IN_PROGRAM -DNO_NSPR_10_SUPPORT >>>> -I/usr/ports/mail/thunderbird/work/comm-esr24/mozilla/js/src -I.. >>>> -I/usr/ports/mail/thunderbird/work/comm-esr24/mozilla/js/src/shell -I. >>>> -I../../../dist/include -I/usr/local/include/nspr -fPIC >>>> -Qunused-arguments -isystem/usr/local/include -Qunused-arguments -Wall >>>> -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits >>>> -Wempty-body -Werror=conversion-null -Wsign-compare >>>> -Wno-invalid-offsetof -Wno-c++0x-extensions -Wno-extended-offsetof >>>> -Wno-unknown-warning-option -Wno-return-type-c-linkage >>>> -Wno-mismatched-tags -O2 -pipe -Qunused-arguments -march=native -O3 >>>> -fno-strict-aliasing -std=c++11 -Wno-c++11-narrowing -stdlib=libc++ >>>> -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -pipe >>>> -DNDEBUG -DTRIMMED -O2 -O3 -fomit-frame-pointer -Qunused-arguments >>>> -isystem/usr/local/include -DMOZILLA_CLIENT -include ../js-confdefs.h >>>> -MD -MP -MF .deps/jsoptparse.o.pp /usr/ports/mail/thunderbir >>>> d/work/comm-esr24/mozilla/js/src/shell/jsoptparse.cpp >>>> /usr/ports/mail/thunderbird/work/comm-esr24/mozilla/js/src/shell/jsoptparse.cpp:256:22: >>>> error: comparison between pointer and integer ('char *' and 'int') >>>> if (value[0] == '\0') >>>> ~~~~~~~~ ^ ~~~~ >>> Like the mp4v2 build, this is probably a simple bug. The code should >>> not compare a pointer to an integer. Most likely, the right side was >>> supposed to be NULL instead? >>> >> I'm probably late to the party, as always... But, have you or Yamaya >> Takashi tried to punt these issues to the respective port managers for >> investigation? >> Regards! > I have patches for libproxy, liveMedia, mp4v2 and thunderbird. > > Send them to the respective maintainer. I've already sent a patch for thunderbird though, since I found one in their bugzilla. Regards! -- Niclas