From owner-freebsd-ports@FreeBSD.ORG Sun Mar 15 09:58:23 2015 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EBB7160D; Sun, 15 Mar 2015 09:58:23 +0000 (UTC) Received: from smtp1.tech.numericable.fr (smtp1.tech.numericable.fr [82.216.111.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ACC5AA04; Sun, 15 Mar 2015 09:58:23 +0000 (UTC) Received: from [192.168.0.14] (85-168-21-153.rev.numericable.fr [85.168.21.153]) by smtp1.tech.numericable.fr (Postfix) with ESMTP id 4B4FA140805; Sun, 15 Mar 2015 10:49:21 +0100 (CET) From: Manolo Gouy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: FreeBSD Port: seaview-4.5.2_1,1 Date: Sun, 15 Mar 2015 10:49:21 +0100 Message-Id: To: bofh@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeejledrjedtgddtiecutefuodetggdotefrucfrrhhofhhilhgvmecupfgfoffgtffkveetuefngfenuceurghilhhouhhtmecufedttdenucenucfjughrpefhtgfgufffkffvggfosehtqhhmtdhhtddvnecuhfhrohhmpeforghnohhlohcuifhouhihuceomhgrnhholhhordhgohhuhiesuhhnihhvqdhlhihonhdurdhfrheqnecuffhomhgrihhnpehunhhivhdqlhihohhnuddrfhhr Cc: ports@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 09:58:24 -0000 Hello, I believe you maintain the seaview package for freeBSD, and have found a = problem to link it. I believe it is now fixed in the last seaview source archive: = ftp://pbil.univ-lyon1.fr/pub/mol_phylogeny/seaview/seaview_4.5.3.4.tar.gz Please, let me know if there are still problems. Thank you for your help with distributing of seaview. Sincerely, = __________________________________________________________________________= | Manolo Gouy = =20 | Laboratoire de biometrie et biologie evolutive - UMR CNRS 5558 = =20 | Universite C. Bernard - Lyon 1 | E-MAIL : manolo.gouy@univ-lyon1.fr =20= | 43 Bd du 11 Novembre 1918 | Tel : +33 4-72-43-12-87 = =20 | 69622 Villeurbanne, France | Fax : +33 4-72-43-13-88 = =20 | = =20 | PBIL - Pole Bio-Informatique de Lyon http://pbil.univ-lyon1.fr = =20 = |_________________________________________________________________________= _ From owner-freebsd-ports@FreeBSD.ORG Sun Mar 15 10:00:00 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64EE36A6 for ; Sun, 15 Mar 2015 10:00:00 +0000 (UTC) Received: from nm23-vm9.access.bullet.mail.gq1.yahoo.com (nm23-vm9.access.bullet.mail.gq1.yahoo.com [216.39.62.70]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2BE95A14 for ; Sun, 15 Mar 2015 10:00:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s2048; t=1426413233; bh=ARldOe6DVCypz7ZxBJoWT5MqTocbvU5jzmbYNt2QH2s=; h=Date:From:To:CC:Subject:References:From:Subject; b=bJaAtdNgeKV4llpsFferXEAJk9SRUlXl4hgGIzqax5ECQTRKiGa8XtH/njRMA5I3RHSHl80pf+M1CUxCLkeUdFcQKT55r5BQKIic4LfarcxepcxEyrP0j4s8G0jgF+FCdWTjEvv0ttuPcB+3P8Q3PnPWR44BrbTXNjHoCgUTn2OSO4ECw5+CgoLR43KP+PkEJ0QPpxHWxwQ7URzywt4u/f6i4UjLlacT4hNb1O5bz7Xc1wpkAOPbAFKAuFnCqO4l/nmjcKl8TPSME6fUMwnPboPZae03CazHAAR/zzABQCuth/8GaFqqLmKBAKANgfRZQTLihHOUIdeoiJmwEGg32Q== Received: from [216.39.60.172] by nm23.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Mar 2015 09:53:53 -0000 Received: from [98.138.104.97] by tm8.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Mar 2015 09:53:53 -0000 Received: from [127.0.0.1] by smtp117.sbc.mail.ne1.yahoo.com with NNFMP; 15 Mar 2015 09:53:52 -0000 X-Yahoo-Newman-Id: 981488.10076.bm@smtp117.sbc.mail.ne1.yahoo.com Message-ID: <981488.10076.bm@smtp117.sbc.mail.ne1.yahoo.com> Date: Sun, 15 Mar 2015 09:53:52 +0000 (UTC) X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Y2G56DEVM1kuLczPs309pEblcbPFT0FNTW9Li.VXZY_Uhre ujMuGCXWeWjiAyoFS6VCVCPf0a9ZqRyf3_3ybQbDdbeGZWHvK_Oh4mdb9Ft_ oAeWzLswRrQs2CmkoMjh4ojBJ.0UA_NAuX0vMMfiEpv8gMy4vr3qGwqRdFW9 1lkAarIi7G3YdonpyHlrnCc1KVxbz2CYy3lxVCH0RHihUEYGd53OUZRuLZ5f V9oITr2ihNGeWk3sEEEFnRO0vz7HtJY6JAwjZr8tGt2.E0xpoNG3BR9CYK5x KLyj__npAGyqKGZsCmEh1Cncrem_qhDITgNlySVkTEzqYiEM2SxXV_CWo4T5 McpNAsrJOWJz63NsTRv9nujuTNN6o01W20m7Zz4wd9PXqbFodFtHvLp1ICe7 m2xILVwd6SmPmjYCYBf8PZA9bPRf6HWk6OEH1J9jNaBTq5BZ0BxIPNsYJDMT eMy78E767Dwdz_WzbJwo.VrJYphYkoLhZ5mt4xE8AblYYjKPh1mT_3JIJj9Z YiD5Xaha7GIsGRn.Q1Id_AoXxRQ.PCioD3Wrs1JZwlgxRtP1IZbdthX10mkN 1ZeEjyaIJLk0f_2AjdVxgHbgPncTC.A1eFwW50bAq5lmadke_jJb7kA8OicT htSqTNCQfOdUAez1YUmfijdNGiLgdpwyL6ndaUx.DWsq_K1hJNUUcI5cj_vq 5T0ex X-Yahoo-SMTP: Kz_aW1.swBBYof3zAD7.RWzXz9ZAQVDMml1VADsbgPT4Kq79LC0- From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Re: make installworld for i386 fails on Kyuafile References: <54EFDFB8.6020404@protected-networks.net> <20150227180746.GP17947@glebius.int.ru> Cc: Michael Butler , freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 10:00:00 -0000 > On Thu, Feb 26, 2015 at 10:08:40PM -0500, Michael Butler wrote: > M> The recent changes which served to hide "struct ifaddr" have broken > M> net-snmp: > I know and slowly working on that: > https://lists.freebsd.org/pipermail/svn-src-head/2015-February/068674.html > Totus tuus, Glebius. How will users know when this bug is fixed so that net-snmp will build on current? I was snagged on this as a dependency in trying to build print/hplip. Tom From owner-freebsd-ports@FreeBSD.ORG Sun Mar 15 13:47:49 2015 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5BF1B7C5; Sun, 15 Mar 2015 13:47:49 +0000 (UTC) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 19F6B288; Sun, 15 Mar 2015 13:47:49 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YX8tP-00090J-7C; Sun, 15 Mar 2015 14:47:47 +0100 Date: Sun, 15 Mar 2015 14:47:47 +0100 From: Kurt Jaeger To: Manolo Gouy Subject: Re: FreeBSD Port: seaview-4.5.2_1,1 Message-ID: <20150315134747.GP62590@home.opsec.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: ports@FreeBSD.org, bofh@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 13:47:49 -0000 Hi! > I believe you maintain the seaview package for freeBSD, and have > found a problem to link it. > I believe it is now fixed in the last seaview source archive: > ftp://pbil.univ-lyon1.fr/pub/mol_phylogeny/seaview/seaview_4.5.3.4.tar.gz PR with patch: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198602 -- pi@opsec.eu +49 171 3101372 5 years to go ! From owner-freebsd-ports@FreeBSD.ORG Sun Mar 15 21:18:52 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4964E656 for ; Sun, 15 Mar 2015 21:18:52 +0000 (UTC) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 16C7D8A4 for ; Sun, 15 Mar 2015 21:18:52 +0000 (UTC) Received: by pdbni2 with SMTP id ni2so38595098pdb.1 for ; Sun, 15 Mar 2015 14:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:message-id:to:subject:from:mime-version:content-type :content-transfer-encoding; bh=SOgyBqOjS8aNfYGKsIXDNkmTmtKRqLq153tR+a4ocKs=; b=DxMn0n3pGPb2h1Vefo0V4oA+RsfMRMdszqxUwyjgVkB8ogTgQTKDRk9Yxx0k0Y5hkb tXe2o5wyISrvCwXk5hguShNo2qDB4OMsWcYJYOhwo0q2TTpCrrcearedgUCJx17TM+4E skMZH7l+l+GEYKdN6DElnPzfPyhT/P4XLffvZzl/BsBhNyUIvWub1hoZYFsAKtvIr3pw uYznL8wUB4l95Eiokotec+G1re1VW0g7FQBUuIPM3avmgfmwu0qrkL0CEs2F7NTw4Bz9 bXPtI1gj+L1bPukpyAMJoIg9ec7hk+XfZb/odoLbCWNTEO4kjGYsauG0rYYyRDV5udA5 3ZnQ== X-Received: by 10.70.123.131 with SMTP id ma3mr101972335pdb.16.1426454331489; Sun, 15 Mar 2015 14:18:51 -0700 (PDT) Received: from localhost (gl10-157.gl10.cilas.net. [61.208.136.157]) by mx.google.com with ESMTPSA id f12sm13774665pat.43.2015.03.15.14.18.50 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 15 Mar 2015 14:18:50 -0700 (PDT) Date: Mon, 16 Mar 2015 06:18:48 +0900 (JST) Message-Id: <20150316.061848.1864035119234175291.mika.xoxo@gmail.com> To: freebsd-ports@freebsd.org Subject: x11-wm/afterstep-i18n From: Mika Xoxo X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 21:18:52 -0000 Until when will x11-wm/afterstep-i18n be "marked as broken"? -- mika From owner-freebsd-ports@FreeBSD.ORG Mon Mar 16 05:09:54 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 387728BB for ; Mon, 16 Mar 2015 05:09:54 +0000 (UTC) Received: from masa.qt7.net (masa.qt7.net [104.140.67.88]) by mx1.freebsd.org (Postfix) with ESMTP id EB2616D for ; Mon, 16 Mar 2015 05:09:53 +0000 (UTC) To: freebsd-ports@freebsd.org Subject: wish to introduce our fleece blankets and bathrobes factory Message-ID: <3e695f37d7aec235f2ec7fd7d4e26386@canon.com> Date: Mon, 16 Mar 2015 06:06:16 +0100 From: "James" Reply-To: wanshancon@tom.com MIME-Version: 1.0 X-Mailer-LID: 26 X-Mailer-RecptId: 20219488 X-Mailer-SID: 118 X-Mailer-Sent-By: 1 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 05:09:54 -0000 We wish to introduce our fleece blankets and bathrobes factory Our factory based in China has been engaged in the manufacture and sales of fleece products for many years. Over the past years, we have got much professional experience in this industry. We produce below: polar fleece blankets micro coral fleece blankets picnic blankets cushions/cushion covers baby blankets embroidered blankets bathrobes voile curtains sauna quits fleece clothing washmachine covers Our products have been exported to North Amercia, Europe, Japan and so on. We are looking forward to start business with you soon. Best regards: James Contact: rightmm@tom.com From owner-freebsd-ports@FreeBSD.ORG Mon Mar 16 09:43:06 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B200E18 for ; Mon, 16 Mar 2015 09:43:06 +0000 (UTC) Received: from portscout.freebsd.org (portscout.freebsd.org [IPv6:2001:1900:2254:206a::50:6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 66D89FBF for ; Mon, 16 Mar 2015 09:43:06 +0000 (UTC) Received: from portscout.freebsd.org ([127.0.1.123]) by portscout.freebsd.org (8.14.9/8.14.9) with ESMTP id t2G9h66c007989 for ; Mon, 16 Mar 2015 09:43:06 GMT (envelope-from portscout@FreeBSD.org) Received: (from portscout@localhost) by portscout.freebsd.org (8.14.9/8.14.9/Submit) id t2G9h6xD007988; Mon, 16 Mar 2015 09:43:06 GMT (envelope-from portscout@FreeBSD.org) Message-Id: <201503160943.t2G9h6xD007988@portscout.freebsd.org> X-Authentication-Warning: portscout.freebsd.org: portscout set sender to portscout@FreeBSD.org using -f Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain MIME-Version: 1.0 Date: Mon, 16 Mar 2015 09:43:06 +0000 From: portscout@FreeBSD.org To: ports@freebsd.org Subject: FreeBSD ports you maintain which are out of date X-Mailer: portscout/0.8.1 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 09:43:06 -0000 Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/ports@freebsd.org.html Port | Current version | New version ------------------------------------------------+-----------------+------------ print/lilypond-devel | 2.19.11 | 2.19.17 ------------------------------------------------+-----------------+------------ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. From owner-freebsd-ports@FreeBSD.ORG Mon Mar 16 10:17:54 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72975893; Mon, 16 Mar 2015 10:17:54 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E75D73C4; Mon, 16 Mar 2015 10:17:53 +0000 (UTC) Received: by lagg8 with SMTP id g8so35468567lag.1; Mon, 16 Mar 2015 03:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version; bh=6NfF15IpFKUdiPendQVhwL26X/sMw+WO01mm25eb8wM=; b=yhjc0jJG+J4TXpkHyEomO7/llM1vCaW2q4EeOCD5OD2GcmIIx1ywKfBZDrP9lonKZK dr9vHinhynrB7Nvi1WAGqys7XwoUDxUvPP63WKHs0MBSRW7VM+0bmeepFTle7ckJdqlS Mm/mjn50maer0O+Jsr+IqbdmEHA6k+rLIRSRyIbbIitxCWr8HwaNwRGMKfkjaFB9Hr/b 2l6fz/+137pu3TVN70Qkh0weECV0ycNbXL1jcmZ3allWyUTzgIfmesVThaUxTeaQKuGK udA/n5Qvsc2juuPl7o4UpXRmoDoAmAzBaw89ut9WQv2RRTmSvyJGZif/YKXsmu/K2kTG Et8g== X-Received: by 10.112.173.41 with SMTP id bh9mr53631244lbc.107.1426501071924; Mon, 16 Mar 2015 03:17:51 -0700 (PDT) Received: from [192.168.1.101] ([80.253.17.36]) by mx.google.com with ESMTPSA id ds8sm2107019lbb.18.2015.03.16.03.17.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Mar 2015 03:17:51 -0700 (PDT) From: Zalysin Maxim Subject: FreeBSD Port: php5-5.4.38 Date: Mon, 16 Mar 2015 13:17:50 +0300 Message-Id: <7003428C-8604-4E48-83F1-1C5FA763947B@gmail.com> To: ale@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: ports@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 10:17:54 -0000 Hello! I am write more functional rc.d script for php-fpm - = https://github.com/MAXuk/php-fpm-rc-script = This script tested on php5.3, php5.4 and php5.6. Maybe it will be interesting to your and added this in freebsd ports. Thanks. =E2=80=94 Maxim Zalysin From owner-freebsd-ports@FreeBSD.ORG Mon Mar 16 20:50:31 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7B7F309 for ; Mon, 16 Mar 2015 20:50:31 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E6CE2FF for ; Mon, 16 Mar 2015 20:50:31 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-ports@freebsd.org with esmtp (envelope-from ) id <1YXbuR-000XIM-Ir>; Mon, 16 Mar 2015 21:46:47 +0100 Received: from g224248125.adsl.alicedsl.de ([92.224.248.125] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-ports@freebsd.org with esmtpsa (envelope-from ) id <1YXbuR-000Xac-G9>; Mon, 16 Mar 2015 21:46:47 +0100 Date: Mon, 16 Mar 2015 21:46:43 +0100 From: "O. Hartmann" To: FreeBSD Ports Subject: textproc/clucene: pkg-static: sqlite error while executing INSERT OR REPLACE INTO packages Message-ID: <20150316214643.3c6ab7f1.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/JwjWGT414bdHXDi6TzD1SZh"; protocol="application/pgp-signature" X-Originating-IP: 92.224.248.125 X-ZEDAT-Hint: A X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 20:50:31 -0000 --Sig_/JwjWGT414bdHXDi6TzD1SZh Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Since today's CURRENT update (running FreeBSD 11.0-CURRENT #1 r280149: Mon = Mar 16 19:41:00 CET 2015 amd64) I receive this nasty error on a box while updating= ports: textproc/clucene: Installing clucene-2.3.3.4_5... pkg-static: sqlite error while executing IN= SERT OR REPLACE INTO packages( origin, name, version, comment, desc, message, arch,= maintainer, www, prefix, flatsize, automatic, licenselogic, mtree_id, time, manifestdig= est) VALUES( ?1, ?2, ?3, ?4, ?5, ?6, ?7, ?8, ?9, ?10, ?11, ?12, ?13, (SELECT id = FROM mtree WHERE content =3D ?14), NOW(), ?15) in file pkgdb.c:1602: FOREIGN KEY const= raint failed *** Error code 70 It seems that something went wrong after the system's update and I have no = clue what it could mean. Filesystem doesn't seem to be corrupted. Is there a way to solve this problem? Please CC me, I'm not subscribing the list. Regards and thanks in advance, Oliver=20 --Sig_/JwjWGT414bdHXDi6TzD1SZh Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVB0EzAAoJEOgBcD7A/5N8eroH/3ewBClBsBPL4/tHtjweosLn 6pr/mJGPdIbBmgv1isiSB6OYraBz8F2Q6Do1+NXjVhXpGMbcvhxRXSd8fQ/EQmfB d4HwTnMgjIjALQgGRpYSt2GVY5Py4hQ3j4WM2pRb141L0FLoTKSHDbsc/3FOV3ob eINqgMXwK8flDUHn8HeXR0EAGVjazXW9ToGJQ2bnt/4/srVW3yqYum1ait3lx79Z md9ddG2lLI0N/0EJS/arWeA8F3HD3x8H7b1tvEmqs8iLiVMozTpzMaMpvZwTmAfL H+OuTe1TSDXO7UmzIsMcTLiIAP5NdDYPMYMwR/aSU6lcgKXapCVIh632fPUk/7k= =mKo6 -----END PGP SIGNATURE----- --Sig_/JwjWGT414bdHXDi6TzD1SZh-- From owner-freebsd-ports@FreeBSD.ORG Mon Mar 16 21:33:30 2015 Return-Path: Delivered-To: freebsd-ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80BF6350; Mon, 16 Mar 2015 21:33:30 +0000 (UTC) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 01C93AD6; Mon, 16 Mar 2015 21:33:30 +0000 (UTC) Received: by lbcgn8 with SMTP id gn8so29442221lbc.2; Mon, 16 Mar 2015 14:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=Lx46f+DeXkj/hFgeoy8+8LHPXokEkgtB+xxxMRqaq4g=; b=bwfJYOP3k8sedsPAwRqAm5x4ZHS3ZfqrYXoO8+qv3K0HWXgOiqkC1IGesRfXyQ5C/i AzGJkTE4AJfWPGUe459cF4mGPfFIN802Ewi0dkIb34AgDIgynt55I8Od1e3EY/MHNvdi zDIdZwixCrZOblvHHKaM8tVfaLTU0qto7dtpC1d6ANTJmzMND+4b9TYEw5pzHE/cmB4P V7gCdMt1y4cmHXl9L96th9DETUXuPjrUg3trz5jYfhLc0W/8exrAKPKGoTbzj6PErdSw 4XOgOt9BRvS4CEP9jcxP6E37WK4wDiMPaYROO+QvWtKVGLyrGjyMN5w4OBMiMgCVezyn TkPQ== MIME-Version: 1.0 X-Received: by 10.112.170.132 with SMTP id am4mr56763534lbc.89.1426541607988; Mon, 16 Mar 2015 14:33:27 -0700 (PDT) Sender: jlehen@gmail.com Received: by 10.114.183.145 with HTTP; Mon, 16 Mar 2015 14:33:27 -0700 (PDT) Date: Mon, 16 Mar 2015 22:33:27 +0100 X-Google-Sender-Auth: iJJGVkO9JjGBBUBqerefByzuAZQ Message-ID: Subject: net/unison240 depends on lang/ocaml-nox11 From: Jeremie Le Hen To: madpilot@FreeBSD.org Content-Type: text/plain; charset=UTF-8 Cc: freebsd-ports@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 21:33:30 -0000 Hi Guido, I saw you recently submitted net/unison240 but it depends on lang/ocaml-nox11. This is a problem with using poudriere: [00:00:58] ====>> Error: Duplicated origin for ocaml-nox11-4.01.0_4: lang/ocaml-nox11 AND lang/ocaml. Rerun with -vv to see which ports are depending on these. Would you mind making it similar to www/unison232? This one works correctly. Thanks a lot. Cheers, -- Jeremie Le Hen jlh@FreeBSD.org From owner-freebsd-ports@FreeBSD.ORG Mon Mar 16 21:37:29 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57CD1561; Mon, 16 Mar 2015 21:37:29 +0000 (UTC) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C850DB64; Mon, 16 Mar 2015 21:37:28 +0000 (UTC) Received: by lbcds1 with SMTP id ds1so40357319lbc.3; Mon, 16 Mar 2015 14:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=14uKPg3UtPuyaBpnFtk63qW4Xi/QsUtP37qdMyl5pfI=; b=kQyKFwvru7C/2xmrNaE1hIcIR7cwB73wPKhmC0DcwJ9JS5WwVwLGY/9Tty98M6Q0AK dabJ0eZOjulFbMKLsdfioIGNOwTZrW5rvYKMmFPKPWuejtsnkTVMtp0rlgSdSkRKXtxk s8m7AlA1BhdAdPgukZV2k5NRwYxO+SUH58pB0uzN39RreY07GOI1a+EwlWUMk3mWaw+d tEkTyH8Ql1RwyMuY2K0GJ4Jsn60FmjRjNr5oL3iSqMobgkTknTdcul28NHC38Xvf7Chr qSJFNA3h3h/mRJ5TA60GsniJQ1r7cR8Xs3IDkoAUoN95J52qq1Sv5thO5ICCEXNeD+4q 5YVg== MIME-Version: 1.0 X-Received: by 10.152.21.99 with SMTP id u3mr56777299lae.105.1426541846750; Mon, 16 Mar 2015 14:37:26 -0700 (PDT) Sender: jlehen@gmail.com Received: by 10.114.183.145 with HTTP; Mon, 16 Mar 2015 14:37:26 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Mar 2015 22:37:26 +0100 X-Google-Sender-Auth: 1nnHizM8uopkHODgRVXlOUsr27I Message-ID: Subject: Re: net/unison240 depends on lang/ocaml-nox11 From: Jeremie Le Hen To: madpilot@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 21:37:29 -0000 Actually, I've just realized that I fixed net/unison232 in my local tree :o). Would you mind submitting it and applying the same for unison240? Here is the patch: Index: Makefile =================================================================== --- Makefile (revision 381259) +++ Makefile (working copy) @@ -34,20 +34,18 @@ .include +BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml .if ${PORT_OPTIONS:MX11} MAKE_ARGS+= UISTYLE=gtk2 PLIST_SUB+= TEXT="" -BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml \ - lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 \ +BUILD_DEPENDS+= lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 \ icotool:${PORTSDIR}/graphics/icoutils RUN_DEPENDS+= lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 PATCH_DEPENDS+= ${BUILD_DEPENDS} -CONFLICTS+= ocaml-nox11* SUB_FILES+= ${PORTNAME}.desktop .else MAKE_ARGS+= UISTYLE=text PLIST_SUB+= TEXT="@comment " -BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml-nox11 PATCH_DEPENDS+= ${BUILD_DEPENDS} .endif On Mon, Mar 16, 2015 at 10:33 PM, Jeremie Le Hen wrote: > Hi Guido, > > I saw you recently submitted net/unison240 but it depends on > lang/ocaml-nox11. This is a problem with using poudriere: > > [00:00:58] ====>> Error: Duplicated origin for ocaml-nox11-4.01.0_4: > lang/ocaml-nox11 AND lang/ocaml. Rerun with -vv to see which ports are > depending on these. > > Would you mind making it similar to www/unison232? This one works correctly. > > Thanks a lot. > Cheers, > -- > Jeremie Le Hen > jlh@FreeBSD.org -- Jeremie Le Hen jlh@FreeBSD.org From owner-freebsd-ports@FreeBSD.ORG Mon Mar 16 22:13:07 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F66FBCE; Mon, 16 Mar 2015 22:13:07 +0000 (UTC) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BED3FF0A; Mon, 16 Mar 2015 22:13:05 +0000 (UTC) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3l5X1w6MP8zbHN; Mon, 16 Mar 2015 23:12:52 +0100 (CET) Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id wak_NxePCwup; Mon, 16 Mar 2015 23:12:48 +0100 (CET) Received: from tommy.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Mon, 16 Mar 2015 23:12:44 +0100 (CET) Message-ID: <5507555C.7030508@FreeBSD.org> Date: Mon, 16 Mar 2015 23:12:44 +0100 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Jeremie Le Hen Subject: Re: net/unison240 depends on lang/ocaml-nox11 References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 22:13:07 -0000 On 03/16/15 22:37, Jeremie Le Hen wrote: > Actually, I've just realized that I fixed net/unison232 in my local tree :o). > > Would you mind submitting it and applying the same for unison240? > I never noticed this since it never happened to me and nobody else reported it. Anyway now that you draw my attention, yes, it needs fixing. Your patch looks correct, but please allow me a little time for some testing. Thanks for bringing this up! >> [00:00:58] ====>> Error: Duplicated origin for ocaml-nox11-4.01.0_4: >> lang/ocaml-nox11 AND lang/ocaml. Rerun with -vv to see which ports are >> depending on these. Just to be sure I get it right, is this error reported at the start of the run while "Calculating ports order and dependencies"? -- Guido Falsi From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 00:04:43 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3BAA577 for ; Tue, 17 Mar 2015 00:04:43 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2D71AD09 for ; Tue, 17 Mar 2015 00:04:42 +0000 (UTC) Received: (qmail 29103 invoked from network); 17 Mar 2015 00:04:41 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 17 Mar 2015 00:04:41 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 16 Mar 2015 20:04:41 -0400 (EDT) Received: (qmail 7241 invoked from network); 17 Mar 2015 00:04:41 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Mar 2015 00:04:41 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id B2A101C439E; Mon, 16 Mar 2015 17:04:35 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc64 11.0-CURRENT portmaster lang/clang36 gets error: llvm-build: error: invalid native target: 'powerpc64' (not in project) Date: Mon, 16 Mar 2015 17:04:38 -0700 Message-Id: <9682273F-8B85-4351-AB2B-011240D40327@dsl-only.net> To: FreeBSD PowerPC ML , freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 00:04:43 -0000 Basic context (more context details listed later): # freebsd-version -ku; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar = 11 19:23:14 PDT 2015 = root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBU= G powerpc powerpc64 The problem: portmaster -tDK --no-confirm lang/clang36 is how I started the build. The error report was after it reported entering the directory: = /usr/obj/portswork/usr/ports/lang/clang36/work/llvm-3.6.0.src/tools/clang/= lib/Driver/ The report was: llvm-build: error: invalid native target: 'powerpc64' (not in project) I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. But powerpc64 = likely does. I've not yet tried from a powerpc (non-64) FreeBSD build. I'll note that with top -PaSCHopid I watched it compile the PowerPc code = generator software: it shoudl be able to handle PowerPCs fine. My guess is a conversion of naming conventions is required someplace: FreeBSD using powerpc64 vs. clang using ppc64. (Big endian context.) This likely would matter for little endian naming as well (ppc64le on = the clang end of things I expect).=20 Context details: # svnlite info /usr/ports/lang/clang36 Path: lang/clang36 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 Relative URL: ^/head/lang/clang36 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: brooks Last Changed Rev: 380295 Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) It used gcc5 to bootstrap as there was no clang present and that is the = only gcc port installed: # svnlite info /usr/ports/lang/gcc5 Path: lang/gcc5 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 Relative URL: ^/head/lang/gcc5 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: gerald Last Changed Rev: 380943 Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) # more /etc/make.conf #CPP=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 00:18:44 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 696B8973 for ; Tue, 17 Mar 2015 00:18:44 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C8A8E0A for ; Tue, 17 Mar 2015 00:18:43 +0000 (UTC) Received: (qmail 26293 invoked from network); 17 Mar 2015 00:18:42 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 17 Mar 2015 00:18:42 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 16 Mar 2015 20:18:42 -0400 (EDT) Received: (qmail 19751 invoked from network); 17 Mar 2015 00:18:42 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Mar 2015 00:18:42 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 7A18E1C439E; Mon, 16 Mar 2015 17:18:36 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared Date: Mon, 16 Mar 2015 17:18:40 -0700 Message-Id: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> To: FreeBSD PowerPC ML , freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 00:18:44 -0000 Basic context (more context details listed later): # freebsd-version -ku; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar = 11 19:23:14 PDT 2015 = root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBU= G powerpc powerpc64 The problem: portmaster -tDK --no-confirm lang/clang36 is how I started the build. The error reported was for in MSVCToolChain.cpp's member function: bool = clang::driver::toolchains::getWindowsSDKDir(std::__cxx1:string&,int&, = int&) const The report was: MSVCToolChain.cpp:25:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. And it not = being likely to be powerpc64 specific would be my guess. May be that it = bootstrapped via gcc5? I've not yet tried from a powerpc (non-64) = FreeBSD build. Context details: # svnlite info /usr/ports/lang/clang36 Path: lang/clang36 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 Relative URL: ^/head/lang/clang36 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: brooks Last Changed Rev: 380295 Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) It used gcc5 to bootstrap as there was no clang present and that is the = only gcc port installed: # svnlite info /usr/ports/lang/gcc5 Path: lang/gcc5 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 Relative URL: ^/head/lang/gcc5 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: gerald Last Changed Rev: 380943 Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) # more /etc/make.conf #CPP=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 01:23:39 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F407535E; Tue, 17 Mar 2015 01:23:38 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D2C3267F; Tue, 17 Mar 2015 01:23:38 +0000 (UTC) Received: from aurora.physics.berkeley.edu (aurora.Physics.Berkeley.EDU [128.32.117.67]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t2H1NTvP022641 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Mar 2015 18:23:29 -0700 Message-ID: <55078211.3080704@freebsd.org> Date: Mon, 16 Mar 2015 18:23:29 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Mark Millard , FreeBSD PowerPC ML , freebsd-ports@freebsd.org Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared References: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> In-Reply-To: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVbki42I0w1WY536Vq8nkEm3UQN1elqms+XgDHEmLZxnMD3yStWm3+Fv9jS3Nc6joLWZU8DGcS5xrn3NU0n3CqGney3AUyROb8U= X-Sonic-ID: C;OM7yN0TM5BG+Gr5YxQPdhw== M;znwhOETM5BG+Gr5YxQPdhw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 01:23:39 -0000 Which compiler are you building with? Just using the normal lang/gcc works for me without issue doing make install in lang/clang36. Are you sure you don't have any local diffs or stale files? -Nathan On 03/16/15 17:18, Mark Millard wrote: > Basic context (more context details listed later): > > # freebsd-version -ku; uname -ap > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 11 19:23:14 PDT 2015 root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc powerpc64 > > > The problem: > > portmaster -tDK --no-confirm lang/clang36 is how I started the build. > > The error reported was for in MSVCToolChain.cpp's member function: > > bool clang::driver::toolchains::getWindowsSDKDir(std::__cxx1:string&,int&, int&) const > > The report was: > > MSVCToolChain.cpp:25:5: error: '::sscanf' has not been declared > ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); > > > I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. And it not being likely to be powerpc64 specific would be my guess. May be that it bootstrapped via gcc5? I've not yet tried from a powerpc (non-64) FreeBSD build. > > > > Context details: > > # svnlite info /usr/ports/lang/clang36 > Path: lang/clang36 > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 > Relative URL: ^/head/lang/clang36 > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 381120 > Node Kind: directory > Schedule: normal > Last Changed Author: brooks > Last Changed Rev: 380295 > Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) > > It used gcc5 to bootstrap as there was no clang present and that is the only gcc port installed: > > # svnlite info /usr/ports/lang/gcc5 > Path: lang/gcc5 > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 > Relative URL: ^/head/lang/gcc5 > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 381120 > Node Kind: directory > Schedule: normal > Last Changed Author: gerald > Last Changed Rev: 380943 > Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) > > # more /etc/make.conf > #CPP=clang-cpp > #CC=clang > #CXX=clang++ > WRKDIRPREFIX=/usr/obj/portswork > #WITH_DEBUG= > MALLOC_PRODUCTION= > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org" > From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 03:00:59 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B865F79 for ; Tue, 17 Mar 2015 03:00:59 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D4B9DF89 for ; Tue, 17 Mar 2015 03:00:58 +0000 (UTC) Received: (qmail 10817 invoked from network); 17 Mar 2015 03:00:57 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 17 Mar 2015 03:00:57 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 16 Mar 2015 23:00:57 -0400 (EDT) Received: (qmail 31494 invoked from network); 17 Mar 2015 03:00:56 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Mar 2015 03:00:56 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 3438A1C4052; Mon, 16 Mar 2015 20:00:50 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared From: Mark Millard In-Reply-To: <55078211.3080704@freebsd.org> Date: Mon, 16 Mar 2015 20:00:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <13ED08B5-0FC7-43CC-A5DA-73C9AA2D5220@dsl-only.net> References: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> <55078211.3080704@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 03:00:59 -0000 > On 2015-Mar-16, at 06:23 PM, Nathan Whitehorn = wrote: >=20 > Which compiler are you building with? Just using the normal lang/gcc = works for me without issue doing make install in lang/clang36. Are you = sure you don't have any local diffs or stale files? > -Nathan Quoting for the "which compiler" part: "It used gcc5 to bootstrap as = there was no clang present and that is the only gcc port installed". The evidence for this was watching top -PaSCHopid while it worked on the = installation. As for the FBSDG5C0 SSD's 11.0-CURRENT history for compilers: gcc 4.2.1 present. clang not present. (Not 3.4.1, not 3.5, not 3.6. 3.4.1 was lost in the 10.1-STABLE -> 11.0-CURRENT conversion when I did = delete-old, not realizing that I'd end up with no clang at all and no obvious way = to build one on the powerpc64s/powerpcs.) (None of the below were ever on any 10.1-STABLE SSD as of when I did the = copies and conversion of some to 11.0-CURRENT.) powerpc64-xtoolchain-gcc present (and so powerpc64-gcc), installed = recently for the first time ever. This was the first ever = not-built-into-world compiler that I've installed on any media. The = powerpc64-gcc installer has a file naming problem for powerpc64 hosts I = had to put copies of 5 files that it created under the names it later = looked for them to finish this install (names not prefixed -> prefixed, = one file copied to another place). gcc5 installed just days ago, the second ever ports-compiler installed. = The install had no problems. I will note that I have started an installation of lang/clang36 on a = powerpc (non-64) 11.0-CURRENT that has/had only gcc 4.2.1 and clang = 3.4.1. Watching with top -PaSCHopid shows that it is doing a lang/gcc = installation as part of its bootstrap, at this point that means 4.8.4. So it is not using gcc 4.2.1. Again for this SSD there is no history of = compiler installs other than those that are part of world. clang 3.4.1 = exists because I did not get around to doing delete-old before I noticed = that I ended up with no clang as a result. This is the only copy of = clang 3.4.1 that survived my ignorance to end up on 11.0-CURRENT. I have another powerpc (non-64) 11.0-CURRENT SSD that does not have = powerpc64-gcc nor clang but does have gcc5 already. Again gcc5 installed = in the last few days. Again before the installation there had only ever = been built-into-world compilers. I've started a lang/CLANG36 install = here as well. We will see how each of these goes. Side note: You can tell I got past the booting/memory-corruption = problems on the G5 PowerMacs recently (via Powermac specific builds). = I'm now exploring other things in FreeBSD. :) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 06:23 PM, Nathan Whitehorn = wrote: Which compiler are you building with? Just using the normal lang/gcc = works for me without issue doing make install in lang/clang36. Are you = sure you don't have any local diffs or stale files? -Nathan On 03/16/15 17:18, Mark Millard wrote: > Basic context (more context details listed later): >=20 > # freebsd-version -ku; uname -ap > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed = Mar 11 19:23:14 PDT 2015 = root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBU= G powerpc powerpc64 >=20 >=20 > The problem: >=20 > portmaster -tDK --no-confirm lang/clang36 is how I started the build. >=20 > The error reported was for in MSVCToolChain.cpp's member function: >=20 > bool = clang::driver::toolchains::getWindowsSDKDir(std::__cxx1:string&,int&, = int&) const >=20 > The report was: >=20 > MSVCToolChain.cpp:25:5: error: '::sscanf' has not been declared > ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); >=20 >=20 > I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. And it not = being likely to be powerpc64 specific would be my guess. May be that it = bootstrapped via gcc5? I've not yet tried from a powerpc (non-64) = FreeBSD build. >=20 >=20 >=20 > Context details: >=20 > # svnlite info /usr/ports/lang/clang36 > Path: lang/clang36 > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 > Relative URL: ^/head/lang/clang36 > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 381120 > Node Kind: directory > Schedule: normal > Last Changed Author: brooks > Last Changed Rev: 380295 > Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) >=20 > It used gcc5 to bootstrap as there was no clang present and that is = the only gcc port installed: >=20 > # svnlite info /usr/ports/lang/gcc5 > Path: lang/gcc5 > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 > Relative URL: ^/head/lang/gcc5 > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 381120 > Node Kind: directory > Schedule: normal > Last Changed Author: gerald > Last Changed Rev: 380943 > Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) >=20 > # more /etc/make.conf > #CPP=3Dclang-cpp > #CC=3Dclang > #CXX=3Dclang++ > WRKDIRPREFIX=3D/usr/obj/portswork > #WITH_DEBUG=3D > MALLOC_PRODUCTION=3D >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" >=20 From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 03:37:54 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D9B0E4B for ; Tue, 17 Mar 2015 03:37:54 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 36460642 for ; Tue, 17 Mar 2015 03:37:53 +0000 (UTC) Received: (qmail 20630 invoked from network); 17 Mar 2015 03:37:52 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 17 Mar 2015 03:37:52 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 16 Mar 2015 23:37:52 -0400 (EDT) Received: (qmail 23711 invoked from network); 17 Mar 2015 03:37:52 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Mar 2015 03:37:52 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id AD09C1C439E; Mon, 16 Mar 2015 20:37:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared From: Mark Millard In-Reply-To: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> Date: Mon, 16 Mar 2015 20:37:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <722DBABA-1E03-434E-ACB4-55A1E69E8AAA@dsl-only.net> References: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> To: FreeBSD PowerPC ML , freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 03:37:54 -0000 I tried "portmaster -tDK --no-confirm lang/clang36" on a powerpc = (non-64): $ freebsd-version -ku ; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Mon Mar = 9 22:24:27 PDT 2015 = root@FBSDG4S0:/usr/obj/usr/srcC/sys/GENERICvtsc-NODEBUG powerpc powerpc Again it used gcc5 to bootstrap, my having installed gcc5 recently, no = other non-built-in-world compilers ever having been installed before. No = clang of any kind to start with. Just gcc 4.2.1. No changes to = lang/clang36. Just: portmaster -tDK --no-confirm lang/clang36 Again it had the same MSVCToolChain.cpp problem: llvm[4]: Compiling MSVCToolChain.cpp for Release build MSVCToolChain.cpp: In member function 'bool = clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::__cxx11::s= tring&, int&, int&) const': MSVCToolChain.cpp:215:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); ^ Like before when I had installed gcc5 it had no troubles installing and = I made no changes. I have another build test running where only built-in-world compilers = existed (gcc 4.2.1 and clang 3.4.1). For this context "portmaster -tDK = --no-confirm lang/clang36" initiated installing lang/gcc (i.e., 4.8.4 at = this point) in order to provide itself with a compiler to bootstrap = with. We will see how that one does. It takes longer since 2 compilers = are being installed. (I started this one first but it is not done yet.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 05:18 PM, Mark Millard = wrote: Basic context (more context details listed later): # freebsd-version -ku; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar = 11 19:23:14 PDT 2015 = root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBU= G powerpc powerpc64 The problem: portmaster -tDK --no-confirm lang/clang36 is how I started the build. The error reported was for in MSVCToolChain.cpp's member function: bool = clang::driver::toolchains::getWindowsSDKDir(std::__cxx1:string&,int&, = int&) const The report was: MSVCToolChain.cpp:25:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. And it not = being likely to be powerpc64 specific would be my guess. May be that it = bootstrapped via gcc5? I've not yet tried from a powerpc (non-64) = FreeBSD build. Context details: # svnlite info /usr/ports/lang/clang36 Path: lang/clang36 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 Relative URL: ^/head/lang/clang36 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: brooks Last Changed Rev: 380295 Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) It used gcc5 to bootstrap as there was no clang present and that is the = only gcc port installed: # svnlite info /usr/ports/lang/gcc5 Path: lang/gcc5 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 Relative URL: ^/head/lang/gcc5 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: gerald Last Changed Rev: 380943 Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) # more /etc/make.conf #CPP=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 05:36:54 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E9CAA23 for ; Tue, 17 Mar 2015 05:36:54 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 45A04102 for ; Tue, 17 Mar 2015 05:36:53 +0000 (UTC) Received: (qmail 3343 invoked from network); 17 Mar 2015 05:36:52 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 17 Mar 2015 05:36:52 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 17 Mar 2015 01:36:52 -0400 (EDT) Received: (qmail 24173 invoked from network); 17 Mar 2015 05:36:52 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Mar 2015 05:36:52 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id DCEA41C4052; Mon, 16 Mar 2015 22:36:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared From: Mark Millard In-Reply-To: <722DBABA-1E03-434E-ACB4-55A1E69E8AAA@dsl-only.net> Date: Mon, 16 Mar 2015 22:36:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> <722DBABA-1E03-434E-ACB4-55A1E69E8AAA@dsl-only.net> To: FreeBSD PowerPC ML , freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 05:36:54 -0000 The last powerpc (non-64) build test to complete ran where only = built-in-world compilers originally existed (gcc 4.2.1 and clang 3.4.1 = this time. For this context "portmaster -tDK --no-confirm lang/clang36" = initiated installing lang/gcc (i.e., 4.8.4 at this point) in order to = provide itself with a compiler to bootstrap with. The result: no failures and a full clang 3.6 installation by being = bootstrapped via gcc 4.8.4. So gcc 4.8.4 vs. gcc5 makes a difference. But before blaming gcc5 = specifically... Here is what I would guess is going on: llvm's source code sometimes uses and other times . (I = did find with grep's.) One would have to trace all the headers actually = included for MSVCToolChain.cpp, directly or indirectly, and see which = one(s) are involved. But for ::sscanf notation they should be explicitly including = somewhere for that context. (Having in addition is fine.) The rule is as follows, using an example. The C++ standard (various = vintages) has at least one vintage that uses vs. as = an example for... "The header assuredly provides its declarations and = definitions within the namespace std. It may also provide these names = within the global namespace. The header assuredly provides = the same declarations and definitions within the global namespace, much = as in the C Standard. It may also provide these names within the = namespace std." So... only guarantees: int std::sscanf( const char* buffer, const char* format, ... ); only guarantees: int ::sscanf( const char* buffer, const char* format, ... ); But either file is allowed to (not required to) also declare/define the = other alternative as well. In other words: For portable code the burden of selecting appropriately = is on the folks including the headers. Otherwise just because it "works" = in one valid toolchain does not mean it is guaranteed to work in another = valid one. gcc5 may well provide fewer of the optional declarations/definitions for = some headers. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 08:37 PM, Mark Millard = wrote: I tried "portmaster -tDK --no-confirm lang/clang36" on a powerpc = (non-64): $ freebsd-version -ku ; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Mon Mar = 9 22:24:27 PDT 2015 = root@FBSDG4S0:/usr/obj/usr/srcC/sys/GENERICvtsc-NODEBUG powerpc powerpc Again it used gcc5 to bootstrap, my having installed gcc5 recently, no = other non-built-in-world compilers ever having been installed before. No = clang of any kind to start with. Just gcc 4.2.1. No changes to = lang/clang36. Just: portmaster -tDK --no-confirm lang/clang36 Again it had the same MSVCToolChain.cpp problem: llvm[4]: Compiling MSVCToolChain.cpp for Release build MSVCToolChain.cpp: In member function 'bool = clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::__cxx11::s= tring&, int&, int&) const': MSVCToolChain.cpp:215:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); ^ Like before when I had installed gcc5 it had no troubles installing and = I made no changes. I have another build test running where only built-in-world compilers = existed (gcc 4.2.1 and clang 3.4.1). For this context "portmaster -tDK = --no-confirm lang/clang36" initiated installing lang/gcc (i.e., 4.8.4 at = this point) in order to provide itself with a compiler to bootstrap = with. We will see how that one does. It takes longer since 2 compilers = are being installed. (I started this one first but it is not done yet.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 05:18 PM, Mark Millard = wrote: Basic context (more context details listed later): # freebsd-version -ku; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar = 11 19:23:14 PDT 2015 = root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBU= G powerpc powerpc64 The problem: portmaster -tDK --no-confirm lang/clang36 is how I started the build. The error reported was for in MSVCToolChain.cpp's member function: bool = clang::driver::toolchains::getWindowsSDKDir(std::__cxx1:string&,int&, = int&) const The report was: MSVCToolChain.cpp:25:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. And it not = being likely to be powerpc64 specific would be my guess. May be that it = bootstrapped via gcc5? I've not yet tried from a powerpc (non-64) = FreeBSD build. Context details: # svnlite info /usr/ports/lang/clang36 Path: lang/clang36 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 Relative URL: ^/head/lang/clang36 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: brooks Last Changed Rev: 380295 Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) It used gcc5 to bootstrap as there was no clang present and that is the = only gcc port installed: # svnlite info /usr/ports/lang/gcc5 Path: lang/gcc5 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 Relative URL: ^/head/lang/gcc5 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: gerald Last Changed Rev: 380943 Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) # more /etc/make.conf #CPP=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 06:00:54 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CC8BB9 for ; Tue, 17 Mar 2015 06:00:54 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DAC74300 for ; Tue, 17 Mar 2015 06:00:53 +0000 (UTC) Received: (qmail 28532 invoked from network); 17 Mar 2015 06:00:52 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 17 Mar 2015 06:00:52 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 17 Mar 2015 02:00:52 -0400 (EDT) Received: (qmail 23909 invoked from network); 17 Mar 2015 06:00:51 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Mar 2015 06:00:51 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id A62651C439E; Mon, 16 Mar 2015 23:00:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets error: llvm-build: error: invalid native target: 'powerpc64' (not in project) From: Mark Millard In-Reply-To: <9682273F-8B85-4351-AB2B-011240D40327@dsl-only.net> Date: Mon, 16 Mar 2015 23:00:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <160E2B60-047A-4E5B-A258-334155CDEC0B@dsl-only.net> References: <9682273F-8B85-4351-AB2B-011240D40327@dsl-only.net> To: FreeBSD PowerPC ML , freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 06:00:54 -0000 The 2 powerpc (non-64) build attempts for clang 3.6 did not get this = problem. So this specific problem is powerpc64 specific. Bootstrapping powerpc (non-64) clang 3.6 via gcc 4.8.4 (the current = lang/gcc) works fine. (In absence of any c++ port lang/clang36 = automatically installed lang/gcc (currently gcc 4.8.4) in order to = bootstrap itself.) Bootstrapping powerpc (non-64) clang 3.6 via gcc5 (by having lang/gcc5 = already installed first) still reports an error for not declaring = ::sscanf, just like powerpc64 based on gcc5 for bootstrapping did. (This might be llvm/clang making use of only where an include = of would be required to be involved in order to guarantee the = :: (global) declaration/definition. The way the C++ standard (all = vintages) is written gcc 4.8.4 and gcc5 could be this different and both = be valid/conforming.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 05:04 PM, Mark Millard = wrote: Basic context (more context details listed later): # freebsd-version -ku; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar = 11 19:23:14 PDT 2015 = root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBU= G powerpc powerpc64 The problem: portmaster -tDK --no-confirm lang/clang36 is how I started the build. The error report was after it reported entering the directory: = /usr/obj/portswork/usr/ports/lang/clang36/work/llvm-3.6.0.src/tools/clang/= lib/Driver/ The report was: llvm-build: error: invalid native target: 'powerpc64' (not in project) I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. But powerpc64 = likely does. I've not yet tried from a powerpc (non-64) FreeBSD build. I'll note that with top -PaSCHopid I watched it compile the PowerPc code = generator software: it shoudl be able to handle PowerPCs fine. My guess is a conversion of naming conventions is required someplace: FreeBSD using powerpc64 vs. clang using ppc64. (Big endian context.) This likely would matter for little endian naming as well (ppc64le on = the clang end of things I expect).=20 Context details: # svnlite info /usr/ports/lang/clang36 Path: lang/clang36 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 Relative URL: ^/head/lang/clang36 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: brooks Last Changed Rev: 380295 Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) It used gcc5 to bootstrap as there was no clang present and that is the = only gcc port installed: # svnlite info /usr/ports/lang/gcc5 Path: lang/gcc5 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 Relative URL: ^/head/lang/gcc5 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: gerald Last Changed Rev: 380943 Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) # more /etc/make.conf #CPP=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 08:31:04 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC342C01; Tue, 17 Mar 2015 08:31:04 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2DB6A782; Tue, 17 Mar 2015 08:31:04 +0000 (UTC) Received: by lbbzq9 with SMTP id zq9so1778309lbb.0; Tue, 17 Mar 2015 01:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=O2tcTQ6EiXoz0CW97XpyB1AKC9nzPO3uNUbAJNQ8duo=; b=LghJFjJenRGTJoOx32LcIQVrsAT2GtnMM0Wi1aFnE0vXmcWmF0PjEk59Om3e+TnkvX k/fR4w3saQ8870bsAFeqCp11wGtHmfE0pok/rIL09U7q9emp+kYlvgI1AFJ4lZ3EGjBY jxr6lzVL9zWyIjEC4Yt9NjPyDoVV2j6cBjql88Ou5i35D1JKfvTWDYXxpr84+KpFhlUS j1SfwS1NiSrsRhF9bAWsgnoso3zSeMfGRDU6caH6TjL3HvjrzBvcnBT9V3VdN+KNbJpm tUTViwXVi/Us04iVY/T2MhMiXLnfpaXtFAHc5dJK+HYiJ6jtcrUA4qTb9ZSiR3fRNvB1 usFg== MIME-Version: 1.0 X-Received: by 10.112.51.35 with SMTP id h3mr49346744lbo.113.1426581062157; Tue, 17 Mar 2015 01:31:02 -0700 (PDT) Sender: jlehen@gmail.com Received: by 10.114.183.145 with HTTP; Tue, 17 Mar 2015 01:31:02 -0700 (PDT) In-Reply-To: <5507555C.7030508@FreeBSD.org> References: <5507555C.7030508@FreeBSD.org> Date: Tue, 17 Mar 2015 09:31:02 +0100 X-Google-Sender-Auth: vXkltIfqxTMdsZDAV41hbgpU1-4 Message-ID: Subject: Re: net/unison240 depends on lang/ocaml-nox11 From: Jeremie Le Hen To: Guido Falsi Content-Type: text/plain; charset=UTF-8 Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 08:31:04 -0000 On Mon, Mar 16, 2015 at 11:12 PM, Guido Falsi wrote: > On 03/16/15 22:37, Jeremie Le Hen wrote: >> Actually, I've just realized that I fixed net/unison232 in my local tree :o). >> >> Would you mind submitting it and applying the same for unison240? >> > > I never noticed this since it never happened to me and nobody else > reported it. > > Anyway now that you draw my attention, yes, it needs fixing. > > Your patch looks correct, but please allow me a little time for some > testing. OK thanks! :) > Thanks for bringing this up! > >>> [00:00:58] ====>> Error: Duplicated origin for ocaml-nox11-4.01.0_4: >>> lang/ocaml-nox11 AND lang/ocaml. Rerun with -vv to see which ports are >>> depending on these. > > Just to be sure I get it right, is this error reported at the start of > the run while "Calculating ports order and dependencies"? Yes that's correct. -- Jeremie Le Hen jlh@FreeBSD.org From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 09:19:53 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 356A1AE6 for ; Tue, 17 Mar 2015 09:19:53 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D7F24CCA for ; Tue, 17 Mar 2015 09:19:52 +0000 (UTC) Received: (qmail 28694 invoked from network); 17 Mar 2015 09:19:45 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 17 Mar 2015 09:19:45 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 17 Mar 2015 05:19:45 -0400 (EDT) Received: (qmail 16072 invoked from network); 17 Mar 2015 09:19:44 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Mar 2015 09:19:44 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id DB0D41C4052; Tue, 17 Mar 2015 02:19:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared From: Mark Millard In-Reply-To: Date: Tue, 17 Mar 2015 02:19:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4A490783-D724-4C81-A99E-0CBB20650559@dsl-only.net> References: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> <722DBABA-1E03-434E-ACB4-55A1E69E8AAA@dsl-only.net> To: FreeBSD PowerPC ML , freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 09:19:53 -0000 On a powerpc (non-64) I did pkg delete's for lang/gcc5 and lang/clang36 = and tried installing lang/gcc491 first then reinstalling lang/clang36 = (so it would bootstrap via gcc491). The result was the same as for lang/gcc5: llvm[4]: Compiling MSVCToolChain.cpp for Release build MSVCToolChain.cpp: In member function 'bool = clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::string&, = int&, int&) const': MSVCToolChain.cpp:215:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); ^ So gcc 4.8.4 (lang/gcc) is the odd one out here (since it the one of the = 3 that does not complain about ::sscanf use). I have another build of lang/gcc5 and then of lang/clang36 going based = on adding: #include to MSVCToolChain.cpp to see if the problem goes away for gcc5 based on = having the only guaranteed-sufficient header explicitly included. We will see what that shows. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 10:36 PM, Mark Millard = wrote: The last powerpc (non-64) build test to complete ran where only = built-in-world compilers originally existed (gcc 4.2.1 and clang 3.4.1 = this time. For this context "portmaster -tDK --no-confirm lang/clang36" = initiated installing lang/gcc (i.e., 4.8.4 at this point) in order to = provide itself with a compiler to bootstrap with. The result: no failures and a full clang 3.6 installation by being = bootstrapped via gcc 4.8.4. So gcc 4.8.4 vs. gcc5 makes a difference. But before blaming gcc5 = specifically... Here is what I would guess is going on: llvm's source code sometimes uses and other times . (I = did find with grep's.) One would have to trace all the headers actually = included for MSVCToolChain.cpp, directly or indirectly, and see which = one(s) are involved. But for ::sscanf notation they should be explicitly including = somewhere for that context. (Having in addition is fine.) The rule is as follows, using an example. The C++ standard (various = vintages) has at least one vintage that uses vs. as = an example for... "The header assuredly provides its declarations and = definitions within the namespace std. It may also provide these names = within the global namespace. The header assuredly provides = the same declarations and definitions within the global namespace, much = as in the C Standard. It may also provide these names within the = namespace std." So... only guarantees: int std::sscanf( const char* buffer, const char* format, ... ); only guarantees: int ::sscanf( const char* buffer, const char* format, ... ); But either file is allowed to (not required to) also declare/define the = other alternative as well. In other words: For portable code the burden of selecting appropriately = is on the folks including the headers. Otherwise just because it "works" = in one valid toolchain does not mean it is guaranteed to work in another = valid one. gcc5 may well provide fewer of the optional declarations/definitions for = some headers. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 08:37 PM, Mark Millard = wrote: I tried "portmaster -tDK --no-confirm lang/clang36" on a powerpc = (non-64): $ freebsd-version -ku ; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Mon Mar = 9 22:24:27 PDT 2015 = root@FBSDG4S0:/usr/obj/usr/srcC/sys/GENERICvtsc-NODEBUG powerpc powerpc Again it used gcc5 to bootstrap, my having installed gcc5 recently, no = other non-built-in-world compilers ever having been installed before. No = clang of any kind to start with. Just gcc 4.2.1. No changes to = lang/clang36. Just: portmaster -tDK --no-confirm lang/clang36 Again it had the same MSVCToolChain.cpp problem: llvm[4]: Compiling MSVCToolChain.cpp for Release build MSVCToolChain.cpp: In member function 'bool = clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::__cxx11::s= tring&, int&, int&) const': MSVCToolChain.cpp:215:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); ^ Like before when I had installed gcc5 it had no troubles installing and = I made no changes. I have another build test running where only built-in-world compilers = existed (gcc 4.2.1 and clang 3.4.1). For this context "portmaster -tDK = --no-confirm lang/clang36" initiated installing lang/gcc (i.e., 4.8.4 at = this point) in order to provide itself with a compiler to bootstrap = with. We will see how that one does. It takes longer since 2 compilers = are being installed. (I started this one first but it is not done yet.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 05:18 PM, Mark Millard = wrote: Basic context (more context details listed later): # freebsd-version -ku; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar = 11 19:23:14 PDT 2015 = root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBU= G powerpc powerpc64 The problem: portmaster -tDK --no-confirm lang/clang36 is how I started the build. The error reported was for in MSVCToolChain.cpp's member function: bool = clang::driver::toolchains::getWindowsSDKDir(std::__cxx1:string&,int&, = int&) const The report was: MSVCToolChain.cpp:25:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. And it not = being likely to be powerpc64 specific would be my guess. May be that it = bootstrapped via gcc5? I've not yet tried from a powerpc (non-64) = FreeBSD build. Context details: # svnlite info /usr/ports/lang/clang36 Path: lang/clang36 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 Relative URL: ^/head/lang/clang36 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: brooks Last Changed Rev: 380295 Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) It used gcc5 to bootstrap as there was no clang present and that is the = only gcc port installed: # svnlite info /usr/ports/lang/gcc5 Path: lang/gcc5 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 Relative URL: ^/head/lang/gcc5 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: gerald Last Changed Rev: 380943 Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) # more /etc/make.conf #CPP=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 09:26:36 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB6EFD9D for ; Tue, 17 Mar 2015 09:26:36 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 80B39DBF for ; Tue, 17 Mar 2015 09:26:36 +0000 (UTC) Received: (qmail 19001 invoked from network); 17 Mar 2015 09:26:35 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 17 Mar 2015 09:26:35 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 17 Mar 2015 05:26:35 -0400 (EDT) Received: (qmail 21852 invoked from network); 17 Mar 2015 09:26:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Mar 2015 09:26:34 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id EBE441C43AD; Tue, 17 Mar 2015 02:26:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared From: Mark Millard In-Reply-To: <4A490783-D724-4C81-A99E-0CBB20650559@dsl-only.net> Date: Tue, 17 Mar 2015 02:26:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> <722DBABA-1E03-434E-ACB4-55A1E69E8AAA@dsl-only.net> <4A490783-D724-4C81-A99E-0CBB20650559@dsl-only.net> To: FreeBSD PowerPC ML , freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 09:26:36 -0000 Please excuse all the "gcc491" references. It is lang/gcc49 and = currently that has 4.9.3 . The gcc 4.9.1 in my head was from earlier powerpc64-xtoolchain-gcc = experiments. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 02:19 AM, Mark Millard = wrote: On a powerpc (non-64) I did pkg delete's for lang/gcc5 and lang/clang36 = and tried installing lang/gcc491 first then reinstalling lang/clang36 = (so it would bootstrap via gcc491). The result was the same as for lang/gcc5: llvm[4]: Compiling MSVCToolChain.cpp for Release build MSVCToolChain.cpp: In member function 'bool = clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::string&, = int&, int&) const': MSVCToolChain.cpp:215:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); ^ So gcc 4.8.4 (lang/gcc) is the odd one out here (since it the one of the = 3 that does not complain about ::sscanf use). I have another build of lang/gcc5 and then of lang/clang36 going based = on adding: #include to MSVCToolChain.cpp to see if the problem goes away for gcc5 based on = having the only guaranteed-sufficient header explicitly included. We will see what that shows. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 10:36 PM, Mark Millard = wrote: The last powerpc (non-64) build test to complete ran where only = built-in-world compilers originally existed (gcc 4.2.1 and clang 3.4.1 = this time. For this context "portmaster -tDK --no-confirm lang/clang36" = initiated installing lang/gcc (i.e., 4.8.4 at this point) in order to = provide itself with a compiler to bootstrap with. The result: no failures and a full clang 3.6 installation by being = bootstrapped via gcc 4.8.4. So gcc 4.8.4 vs. gcc5 makes a difference. But before blaming gcc5 = specifically... Here is what I would guess is going on: llvm's source code sometimes uses and other times . (I = did find with grep's.) One would have to trace all the headers actually = included for MSVCToolChain.cpp, directly or indirectly, and see which = one(s) are involved. But for ::sscanf notation they should be explicitly including = somewhere for that context. (Having in addition is fine.) The rule is as follows, using an example. The C++ standard (various = vintages) has at least one vintage that uses vs. as = an example for... "The header assuredly provides its declarations and = definitions within the namespace std. It may also provide these names = within the global namespace. The header assuredly provides = the same declarations and definitions within the global namespace, much = as in the C Standard. It may also provide these names within the = namespace std." So... only guarantees: int std::sscanf( const char* buffer, const char* format, ... ); only guarantees: int ::sscanf( const char* buffer, const char* format, ... ); But either file is allowed to (not required to) also declare/define the = other alternative as well. In other words: For portable code the burden of selecting appropriately = is on the folks including the headers. Otherwise just because it "works" = in one valid toolchain does not mean it is guaranteed to work in another = valid one. gcc5 may well provide fewer of the optional declarations/definitions for = some headers. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 08:37 PM, Mark Millard = wrote: I tried "portmaster -tDK --no-confirm lang/clang36" on a powerpc = (non-64): $ freebsd-version -ku ; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Mon Mar = 9 22:24:27 PDT 2015 = root@FBSDG4S0:/usr/obj/usr/srcC/sys/GENERICvtsc-NODEBUG powerpc powerpc Again it used gcc5 to bootstrap, my having installed gcc5 recently, no = other non-built-in-world compilers ever having been installed before. No = clang of any kind to start with. Just gcc 4.2.1. No changes to = lang/clang36. Just: portmaster -tDK --no-confirm lang/clang36 Again it had the same MSVCToolChain.cpp problem: llvm[4]: Compiling MSVCToolChain.cpp for Release build MSVCToolChain.cpp: In member function 'bool = clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::__cxx11::s= tring&, int&, int&) const': MSVCToolChain.cpp:215:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); ^ Like before when I had installed gcc5 it had no troubles installing and = I made no changes. I have another build test running where only built-in-world compilers = existed (gcc 4.2.1 and clang 3.4.1). For this context "portmaster -tDK = --no-confirm lang/clang36" initiated installing lang/gcc (i.e., 4.8.4 at = this point) in order to provide itself with a compiler to bootstrap = with. We will see how that one does. It takes longer since 2 compilers = are being installed. (I started this one first but it is not done yet.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 05:18 PM, Mark Millard = wrote: Basic context (more context details listed later): # freebsd-version -ku; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar = 11 19:23:14 PDT 2015 = root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBU= G powerpc powerpc64 The problem: portmaster -tDK --no-confirm lang/clang36 is how I started the build. The error reported was for in MSVCToolChain.cpp's member function: bool = clang::driver::toolchains::getWindowsSDKDir(std::__cxx1:string&,int&, = int&) const The report was: MSVCToolChain.cpp:25:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. And it not = being likely to be powerpc64 specific would be my guess. May be that it = bootstrapped via gcc5? I've not yet tried from a powerpc (non-64) = FreeBSD build. Context details: # svnlite info /usr/ports/lang/clang36 Path: lang/clang36 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 Relative URL: ^/head/lang/clang36 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: brooks Last Changed Rev: 380295 Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) It used gcc5 to bootstrap as there was no clang present and that is the = only gcc port installed: # svnlite info /usr/ports/lang/gcc5 Path: lang/gcc5 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 Relative URL: ^/head/lang/gcc5 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: gerald Last Changed Rev: 380943 Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) # more /etc/make.conf #CPP=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 09:47:07 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B6D75B2; Tue, 17 Mar 2015 09:47:07 +0000 (UTC) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E981AB2; Tue, 17 Mar 2015 09:47:06 +0000 (UTC) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3l5qQp0ZCCzbHM; Tue, 17 Mar 2015 10:46:58 +0100 (CET) Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id ODyZ8MrIOJsw; Tue, 17 Mar 2015 10:46:56 +0100 (CET) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Tue, 17 Mar 2015 10:46:56 +0100 (CET) Message-ID: <5507F80F.70609@FreeBSD.org> Date: Tue, 17 Mar 2015 10:46:55 +0100 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Jeremie Le Hen Subject: Re: net/unison240 depends on lang/ocaml-nox11 References: <5507555C.7030508@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 09:47:07 -0000 On 03/17/15 09:31, Jeremie Le Hen wrote: > On Mon, Mar 16, 2015 at 11:12 PM, Guido Falsi wrote: >> On 03/16/15 22:37, Jeremie Le Hen wrote: >>> Actually, I've just realized that I fixed net/unison232 in my local tree :o). >>> >>> Would you mind submitting it and applying the same for unison240? >>> >> >> I never noticed this since it never happened to me and nobody else >> reported it. >> >> Anyway now that you draw my attention, yes, it needs fixing. >> >> Your patch looks correct, but please allow me a little time for some >> testing. > > OK thanks! :) Just committed it. Thanks again for reporting the issue! -- Guido Falsi From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 10:44:40 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9414422C; Tue, 17 Mar 2015 10:44:40 +0000 (UTC) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1085B9B3; Tue, 17 Mar 2015 10:44:40 +0000 (UTC) Received: by labjg1 with SMTP id jg1so4763447lab.2; Tue, 17 Mar 2015 03:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=BlcU9c/wdCwhR6XdjdSLeSJbs9l3XPQP/mejno5wJTc=; b=gDUtA5cTQjRR5O/ryElN7D5xjtKLoq3k0tHyZJTD+wiLVAgdKZ4tEu+dAzSLiyvMje a+KHCJGWDWgHbo7Fs+vguv2NinmiCvNzkH/8L67wccmL/eQ5bta262JSDmMdMqpAt60i NRaFbEBaPDWxm01j6jtGWPEj/VPog4h97/hAu5NjgTD9lKNApHPMwNWZdjuQHbC0ISk+ +aiUz5+s2gV2UqqW2EFZJDluJZjWArS9eNVJ/fFFvXNvLHl0+TQU/R2/N49DtcG3lXEj N1FJELFInwjsoBbJ2XVSMCVHjgJwPpAoGJ/s4iU9BZft+ss73pq5bap66LRUnHc+7+y6 YaYQ== MIME-Version: 1.0 X-Received: by 10.152.36.138 with SMTP id q10mr58485035laj.113.1426589077888; Tue, 17 Mar 2015 03:44:37 -0700 (PDT) Sender: jlehen@gmail.com Received: by 10.114.183.145 with HTTP; Tue, 17 Mar 2015 03:44:37 -0700 (PDT) In-Reply-To: <5507F80F.70609@FreeBSD.org> References: <5507555C.7030508@FreeBSD.org> <5507F80F.70609@FreeBSD.org> Date: Tue, 17 Mar 2015 11:44:37 +0100 X-Google-Sender-Auth: _cli4vKZRI750ba5hNHJdEDQzvo Message-ID: Subject: Re: net/unison240 depends on lang/ocaml-nox11 From: Jeremie Le Hen To: Guido Falsi Content-Type: text/plain; charset=UTF-8 Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 10:44:40 -0000 On Tue, Mar 17, 2015 at 10:46 AM, Guido Falsi wrote: > On 03/17/15 09:31, Jeremie Le Hen wrote: >> On Mon, Mar 16, 2015 at 11:12 PM, Guido Falsi wrote: >>> On 03/16/15 22:37, Jeremie Le Hen wrote: >>>> Actually, I've just realized that I fixed net/unison232 in my local tree :o). >>>> >>>> Would you mind submitting it and applying the same for unison240? >>>> >>> >>> I never noticed this since it never happened to me and nobody else >>> reported it. >>> >>> Anyway now that you draw my attention, yes, it needs fixing. >>> >>> Your patch looks correct, but please allow me a little time for some >>> testing. >> >> OK thanks! :) > > Just committed it. Thanks again for reporting the issue! Thanks! I don't want to abuse your time, but "make checksum" is broken on net/unison240 :). -- Jeremie Le Hen jlh@FreeBSD.org From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 11:25:43 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D16CCC4A; Tue, 17 Mar 2015 11:25:43 +0000 (UTC) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8AD4EE53; Tue, 17 Mar 2015 11:25:43 +0000 (UTC) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3l5scf3MPGzbHN; Tue, 17 Mar 2015 12:25:38 +0100 (CET) Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id V3bAqgtHtV3N; Tue, 17 Mar 2015 12:25:36 +0100 (CET) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Tue, 17 Mar 2015 12:25:36 +0100 (CET) Message-ID: <55080F30.9010104@FreeBSD.org> Date: Tue, 17 Mar 2015 12:25:36 +0100 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Jeremie Le Hen Subject: Re: net/unison240 depends on lang/ocaml-nox11 References: <5507555C.7030508@FreeBSD.org> <5507F80F.70609@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 11:25:43 -0000 On 03/17/15 11:44, Jeremie Le Hen wrote: > On Tue, Mar 17, 2015 at 10:46 AM, Guido Falsi wrote: >> On 03/17/15 09:31, Jeremie Le Hen wrote: >>> On Mon, Mar 16, 2015 at 11:12 PM, Guido Falsi wrote: >>>> On 03/16/15 22:37, Jeremie Le Hen wrote: >>>>> Actually, I've just realized that I fixed net/unison232 in my local tree :o). >>>>> >>>>> Would you mind submitting it and applying the same for unison240? >>>>> >>>> >>>> I never noticed this since it never happened to me and nobody else >>>> reported it. >>>> >>>> Anyway now that you draw my attention, yes, it needs fixing. >>>> >>>> Your patch looks correct, but please allow me a little time for some >>>> testing. >>> >>> OK thanks! :) >> >> Just committed it. Thanks again for reporting the issue! > > Thanks! > > I don't want to abuse your time, but "make checksum" is broken on > net/unison240 :). > Looks like distfiles were rerolled. 2.48 has the same problem. Will commit updated checksums shortly! Thanks again. -- Guido Falsi From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 12:27:27 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BBE09D20; Tue, 17 Mar 2015 12:27:27 +0000 (UTC) Received: from mail.bein.link (bein.link [37.252.124.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 844097C0; Tue, 17 Mar 2015 12:27:27 +0000 (UTC) Received: by mail.bein.link (Postfix, from userid 1001) id 3BD7E1AF172; Tue, 17 Mar 2015 12:21:27 +0000 (UTC) Date: Tue, 17 Mar 2015 12:21:27 +0000 From: Maxim Kirenenko To: ports@freebsd.org Subject: devel/py-colorama: no update yet Message-ID: <20150317122127.GC74328@bein.link> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Cc: python@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 12:27:27 -0000 Dear everyone, Recently, I submitted a PR about devel/py-colorama: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198605 Until now, I didn't get any reply on that. Could anyone update that port for me, please? -- wbr, Maxim Filimonov From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 12:53:15 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C85DA4C4; Tue, 17 Mar 2015 12:53:15 +0000 (UTC) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8CA89A7C; Tue, 17 Mar 2015 12:53:15 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YXqzf-000Poc-HZ; Tue, 17 Mar 2015 13:53:11 +0100 Date: Tue, 17 Mar 2015 13:53:11 +0100 From: Kurt Jaeger To: Maxim Kirenenko Subject: Re: devel/py-colorama: no update yet Message-ID: <20150317125311.GQ62590@home.opsec.eu> References: <20150317122127.GC74328@bein.link> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150317122127.GC74328@bein.link> Cc: ports@freebsd.org, python@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 12:53:15 -0000 Hi! > Recently, I submitted a PR about devel/py-colorama: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198605 > > Until now, I didn't get any reply on that. Could anyone update that port > for me, please? It's still pending on maintainer approval ? -- pi@opsec.eu +49 171 3101372 5 years to go ! From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 14:10:57 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4ABBFE4 for ; Tue, 17 Mar 2015 14:10:57 +0000 (UTC) Received: from mail.bein.link (bein.link [37.252.124.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A950A242 for ; Tue, 17 Mar 2015 14:10:57 +0000 (UTC) Received: by mail.bein.link (Postfix, from userid 1001) id CADB21AF1EE; Tue, 17 Mar 2015 14:10:54 +0000 (UTC) Date: Tue, 17 Mar 2015 14:10:54 +0000 From: Maxim Kirenenko To: freebsd-ports@freebsd.org Subject: Re: devel/py-colorama: no update yet Message-ID: <20150317141054.GD74328@bein.link> Mail-Followup-To: Maxim Kirenenko , freebsd-ports@freebsd.org References: <20150317122127.GC74328@bein.link> <20150317125311.GQ62590@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150317125311.GQ62590@home.opsec.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 14:10:58 -0000 On Tue, Mar 17, 2015 at 01:53:11PM +0100, Kurt Jaeger wrote: > Hi! > > > Recently, I submitted a PR about devel/py-colorama: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198605 > > > > Until now, I didn't get any reply on that. Could anyone update that port > > for me, please? > > It's still pending on maintainer approval ? > Yes. And the maintainer doesn't seem to answer. -- wbr, Maxim Filimonov From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 14:16:11 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E870A198 for ; Tue, 17 Mar 2015 14:16:11 +0000 (UTC) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A707A2B9 for ; Tue, 17 Mar 2015 14:16:11 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YXsHy-0000uy-RR; Tue, 17 Mar 2015 15:16:10 +0100 Date: Tue, 17 Mar 2015 15:16:10 +0100 From: Kurt Jaeger To: Maxim Kirenenko , freebsd-ports@freebsd.org Subject: Re: devel/py-colorama: no update yet Message-ID: <20150317141610.GR62590@home.opsec.eu> References: <20150317122127.GC74328@bein.link> <20150317125311.GQ62590@home.opsec.eu> <20150317141054.GD74328@bein.link> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150317141054.GD74328@bein.link> X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 14:16:12 -0000 Hi! > > > Recently, I submitted a PR about devel/py-colorama: > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198605 > > > > > > Until now, I didn't get any reply on that. Could anyone update that port > > > for me, please? > > > > It's still pending on maintainer approval ? > Yes. And the maintainer doesn't seem to answer. Section 5.5 of the porters handbook, https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html says: [...] If the maintainer does not respond to an update request after two weeks (excluding major public holidays), then that is considered a maintainer timeout, and the update may be made without explicit maintainer approval. [...] So in general he has two weeks. If it's urgent, we can make an exception. For example: - Does it block any other PRs or ports from updating ? - Is it broken right now ? -- pi@opsec.eu +49 171 3101372 5 years to go ! From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 14:18:10 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 661B53DE for ; Tue, 17 Mar 2015 14:18:10 +0000 (UTC) Received: from mail.bein.link (bein.link [37.252.124.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2AB612EE for ; Tue, 17 Mar 2015 14:18:10 +0000 (UTC) Received: by mail.bein.link (Postfix, from userid 1001) id F305C1AF172; Tue, 17 Mar 2015 14:18:09 +0000 (UTC) Date: Tue, 17 Mar 2015 14:18:09 +0000 From: Maxim Kirenenko To: freebsd-ports@freebsd.org Subject: Re: devel/py-colorama: no update yet Message-ID: <20150317141809.GB76924@bein.link> Mail-Followup-To: Maxim Kirenenko , freebsd-ports@freebsd.org References: <20150317122127.GC74328@bein.link> <20150317125311.GQ62590@home.opsec.eu> <20150317141054.GD74328@bein.link> <20150317141610.GR62590@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150317141610.GR62590@home.opsec.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 14:18:10 -0000 On Tue, Mar 17, 2015 at 03:16:10PM +0100, Kurt Jaeger wrote: > Hi! > For example: > - Does it block any other PRs or ports from updating ? > - Is it broken right now ? > - It actually does. I want to submit a new port, and it requires a recent version of py-colorama which is not available yet; - No, it isn't AFAIK. -- wbr, Maxim Filimonov From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 14:42:56 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67C6D8BF for ; Tue, 17 Mar 2015 14:42:56 +0000 (UTC) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 295FF83E for ; Tue, 17 Mar 2015 14:42:56 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YXshr-0001Qe-UP; Tue, 17 Mar 2015 15:42:55 +0100 Date: Tue, 17 Mar 2015 15:42:55 +0100 From: Kurt Jaeger To: Maxim Kirenenko , freebsd-ports@freebsd.org Subject: Re: devel/py-colorama: no update yet Message-ID: <20150317144255.GS62590@home.opsec.eu> References: <20150317122127.GC74328@bein.link> <20150317125311.GQ62590@home.opsec.eu> <20150317141054.GD74328@bein.link> <20150317141610.GR62590@home.opsec.eu> <20150317141809.GB76924@bein.link> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150317141809.GB76924@bein.link> X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 14:42:56 -0000 Hi! > > For example: > > - Does it block any other PRs or ports from updating ? > > - Is it broken right now ? > > > > - It actually does. I want to submit a new port, and it requires a > recent version of py-colorama which is not available yet; > - No, it isn't AFAIK. Can you submit the port and make the PR block on the py-colorama PR ? Then it's more obvious and I can speed this up (this evening CET). -- pi@opsec.eu +49 171 3101372 5 years to go ! From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 17:57:07 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18226ADA for ; Tue, 17 Mar 2015 17:57:07 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB507B5 for ; Tue, 17 Mar 2015 17:57:06 +0000 (UTC) Received: (qmail 4454 invoked from network); 17 Mar 2015 17:57:05 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 17 Mar 2015 17:57:05 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 17 Mar 2015 13:57:05 -0400 (EDT) Received: (qmail 21747 invoked from network); 17 Mar 2015 17:57:04 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Mar 2015 17:57:04 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 8BBC41C4052; Tue, 17 Mar 2015 10:57:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared From: Mark Millard In-Reply-To: Date: Tue, 17 Mar 2015 10:57:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> <722DBABA-1E03-434E-ACB4-55A1E69E8AAA@dsl-only.net> <4A490783-D724-4C81-A99E-0CBB20650559@dsl-only.net> To: FreeBSD PowerPC ML , freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 17:57:07 -0000 Adding a #include to MSVCToolChain.cpp fixed the specific ::sscanf problem for compiling = MSVCToolChain.cpp with gcc5. It also allowed the lang/clang36 build and = installation to complete. The official MSVCToolChain.cpp for the port does not directly or = indirectly include a header that guarantees to declare/define ::sscanf. = But it should. An alternative to the #include is to instead use std::sscanf notation. = That will be the next experiment to check if had been included = somewhere or not. It might be that neither header had been included. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 02:26 AM, Mark Millard = wrote: Please excuse all the "gcc491" references. It is lang/gcc49 and = currently that has 4.9.3 . The gcc 4.9.1 in my head was from earlier powerpc64-xtoolchain-gcc = experiments. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 02:19 AM, Mark Millard = wrote: On a powerpc (non-64) I did pkg delete's for lang/gcc5 and lang/clang36 = and tried installing lang/gcc491 first then reinstalling lang/clang36 = (so it would bootstrap via gcc491). The result was the same as for lang/gcc5: llvm[4]: Compiling MSVCToolChain.cpp for Release build MSVCToolChain.cpp: In member function 'bool = clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::string&, = int&, int&) const': MSVCToolChain.cpp:215:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); ^ So gcc 4.8.4 (lang/gcc) is the odd one out here (since it the one of the = 3 that does not complain about ::sscanf use). I have another build of lang/gcc5 and then of lang/clang36 going based = on adding: #include to MSVCToolChain.cpp to see if the problem goes away for gcc5 based on = having the only guaranteed-sufficient header explicitly included. We will see what that shows. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 10:36 PM, Mark Millard = wrote: The last powerpc (non-64) build test to complete ran where only = built-in-world compilers originally existed (gcc 4.2.1 and clang 3.4.1 = this time. For this context "portmaster -tDK --no-confirm lang/clang36" = initiated installing lang/gcc (i.e., 4.8.4 at this point) in order to = provide itself with a compiler to bootstrap with. The result: no failures and a full clang 3.6 installation by being = bootstrapped via gcc 4.8.4. So gcc 4.8.4 vs. gcc5 makes a difference. But before blaming gcc5 = specifically... Here is what I would guess is going on: llvm's source code sometimes uses and other times . (I = did find with grep's.) One would have to trace all the headers actually = included for MSVCToolChain.cpp, directly or indirectly, and see which = one(s) are involved. But for ::sscanf notation they should be explicitly including = somewhere for that context. (Having in addition is fine.) The rule is as follows, using an example. The C++ standard (various = vintages) has at least one vintage that uses vs. as = an example for... "The header assuredly provides its declarations and = definitions within the namespace std. It may also provide these names = within the global namespace. The header assuredly provides = the same declarations and definitions within the global namespace, much = as in the C Standard. It may also provide these names within the = namespace std." So... only guarantees: int std::sscanf( const char* buffer, const char* format, ... ); only guarantees: int ::sscanf( const char* buffer, const char* format, ... ); But either file is allowed to (not required to) also declare/define the = other alternative as well. In other words: For portable code the burden of selecting appropriately = is on the folks including the headers. Otherwise just because it "works" = in one valid toolchain does not mean it is guaranteed to work in another = valid one. gcc5 may well provide fewer of the optional declarations/definitions for = some headers. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 08:37 PM, Mark Millard = wrote: I tried "portmaster -tDK --no-confirm lang/clang36" on a powerpc = (non-64): $ freebsd-version -ku ; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Mon Mar = 9 22:24:27 PDT 2015 = root@FBSDG4S0:/usr/obj/usr/srcC/sys/GENERICvtsc-NODEBUG powerpc powerpc Again it used gcc5 to bootstrap, my having installed gcc5 recently, no = other non-built-in-world compilers ever having been installed before. No = clang of any kind to start with. Just gcc 4.2.1. No changes to = lang/clang36. Just: portmaster -tDK --no-confirm lang/clang36 Again it had the same MSVCToolChain.cpp problem: llvm[4]: Compiling MSVCToolChain.cpp for Release build MSVCToolChain.cpp: In member function 'bool = clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::__cxx11::s= tring&, int&, int&) const': MSVCToolChain.cpp:215:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); ^ Like before when I had installed gcc5 it had no troubles installing and = I made no changes. I have another build test running where only built-in-world compilers = existed (gcc 4.2.1 and clang 3.4.1). For this context "portmaster -tDK = --no-confirm lang/clang36" initiated installing lang/gcc (i.e., 4.8.4 at = this point) in order to provide itself with a compiler to bootstrap = with. We will see how that one does. It takes longer since 2 compilers = are being installed. (I started this one first but it is not done yet.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 05:18 PM, Mark Millard = wrote: Basic context (more context details listed later): # freebsd-version -ku; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar = 11 19:23:14 PDT 2015 = root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBU= G powerpc powerpc64 The problem: portmaster -tDK --no-confirm lang/clang36 is how I started the build. The error reported was for in MSVCToolChain.cpp's member function: bool = clang::driver::toolchains::getWindowsSDKDir(std::__cxx1:string&,int&, = int&) const The report was: MSVCToolChain.cpp:25:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. And it not = being likely to be powerpc64 specific would be my guess. May be that it = bootstrapped via gcc5? I've not yet tried from a powerpc (non-64) = FreeBSD build. Context details: # svnlite info /usr/ports/lang/clang36 Path: lang/clang36 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 Relative URL: ^/head/lang/clang36 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: brooks Last Changed Rev: 380295 Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) It used gcc5 to bootstrap as there was no clang present and that is the = only gcc port installed: # svnlite info /usr/ports/lang/gcc5 Path: lang/gcc5 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 Relative URL: ^/head/lang/gcc5 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: gerald Last Changed Rev: 380943 Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) # more /etc/make.conf #CPP=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 19:35:33 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 754FB7CB for ; Tue, 17 Mar 2015 19:35:33 +0000 (UTC) Received: from mail.bein.link (bein.link [37.252.124.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 379D6ED3 for ; Tue, 17 Mar 2015 19:35:32 +0000 (UTC) Received: from thinkpad.localnet (home.bein.link [172.16.32.6]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bein.link (Postfix) with ESMTPSA id 9316B1AF18B; Tue, 17 Mar 2015 19:35:31 +0000 (UTC) From: Maxim V Filimonov To: Kurt Jaeger Reply-To: che@bein.link Subject: Re: devel/py-colorama: no update yet Date: Tue, 17 Mar 2015 22:35:27 +0300 Message-ID: <11152995.Nk6mF987vM@thinkpad> User-Agent: KMail/4.14.2 (FreeBSD/10.1-RELEASE-p6; KDE/4.14.2; amd64; ; ) In-Reply-To: <20150317144255.GS62590@home.opsec.eu> References: <20150317122127.GC74328@bein.link> <20150317141809.GB76924@bein.link> <20150317144255.GS62590@home.opsec.eu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 19:35:33 -0000 On Tuesday 17 March 2015 15:42:55 Kurt Jaeger wrote: > Hi! > > > > For example: > > > - Does it block any other PRs or ports from updating ? > > > - Is it broken right now ? > > > > - It actually does. I want to submit a new port, and it requires a > > > > recent version of py-colorama which is not available yet; > > > > - No, it isn't AFAIK. > > Can you submit the port and make the PR block on the py-colorama PR ? > > Then it's more obvious and I can speed this up (this evening CET). Done. Added a PR, made the PR on py-colorama its blocker. -- wbr, Maxim Filimonov From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 19:59:13 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D4CCF92; Tue, 17 Mar 2015 19:59:13 +0000 (UTC) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A75E198; Tue, 17 Mar 2015 19:59:13 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YXxdv-0006bd-LB; Tue, 17 Mar 2015 20:59:11 +0100 Date: Tue, 17 Mar 2015 20:59:11 +0100 From: Kurt Jaeger To: Maxim Kirenenko Subject: Re: devel/py-colorama: no update yet Message-ID: <20150317195911.GT62590@home.opsec.eu> References: <20150317122127.GC74328@bein.link> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150317122127.GC74328@bein.link> Cc: ports@freebsd.org, python@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 19:59:13 -0000 Hi! > Recently, I submitted a PR about devel/py-colorama: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198605 > > Until now, I didn't get any reply on that. Could anyone update that port > for me, please? testing@work One thing I found unusual in your submission: The shar. If the port already exists and the patch is an update, please provide a diff -r -u between the old and the new port. The provided svn diff does not work with patch against an existing 0.2.5 ports dir. If it's a *new* port, then shar is the recommended format. -- pi@opsec.eu +49 171 3101372 5 years to go ! From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 20:24:46 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3678648 for ; Tue, 17 Mar 2015 20:24:46 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 486106C5 for ; Tue, 17 Mar 2015 20:24:45 +0000 (UTC) Received: (qmail 21641 invoked from network); 17 Mar 2015 20:24:43 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 17 Mar 2015 20:24:43 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 17 Mar 2015 16:24:43 -0400 (EDT) Received: (qmail 12690 invoked from network); 17 Mar 2015 20:24:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Mar 2015 20:24:43 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id A11B91C43A6; Tue, 17 Mar 2015 13:24:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared From: Mark Millard In-Reply-To: Date: Tue, 17 Mar 2015 13:24:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7A4844FD-8AF2-4431-ADC2-F172626097B1@dsl-only.net> References: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> <722DBABA-1E03-434E-ACB4-55A1E69E8AAA@dsl-only.net> <4A490783-D724-4C81-A99E-0CBB20650559@dsl-only.net> To: FreeBSD PowerPC ML , freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 20:24:46 -0000 I tried the final experiment using std::sscanf (so: adding the std) in = to the official port's MSVCToolChain.cpp source without adding an = explicit include of . (So also no explicit include of , = just like the official source file.) It failed: MSVCToolChain.cpp: In member function 'bool = clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::__cxx11::s= tring&, int&, int&) const': MSVCToolChain.cpp:215:5: error: 'sscanf' is not a member of 'std' std::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); ^ In other words for the official port's source code (by the above and = prior reported experiments): MSVCToolChain.cpp does not directly or indirectly include . MSVCToolChain.cpp does not directly or indirectly include . At that point it is shear luck for there to be any = declaration/definition of either ::sscanf or std::sscanf. Apparently gcc = 4.8.4 is implicitly providing one someplace for at least ::sscanf. gcc5 = and gcc 4.9.3 do not. I do not see any reason to depend on such gcc-version-specific behavior. In my view MSVCToolChain.cpp should have: #include added. So the = /usr/obj/portswork/usr/ports/lang/clang36/work/llvm-3.6.0.src/tools/clang/= lib/Driver/MSVCToolChain.cpp code would start with something like (once = patched?)... (Warning: MSVCToolChain.cpp's initial comment misnames the file name.) //=3D=3D=3D--- ToolChains.cpp - ToolChain Implementations = -----------------------=3D=3D=3D// // // The LLVM Compiler Infrastructure // // This file is distributed under the University of Illinois Open Source // License. See LICENSE.TXT for details. // = //=3D=3D=3D---------------------------------------------------------------= -------=3D=3D=3D// #include "ToolChains.h" #include "clang/Basic/CharInfo.h" #include "clang/Basic/Version.h" #include "clang/Driver/Compilation.h" #include "clang/Driver/Driver.h" #include "clang/Driver/DriverDiagnostic.h" #include "clang/Driver/Options.h" #include "llvm/ADT/StringExtras.h" #include "llvm/Config/llvm-config.h" #include "llvm/Option/Arg.h" #include "llvm/Option/ArgList.h" #include "llvm/Support/ErrorHandling.h" #include "llvm/Support/FileSystem.h" #include "llvm/Support/Process.h" #include // Include the necessary headers to interface with the Windows registry = and // environment. ... =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 10:57 AM, Mark Millard = wrote: Adding a #include to MSVCToolChain.cpp fixed the specific ::sscanf problem for compiling = MSVCToolChain.cpp with gcc5. It also allowed the lang/clang36 build and = installation to complete. The official MSVCToolChain.cpp for the port does not directly or = indirectly include a header that guarantees to declare/define ::sscanf. = But it should. An alternative to the #include is to instead use std::sscanf notation. = That will be the next experiment to check if had been included = somewhere or not. It might be that neither header had been included. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 02:26 AM, Mark Millard = wrote: Please excuse all the "gcc491" references. It is lang/gcc49 and = currently that has 4.9.3 . The gcc 4.9.1 in my head was from earlier powerpc64-xtoolchain-gcc = experiments. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 02:19 AM, Mark Millard = wrote: On a powerpc (non-64) I did pkg delete's for lang/gcc5 and lang/clang36 = and tried installing lang/gcc491 first then reinstalling lang/clang36 = (so it would bootstrap via gcc491). The result was the same as for lang/gcc5: llvm[4]: Compiling MSVCToolChain.cpp for Release build MSVCToolChain.cpp: In member function 'bool = clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::string&, = int&, int&) const': MSVCToolChain.cpp:215:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); ^ So gcc 4.8.4 (lang/gcc) is the odd one out here (since it the one of the = 3 that does not complain about ::sscanf use). I have another build of lang/gcc5 and then of lang/clang36 going based = on adding: #include to MSVCToolChain.cpp to see if the problem goes away for gcc5 based on = having the only guaranteed-sufficient header explicitly included. We will see what that shows. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 10:36 PM, Mark Millard = wrote: The last powerpc (non-64) build test to complete ran where only = built-in-world compilers originally existed (gcc 4.2.1 and clang 3.4.1 = this time. For this context "portmaster -tDK --no-confirm lang/clang36" = initiated installing lang/gcc (i.e., 4.8.4 at this point) in order to = provide itself with a compiler to bootstrap with. The result: no failures and a full clang 3.6 installation by being = bootstrapped via gcc 4.8.4. So gcc 4.8.4 vs. gcc5 makes a difference. But before blaming gcc5 = specifically... Here is what I would guess is going on: llvm's source code sometimes uses and other times . (I = did find with grep's.) One would have to trace all the headers actually = included for MSVCToolChain.cpp, directly or indirectly, and see which = one(s) are involved. But for ::sscanf notation they should be explicitly including = somewhere for that context. (Having in addition is fine.) The rule is as follows, using an example. The C++ standard (various = vintages) has at least one vintage that uses vs. as = an example for... "The header assuredly provides its declarations and = definitions within the namespace std. It may also provide these names = within the global namespace. The header assuredly provides = the same declarations and definitions within the global namespace, much = as in the C Standard. It may also provide these names within the = namespace std." So... only guarantees: int std::sscanf( const char* buffer, const char* format, ... ); only guarantees: int ::sscanf( const char* buffer, const char* format, ... ); But either file is allowed to (not required to) also declare/define the = other alternative as well. In other words: For portable code the burden of selecting appropriately = is on the folks including the headers. Otherwise just because it "works" = in one valid toolchain does not mean it is guaranteed to work in another = valid one. gcc5 may well provide fewer of the optional declarations/definitions for = some headers. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 08:37 PM, Mark Millard = wrote: I tried "portmaster -tDK --no-confirm lang/clang36" on a powerpc = (non-64): $ freebsd-version -ku ; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Mon Mar = 9 22:24:27 PDT 2015 = root@FBSDG4S0:/usr/obj/usr/srcC/sys/GENERICvtsc-NODEBUG powerpc powerpc Again it used gcc5 to bootstrap, my having installed gcc5 recently, no = other non-built-in-world compilers ever having been installed before. No = clang of any kind to start with. Just gcc 4.2.1. No changes to = lang/clang36. Just: portmaster -tDK --no-confirm lang/clang36 Again it had the same MSVCToolChain.cpp problem: llvm[4]: Compiling MSVCToolChain.cpp for Release build MSVCToolChain.cpp: In member function 'bool = clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::__cxx11::s= tring&, int&, int&) const': MSVCToolChain.cpp:215:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); ^ Like before when I had installed gcc5 it had no troubles installing and = I made no changes. I have another build test running where only built-in-world compilers = existed (gcc 4.2.1 and clang 3.4.1). For this context "portmaster -tDK = --no-confirm lang/clang36" initiated installing lang/gcc (i.e., 4.8.4 at = this point) in order to provide itself with a compiler to bootstrap = with. We will see how that one does. It takes longer since 2 compilers = are being installed. (I started this one first but it is not done yet.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 05:18 PM, Mark Millard = wrote: Basic context (more context details listed later): # freebsd-version -ku; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar = 11 19:23:14 PDT 2015 = root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBU= G powerpc powerpc64 The problem: portmaster -tDK --no-confirm lang/clang36 is how I started the build. The error reported was for in MSVCToolChain.cpp's member function: bool = clang::driver::toolchains::getWindowsSDKDir(std::__cxx1:string&,int&, = int&) const The report was: MSVCToolChain.cpp:25:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. And it not = being likely to be powerpc64 specific would be my guess. May be that it = bootstrapped via gcc5? I've not yet tried from a powerpc (non-64) = FreeBSD build. Context details: # svnlite info /usr/ports/lang/clang36 Path: lang/clang36 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 Relative URL: ^/head/lang/clang36 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: brooks Last Changed Rev: 380295 Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) It used gcc5 to bootstrap as there was no clang present and that is the = only gcc port installed: # svnlite info /usr/ports/lang/gcc5 Path: lang/gcc5 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 Relative URL: ^/head/lang/gcc5 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: gerald Last Changed Rev: 380943 Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) # more /etc/make.conf #CPP=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ports@FreeBSD.ORG Tue Mar 17 21:16:42 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52F208E1 for ; Tue, 17 Mar 2015 21:16:42 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F3C2FD2F for ; Tue, 17 Mar 2015 21:16:41 +0000 (UTC) Received: (qmail 938 invoked from network); 17 Mar 2015 21:16:40 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 17 Mar 2015 21:16:40 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 17 Mar 2015 17:16:40 -0400 (EDT) Received: (qmail 16445 invoked from network); 17 Mar 2015 21:16:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Mar 2015 21:16:40 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 282F21C439E; Tue, 17 Mar 2015 14:16:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared From: Mark Millard In-Reply-To: <7A4844FD-8AF2-4431-ADC2-F172626097B1@dsl-only.net> Date: Tue, 17 Mar 2015 14:16:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <93E56954-B418-489A-B437-EAB73DF758CB@dsl-only.net> References: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> <722DBABA-1E03-434E-ACB4-55A1E69E8AAA@dsl-only.net> <4A490783-D724-4C81-A99E-0CBB20650559@dsl-only.net> <7A4844FD-8AF2-4431-ADC2-F172626097B1@dsl-only.net> To: FreeBSD PowerPC ML , freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 21:16:42 -0000 Looking at = https://github.com/clang-omp/clang_trunk/blob/master/lib/Driver/MSVCToolCh= ain.cpp shows that the modern source code has std::sscanf and = use so that is likely the better direction to go. What I saw when I = looked was: //=3D=3D=3D--- ToolChains.cpp - ToolChain Implementations = -----------------------=3D=3D=3D// // // The LLVM Compiler Infrastructure // // This file is distributed under the University of Illinois Open Source // License. See LICENSE.TXT for details. // = //=3D=3D=3D---------------------------------------------------------------= -------=3D=3D=3D// #include "ToolChains.h" #include "clang/Basic/CharInfo.h" #include "clang/Basic/Version.h" #include "clang/Driver/Compilation.h" #include "clang/Driver/Driver.h" #include "clang/Driver/DriverDiagnostic.h" #include "clang/Driver/Options.h" #include "llvm/ADT/StringExtras.h" #include "llvm/Config/llvm-config.h" #include "llvm/Option/Arg.h" #include "llvm/Option/ArgList.h" #include "llvm/Support/ErrorHandling.h" #include "llvm/Support/FileSystem.h" #include "llvm/Support/Process.h" #include // Include the necessary headers to interface with the Windows registry = and // environment. ... if (!sdkVersion.empty()) std::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); return hasSDKDir && !path.empty(); ... =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 01:24 PM, Mark Millard = wrote: I tried the final experiment using std::sscanf (so: adding the std) in = to the official port's MSVCToolChain.cpp source without adding an = explicit include of . (So also no explicit include of , = just like the official source file.) It failed: MSVCToolChain.cpp: In member function 'bool = clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::__cxx11::s= tring&, int&, int&) const': MSVCToolChain.cpp:215:5: error: 'sscanf' is not a member of 'std' std::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); ^ In other words for the official port's source code (by the above and = prior reported experiments): MSVCToolChain.cpp does not directly or indirectly include . MSVCToolChain.cpp does not directly or indirectly include . At that point it is shear luck for there to be any = declaration/definition of either ::sscanf or std::sscanf. Apparently gcc = 4.8.4 is implicitly providing one someplace for at least ::sscanf. gcc5 = and gcc 4.9.3 do not. I do not see any reason to depend on such gcc-version-specific behavior. In my view MSVCToolChain.cpp should have: #include added. So the = /usr/obj/portswork/usr/ports/lang/clang36/work/llvm-3.6.0.src/tools/clang/= lib/Driver/MSVCToolChain.cpp code would start with something like (once = patched?)... (Warning: MSVCToolChain.cpp's initial comment misnames the file name.) //=3D=3D=3D--- ToolChains.cpp - ToolChain Implementations = -----------------------=3D=3D=3D// // // The LLVM Compiler Infrastructure // // This file is distributed under the University of Illinois Open Source // License. See LICENSE.TXT for details. // = //=3D=3D=3D---------------------------------------------------------------= -------=3D=3D=3D// #include "ToolChains.h" #include "clang/Basic/CharInfo.h" #include "clang/Basic/Version.h" #include "clang/Driver/Compilation.h" #include "clang/Driver/Driver.h" #include "clang/Driver/DriverDiagnostic.h" #include "clang/Driver/Options.h" #include "llvm/ADT/StringExtras.h" #include "llvm/Config/llvm-config.h" #include "llvm/Option/Arg.h" #include "llvm/Option/ArgList.h" #include "llvm/Support/ErrorHandling.h" #include "llvm/Support/FileSystem.h" #include "llvm/Support/Process.h" #include // Include the necessary headers to interface with the Windows registry = and // environment. ... =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 10:57 AM, Mark Millard = wrote: Adding a #include to MSVCToolChain.cpp fixed the specific ::sscanf problem for compiling = MSVCToolChain.cpp with gcc5. It also allowed the lang/clang36 build and = installation to complete. The official MSVCToolChain.cpp for the port does not directly or = indirectly include a header that guarantees to declare/define ::sscanf. = But it should. An alternative to the #include is to instead use std::sscanf notation. = That will be the next experiment to check if had been included = somewhere or not. It might be that neither header had been included. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 02:26 AM, Mark Millard = wrote: Please excuse all the "gcc491" references. It is lang/gcc49 and = currently that has 4.9.3 . The gcc 4.9.1 in my head was from earlier powerpc64-xtoolchain-gcc = experiments. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 02:19 AM, Mark Millard = wrote: On a powerpc (non-64) I did pkg delete's for lang/gcc5 and lang/clang36 = and tried installing lang/gcc491 first then reinstalling lang/clang36 = (so it would bootstrap via gcc491). The result was the same as for lang/gcc5: llvm[4]: Compiling MSVCToolChain.cpp for Release build MSVCToolChain.cpp: In member function 'bool = clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::string&, = int&, int&) const': MSVCToolChain.cpp:215:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); ^ So gcc 4.8.4 (lang/gcc) is the odd one out here (since it the one of the = 3 that does not complain about ::sscanf use). I have another build of lang/gcc5 and then of lang/clang36 going based = on adding: #include to MSVCToolChain.cpp to see if the problem goes away for gcc5 based on = having the only guaranteed-sufficient header explicitly included. We will see what that shows. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 10:36 PM, Mark Millard = wrote: The last powerpc (non-64) build test to complete ran where only = built-in-world compilers originally existed (gcc 4.2.1 and clang 3.4.1 = this time. For this context "portmaster -tDK --no-confirm lang/clang36" = initiated installing lang/gcc (i.e., 4.8.4 at this point) in order to = provide itself with a compiler to bootstrap with. The result: no failures and a full clang 3.6 installation by being = bootstrapped via gcc 4.8.4. So gcc 4.8.4 vs. gcc5 makes a difference. But before blaming gcc5 = specifically... Here is what I would guess is going on: llvm's source code sometimes uses and other times . (I = did find with grep's.) One would have to trace all the headers actually = included for MSVCToolChain.cpp, directly or indirectly, and see which = one(s) are involved. But for ::sscanf notation they should be explicitly including = somewhere for that context. (Having in addition is fine.) The rule is as follows, using an example. The C++ standard (various = vintages) has at least one vintage that uses vs. as = an example for... "The header assuredly provides its declarations and = definitions within the namespace std. It may also provide these names = within the global namespace. The header assuredly provides = the same declarations and definitions within the global namespace, much = as in the C Standard. It may also provide these names within the = namespace std." So... only guarantees: int std::sscanf( const char* buffer, const char* format, ... ); only guarantees: int ::sscanf( const char* buffer, const char* format, ... ); But either file is allowed to (not required to) also declare/define the = other alternative as well. In other words: For portable code the burden of selecting appropriately = is on the folks including the headers. Otherwise just because it "works" = in one valid toolchain does not mean it is guaranteed to work in another = valid one. gcc5 may well provide fewer of the optional declarations/definitions for = some headers. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 08:37 PM, Mark Millard = wrote: I tried "portmaster -tDK --no-confirm lang/clang36" on a powerpc = (non-64): $ freebsd-version -ku ; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Mon Mar = 9 22:24:27 PDT 2015 = root@FBSDG4S0:/usr/obj/usr/srcC/sys/GENERICvtsc-NODEBUG powerpc powerpc Again it used gcc5 to bootstrap, my having installed gcc5 recently, no = other non-built-in-world compilers ever having been installed before. No = clang of any kind to start with. Just gcc 4.2.1. No changes to = lang/clang36. Just: portmaster -tDK --no-confirm lang/clang36 Again it had the same MSVCToolChain.cpp problem: llvm[4]: Compiling MSVCToolChain.cpp for Release build MSVCToolChain.cpp: In member function 'bool = clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::__cxx11::s= tring&, int&, int&) const': MSVCToolChain.cpp:215:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); ^ Like before when I had installed gcc5 it had no troubles installing and = I made no changes. I have another build test running where only built-in-world compilers = existed (gcc 4.2.1 and clang 3.4.1). For this context "portmaster -tDK = --no-confirm lang/clang36" initiated installing lang/gcc (i.e., 4.8.4 at = this point) in order to provide itself with a compiler to bootstrap = with. We will see how that one does. It takes longer since 2 compilers = are being installed. (I started this one first but it is not done yet.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 05:18 PM, Mark Millard = wrote: Basic context (more context details listed later): # freebsd-version -ku; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar = 11 19:23:14 PDT 2015 = root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBU= G powerpc powerpc64 The problem: portmaster -tDK --no-confirm lang/clang36 is how I started the build. The error reported was for in MSVCToolChain.cpp's member function: bool = clang::driver::toolchains::getWindowsSDKDir(std::__cxx1:string&,int&, = int&) const The report was: MSVCToolChain.cpp:25:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. And it not = being likely to be powerpc64 specific would be my guess. May be that it = bootstrapped via gcc5? I've not yet tried from a powerpc (non-64) = FreeBSD build. Context details: # svnlite info /usr/ports/lang/clang36 Path: lang/clang36 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 Relative URL: ^/head/lang/clang36 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: brooks Last Changed Rev: 380295 Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) It used gcc5 to bootstrap as there was no clang present and that is the = only gcc port installed: # svnlite info /usr/ports/lang/gcc5 Path: lang/gcc5 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 Relative URL: ^/head/lang/gcc5 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: gerald Last Changed Rev: 380943 Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) # more /etc/make.conf #CPP=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ports@FreeBSD.ORG Wed Mar 18 03:02:52 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75846AEB for ; Wed, 18 Mar 2015 03:02:52 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 28F72BD3 for ; Wed, 18 Mar 2015 03:02:51 +0000 (UTC) Received: (qmail 19723 invoked from network); 18 Mar 2015 03:02:49 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 18 Mar 2015 03:02:49 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 17 Mar 2015 23:02:49 -0400 (EDT) Received: (qmail 526 invoked from network); 18 Mar 2015 03:02:49 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Mar 2015 03:02:49 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id C28601C439E; Tue, 17 Mar 2015 20:02:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets error: llvm-build: error: invalid native target: 'powerpc64' (not in project) From: Mark Millard In-Reply-To: <160E2B60-047A-4E5B-A258-334155CDEC0B@dsl-only.net> Date: Tue, 17 Mar 2015 20:02:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1E76AC30-BCB1-4FEE-8FA5-5EECF1F757E8@dsl-only.net> References: <9682273F-8B85-4351-AB2B-011240D40327@dsl-only.net> <160E2B60-047A-4E5B-A258-334155CDEC0B@dsl-only.net> To: FreeBSD PowerPC ML , freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 03:02:52 -0000 patch-utils_llvm-build_llvmbuild_main.py is missing a powerpc64 entry, = such as illustrated below. $ svnlite diff /usr/ports/lang/clang36 Index: = /usr/ports/lang/clang36/files/patch-utils_llvm-build_llvmbuild_main.py =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- = /usr/ports/lang/clang36/files/patch-utils_llvm-build_llvmbuild_main.py = (revision 381120) +++ = /usr/ports/lang/clang36/files/patch-utils_llvm-build_llvmbuild_main.py = (working copy) @@ -3,7 +3,7 @@ =20 --- utils/llvm-build/llvmbuild/main.py.orig +++ utils/llvm-build/llvmbuild/main.py -@@ -633,7 +633,13 @@ +@@ -633,7 +633,14 @@ =20 # We handle a few special cases of target names here for = historical # reasons, as these are the names configure currently comes up = with. @@ -13,6 +13,7 @@ + 'i386' : 'X86', + 'mips' : 'Mips', + 'powerpc' : 'PowerPC', ++ 'powerpc64' : 'PowerPC', + 'sparc64' : 'Sparc', + 'x86' : 'X86', 'x86_64' : 'X86', =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 11:00 PM, Mark Millard = wrote: The 2 powerpc (non-64) build attempts for clang 3.6 did not get this = problem. So this specific problem is powerpc64 specific. Bootstrapping powerpc (non-64) clang 3.6 via gcc 4.8.4 (the current = lang/gcc) works fine. (In absence of any c++ port lang/clang36 = automatically installed lang/gcc (currently gcc 4.8.4) in order to = bootstrap itself.) Bootstrapping powerpc (non-64) clang 3.6 via gcc5 (by having lang/gcc5 = already installed first) still reports an error for not declaring = ::sscanf, just like powerpc64 based on gcc5 for bootstrapping did. (This might be llvm/clang making use of only where an include = of would be required to be involved in order to guarantee the = :: (global) declaration/definition. The way the C++ standard (all = vintages) is written gcc 4.8.4 and gcc5 could be this different and both = be valid/conforming.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 05:04 PM, Mark Millard = wrote: Basic context (more context details listed later): # freebsd-version -ku; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar = 11 19:23:14 PDT 2015 = root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBU= G powerpc powerpc64 The problem: portmaster -tDK --no-confirm lang/clang36 is how I started the build. The error report was after it reported entering the directory: = /usr/obj/portswork/usr/ports/lang/clang36/work/llvm-3.6.0.src/tools/clang/= lib/Driver/ The report was: llvm-build: error: invalid native target: 'powerpc64' (not in project) I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. But powerpc64 = likely does. I've not yet tried from a powerpc (non-64) FreeBSD build. I'll note that with top -PaSCHopid I watched it compile the PowerPc code = generator software: it shoudl be able to handle PowerPCs fine. My guess is a conversion of naming conventions is required someplace: FreeBSD using powerpc64 vs. clang using ppc64. (Big endian context.) This likely would matter for little endian naming as well (ppc64le on = the clang end of things I expect).=20 Context details: # svnlite info /usr/ports/lang/clang36 Path: lang/clang36 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 Relative URL: ^/head/lang/clang36 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: brooks Last Changed Rev: 380295 Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) It used gcc5 to bootstrap as there was no clang present and that is the = only gcc port installed: # svnlite info /usr/ports/lang/gcc5 Path: lang/gcc5 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 Relative URL: ^/head/lang/gcc5 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: gerald Last Changed Rev: 380943 Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) # more /etc/make.conf #CPP=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ports@FreeBSD.ORG Wed Mar 18 06:49:08 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4EB73196 for ; Wed, 18 Mar 2015 06:49:08 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 03390274 for ; Wed, 18 Mar 2015 06:49:07 +0000 (UTC) Received: (qmail 22522 invoked from network); 18 Mar 2015 06:49:06 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 18 Mar 2015 06:49:06 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Wed, 18 Mar 2015 02:49:06 -0400 (EDT) Received: (qmail 12148 invoked from network); 18 Mar 2015 06:49:05 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Mar 2015 06:49:05 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 65EC31C4052; Tue, 17 Mar 2015 23:49:04 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 10.1-STABLE [WITH_DEBUG] context; cmake's /usr/local/bin/ctest broken but graphics/png configuration defaults use it From: Mark Millard In-Reply-To: <21202F99-B759-4888-8C7E-5F65D4346F96@dsl-only.net> Date: Tue, 17 Mar 2015 23:49:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54FC7D92.3010405@freebsd.org> <021318C0-0D3C-4950-AFB5-9B15E3BD3376@dsl-only.net> <21202F99-B759-4888-8C7E-5F65D4346F96@dsl-only.net> To: freebsd-toolchain@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-ports@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 06:49:08 -0000 Looks like I forgot to forward Brad King's 2015-Mar-11 note that KWSys = and CMake have the "static" fix that allows non-inlining debug builds of = ctest and other programs to handle the TOC register usage appropriately: > The change is now in KWSys 'master' and I've updated > the copy within CMake: >=20 > KWSys 2015-03-10 (4a698414) > http://cmake.org/gitweb?p=3Dcmake.git;a=3Dcommitdiff;h=3D9a427f86 >=20 > Merge branch 'upstream-kwsys' into update-kwsys > http://cmake.org/gitweb?p=3Dcmake.git;a=3Dcommitdiff;h=3De433223d >=20 > -Brad =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-10, at 01:11 PM, Mark Millard = wrote: Brad King is adding the missing static to _stl_next_prime in KWSys and = from there it will eventually propagate into CMake's code base. Actually = in KWSys both static's are to be added. ( = http://review.source.kitware.com/#/c/19465/ ) Brad wrote that CMake's code base had added the static to = _get_stl_prime_list to handle a linking problem in some environment. = (Despite not knowing of KWSys I had guessed that there was some reason = why that static was there: that is why I suggested the direction of = making _stl_next_prime match instead of suggesting removing the static = on _get_stl_prime_list.) Once propagated the updates will make KWSys and = CMake's code again match in this area. So eventually FreeBSD should pick up a fix that should allow WITH_DEBUG=3D= to be better behaved for CMake's programs that use it's hashtable.hxx . =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-9, at 08:09 AM, Mark Millard wrote: I've discovered why/how WITH_DEBUG=3D ends up with cmake's = /usr/local/bin/ctest messed up for PIC code generation (powerpc64 = context). A source code fix that avoids the problem is likely to change = cmake's hashtable.hxx that has inline size_t _stl_next_prime(size_t __n) { const unsigned long* __first =3D get_stl_prime_list(); const unsigned long* __last =3D get_stl_prime_list() + = (int)_stl_num_primes; const unsigned long* pos =3D cmsys_stl::lower_bound(__first, __last, = __n); return pos =3D=3D __last ? *(__last - 1) : *pos; } to also indicate static for it like the .hxx file has for static inline const unsigned long* get_stl_prime_list() { static const unsigned long _stl_prime_list[_stl_num_primes] =3D { 5ul, 11ul, 23ul, 53ul, 97ul, 193ul, 389ul, 769ul, 1543ul, 3079ul, 6151ul, 12289ul, 24593ul, 49157ul, 98317ul, 196613ul, 393241ul, 786433ul, 1572869ul, 3145739ul, 6291469ul, 12582917ul, 25165843ul, 50331653ul, 100663319ul, 201326611ul, 402653189ul, 805306457ul, 1610612741ul, 3221225473ul, 4294967291ul }; return &_stl_prime_list[0]; } NOTE: _stl_next_prime has the only calls to _get_stl_prime_list that = exist in the source code. The details for what is going on follow... There are 7 instances of get_stl_prime_list's code in my = /usr/local/bin/ctest, each with differing %r2 offsets for differing %r2 = values to allow finding appropriate _stl_prime_list addresses in various = places that include the header file. Each code instance from my build's = /usr/local/bin/ctest is shown below. (Note that the = ._ZN5cmsysL18get_stl_prime_listEv name does not vary despite the = distinct addresses.) But there is only 1 instance of _stl_next_prime's code in = /usr/local/bin/ctest, also shown below. This routine directly calls the = first of the ._ZN5cmsysL18get_stl_prime_listEv routines below, = effectively forcing the %r2 offset from that code to always be used = --and so generating garbage addresses for 6 of the 7 static contexts. 6 of the ._ZN5cmsysL18get_stl_prime_listEv's are completely unused. But most of the initial usage of _stl_next_prime in execution order = happens to have the %r2 value that goes with the first = ._ZN5cmsysL18get_stl_prime_listEv routine. That is why = /usr/local/bin/ctest dies as late as it does. I have observed the indicated behavior leading up to the crash under gdb = as well. 00000000101751c0 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 00000000101751c4 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 00000000101751c8 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 00000000101751cc <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-2976(r2) 00000000101751d0 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 00000000101751d4 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 00000000101751d8 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 00000000101751dc <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 00000000101751e0 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 00000000101751e4 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 00000000101751e8 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 000000001017c028 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 000000001017c02c <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 000000001017c030 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 000000001017c034 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-2720(r2) 000000001017c038 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 000000001017c03c <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 000000001017c040 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 000000001017c044 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 000000001017c048 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 000000001017c04c <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 000000001017c050 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 00000000101f4ae8 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 00000000101f4aec <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 00000000101f4af0 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 00000000101f4af4 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,2088(r2) 00000000101f4af8 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 00000000101f4afc <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 00000000101f4b00 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 00000000101f4b04 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 00000000101f4b08 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 00000000101f4b0c <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 00000000101f4b10 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 000000001029161c <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 0000000010291620 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 0000000010291624 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 0000000010291628 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,11344(r2) 000000001029162c <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 0000000010291630 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 0000000010291634 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 0000000010291638 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 000000001029163c <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 0000000010291640 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 0000000010291644 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 00000000103cde60 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 00000000103cde64 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 00000000103cde68 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 00000000103cde6c <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-32728(r2) 00000000103cde70 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 00000000103cde74 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 00000000103cde78 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 00000000103cde7c <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 00000000103cde80 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 00000000103cde84 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 00000000103cde88 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 000000001041bf4c <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 000000001041bf50 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 000000001041bf54 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 000000001041bf58 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-26608(r2) 000000001041bf5c <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 000000001041bf60 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 000000001041bf64 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 000000001041bf68 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 000000001041bf6c <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 000000001041bf70 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 000000001041bf74 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 00000000104719ec <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 00000000104719f0 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 00000000104719f4 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 00000000104719f8 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-21280(r2) 00000000104719fc <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 0000000010471a00 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 0000000010471a04 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 0000000010471a08 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 0000000010471a0c <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 0000000010471a10 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 0000000010471a14 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) And here is the only _stl_next_prime routine: 0000000010176174 <._ZN5cmsys15_stl_next_primeEm> mflr r0 0000000010176178 <._ZN5cmsys15_stl_next_primeEm+0x4> std r31,-8(r1) 000000001017617c <._ZN5cmsys15_stl_next_primeEm+0x8> std r0,16(r1) 0000000010176180 <._ZN5cmsys15_stl_next_primeEm+0xc> stdu r1,-176(r1) 0000000010176184 <._ZN5cmsys15_stl_next_primeEm+0x10> mr r31,r1 0000000010176188 <._ZN5cmsys15_stl_next_primeEm+0x14> std = r3,224(r31) 000000001017618c <._ZN5cmsys15_stl_next_primeEm+0x18> bl = 00000000101751c0 <._ZN5cmsysL18get_stl_prime_listEv> 0000000010176190 <._ZN5cmsys15_stl_next_primeEm+0x1c> mr r0,r3 0000000010176194 <._ZN5cmsys15_stl_next_primeEm+0x20> std = r0,128(r31) 0000000010176198 <._ZN5cmsys15_stl_next_primeEm+0x24> bl = 00000000101751c0 <._ZN5cmsysL18get_stl_prime_listEv> 000000001017619c <._ZN5cmsys15_stl_next_primeEm+0x28> mr r9,r3 00000000101761a0 <._ZN5cmsys15_stl_next_primeEm+0x2c> addi r0,r9,248 00000000101761a4 <._ZN5cmsys15_stl_next_primeEm+0x30> std = r0,120(r31) 00000000101761a8 <._ZN5cmsys15_stl_next_primeEm+0x34> ld = r3,128(r31) 00000000101761ac <._ZN5cmsys15_stl_next_primeEm+0x38> ld = r4,120(r31) 00000000101761b0 <._ZN5cmsys15_stl_next_primeEm+0x3c> addi r0,r31,224 00000000101761b4 <._ZN5cmsys15_stl_next_primeEm+0x40> mr r5,r0 00000000101761b8 <._ZN5cmsys15_stl_next_primeEm+0x44> bl = 0000000010176090 <._ZSt11lower_boundIPKmmET_S2_S2_RKT0_> 00000000101761bc <._ZN5cmsys15_stl_next_primeEm+0x48> crmove = 4*cr7+so,4*cr7+so 00000000101761c0 <._ZN5cmsys15_stl_next_primeEm+0x4c> mr r0,r3 00000000101761c4 <._ZN5cmsys15_stl_next_primeEm+0x50> std = r0,112(r31) 00000000101761c8 <._ZN5cmsys15_stl_next_primeEm+0x54> ld = r9,112(r31) 00000000101761cc <._ZN5cmsys15_stl_next_primeEm+0x58> ld = r0,120(r31) 00000000101761d0 <._ZN5cmsys15_stl_next_primeEm+0x5c> cmpd cr7,r9,r0 00000000101761d4 <._ZN5cmsys15_stl_next_primeEm+0x60> bne- = cr7,00000000101761ec <._ZN5cmsys15_stl_next_primeEm+0x78> 00000000101761d8 <._ZN5cmsys15_stl_next_primeEm+0x64> ld = r9,120(r31) 00000000101761dc <._ZN5cmsys15_stl_next_primeEm+0x68> addi r9,r9,-8 00000000101761e0 <._ZN5cmsys15_stl_next_primeEm+0x6c> ld r9,0(r9) 00000000101761e4 <._ZN5cmsys15_stl_next_primeEm+0x70> std = r9,144(r31) 00000000101761e8 <._ZN5cmsys15_stl_next_primeEm+0x74> b = 00000000101761f8 <._ZN5cmsys15_stl_next_primeEm+0x84> 00000000101761ec <._ZN5cmsys15_stl_next_primeEm+0x78> ld = r9,112(r31) 00000000101761f0 <._ZN5cmsys15_stl_next_primeEm+0x7c> ld r9,0(r9) 00000000101761f4 <._ZN5cmsys15_stl_next_primeEm+0x80> std = r9,144(r31) 00000000101761f8 <._ZN5cmsys15_stl_next_primeEm+0x84> ld = r0,144(r31) 00000000101761fc <._ZN5cmsys15_stl_next_primeEm+0x88> mr r3,r0 0000000010176200 <._ZN5cmsys15_stl_next_primeEm+0x8c> ld r1,0(r1) 0000000010176204 <._ZN5cmsys15_stl_next_primeEm+0x90> ld r0,16(r1) 0000000010176208 <._ZN5cmsys15_stl_next_primeEm+0x94> mtlr r0 000000001017620c <._ZN5cmsys15_stl_next_primeEm+0x98> ld r31,-8(r1) 0000000010176210 <._ZN5cmsys15_stl_next_primeEm+0x9c> blr 0000000010176214 <._ZN5cmsys15_stl_next_primeEm+0xa0> .long 0x0 0000000010176218 <._ZN5cmsys15_stl_next_primeEm+0xa4> .long 0x90001 000000001017621c <._ZN5cmsys15_stl_next_primeEm+0xa8> lwz r0,1(r1) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-8, at 06:35 PM, Mark Millard wrote: Thanks for the note. It is useful to know the variation from my context. You were not explicit but because you mention POWER8 I'd guess that you = were reporting based on 11.0-CURRENT. I have not yet established an = 11.0-CURRENT boot-context, although I plan to at some point. powerpc64 vs. powerpc builds give different results... For powerpc64 I decided to "pkg delete '*'", check /usr/local/... and = /var/db/pkg/..., and start a rebuild of all my ports to see what = happens. For powerpc I'm just establishing a boot-SSD context now. The activity for both has gotten past cmake and I get the following = results for ctest on the G5s where the builds are running: powerpc64 build: ctest still messed up with std::length_error from = vector::reserve. powerpc build: ctest works fine. Both are being run on PowerMac G5s. Both are still building more ports. As for potential HW problems and HW configuration problems: I have access to 3 PowerMac G5's and they all behaved the same for each = specific build: PowerMac11,2 (Quad-Core) G5 with 16GBytes ECC RAM PowerMac11,2 (Quad-Core) G5 with 12GBytes RAM PowerMac7,2 (Dual-processor) G5 with 8GBytes RAM All of these have only one board installed: the video board. Normally = there is only one "disk" present when in use: a boot SSD on ada0. The only common HW element in my testing G5 behavior is my moving my = boot SSD that I'm testing. Non-SSD hardware is rarely the issue with anything that I report unless = I'm reporting differences in behavior between the PowerMacs that I have = access to for the type of build involved: I have a compare/contrast = environment available for my testing and I use it. [I have access to multiple G4 PowerMacs of various vintages and a G3 = PowerMac as well, similarly minimal configurations. But I'm only now = re-establishing having a FreeBSD context for these after mostly = abandoning them for much of the 9-10 months while I was investigating = the frequent PowerMac G5 early-boot-crash problems as my primary FreeBSD = activity.] The powerpc64 PowerMac G5 boot-SSD content that I use for 10.1-STABLE = and 10.1-RELENG could certainly be suspect in some way. :) I mostly use = 10.1-STABLE, currently: $ freebsd-version -ku; uname -a 10.1-STABLE 10.1-STABLE FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar 6 = 23:08:59 PST 2015 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc = powerpc As for other configuration points: See my original note for more details on the difference from the = official world/kernel materials. There is also /boot/loader.conf picking = out a kernel (I use INSTKERNNAME=3D with non-default names mostly) and = picking out vt vs. sc, /etc/fstab, /etc/rc.conf (hostname, ifconfig_ = for ethernet, ntpd_, dumpdev, hald_enable, dbus_enable), = /etc/sysctl.conf for /var/crash/ related items. Counting the original = note's list of differences: Not much else is different from the = default/official materials. For ports configurations: Before I had suspended trying to track the = ports status I historically had used almost every default selection, = something like 2 to 6 non-default selections. (I keep a snapshot of = /var/db/ports/... as a reference/reminder.) I've got the same policy for = trying to re-establish the ports now that I can reliably boot the G5s. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-8, at 09:49 AM, Nathan Whitehorn = wrote: This works fine for me. Are you sure you don't have some weird = configuration or hardware problem? -Nathan On 03/07/15 22:56, Mark Millard wrote: > powerpc64 context (more details are listed much later): >=20 > $ freebsd-version -ku; uname -a > 10.1-STABLE > 10.1-STABLE > FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar = 6 23:08:59 PST 2015 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc = powerpc >=20 > Ports Revision 380683 via svnlite update. I've been using portmaster. >=20 >=20 > The problem (which I've not figured out yet)... >=20 > When png-1.6.16 has PNGTEST enabled (default and "recommended") it = tries to use cmake's /usr/local/bin/ctest. But in my context ctest is = broken, trying to reserve 2305843009213693952 Hashtable_node<...>*'s = [see #8's ...::reserve (..., __n=3D...) below] when = _M_initialize_buckets(..., __n=3D100) in #9. (Note: 2305843009213693952 = =3D=3D 0x2000000000000000.) I have yet to figure out how that magic = number is becoming involved. See below from one of the crash dumps: >=20 > #0 0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7 > [New Thread 51c06400 (LWP 100091/ctest)] > (gdb) bt > #0 0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7 > #1 0x0000000050d171ac in .__raise () from /lib/libc.so.7 > #2 0x0000000050d15788 in .abort () from /lib/libc.so.7 > #3 0x00000000514c9ae0 in = ._ZN9__gnu_cxx27__verbose_terminate_handlerEv () from = /usr/lib/libsupc++.so.1 > #4 0x00000000514cf1d8 in ._ZSt14set_unexpectedPFvvE () from = /usr/lib/libsupc++.so.1 > #5 0x00000000514cf230 in ._ZSt9terminatev () from = /usr/lib/libsupc++.so.1 > #6 0x00000000514cf0dc in .__cxa_throw () from /usr/lib/libsupc++.so.1 > #7 0x0000000050ab4e54 in ._ZSt20__throw_length_errorPKc () from = /usr/lib/libstdc++.so.6 > #8 0x000000001024659c in = std::vector >*, = std::allocator >*> >::reserve (this=3D0xffffffffffffb108, = __n=3D2305843009213693952) at vector.tcc:72 > #9 0x00000000104749bc in cmsys::hashtable, std::string, cmsys::hash, = cmsys::hash_select1st, = std::equal_to, std::allocator = >::_M_initialize_buckets (this=3D0xffffffffffffb100, __n=3D100) at = hashtable.hxx:797 > #10 0x0000000010474ae4 in hashtable (this=3D0xffffffffffffb100, = __n=3D100, __hf=3D@0xffffffffffffaeb2, __eql=3D@0xffffffffffffaeb1, = __a=3D@0xffffffffffffaeb0) at hashtable.hxx:545 > #11 0x0000000010474bb8 in hash_map (this=3D0xffffffffffffb100) at = hash_map.hxx:113 > #12 0x0000000010472ba4 in cmDefinitions (this=3D0xffffffffffffb0f8, = parent=3D0x0) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmDefinit= ions.cxx:19 > #13 0x000000001020dc40 in cmMakefile (this=3D0x51cb1800) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmMakefil= e.cxx:56 > #14 0x00000000101efb0c in cmLocalGenerator::SetGlobalGenerator = (this=3D0x51c3f480, gg=3D0xffffffffffffc138) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmLocalGe= nerator.cxx:244 > #15 0x00000000101874b0 in cmGlobalGenerator::CreateLocalGenerator = (this=3D0xffffffffffffc138) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmGlobalG= enerator.cxx:1906 > #16 0x00000000100224dc in cmCTest::Initialize = (this=3D0xffffffffffffcf50, binary_dir=3D0x51c890f8 = "/usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16", = command=3D0x0) > at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.c= xx:511 > #17 0x000000001002c704 in cmCTest::Run (this=3D0xffffffffffffcf50, = args=3D@0xffffffffffffcb80, output=3D0xffffffffffffcb98) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.c= xx:2474 > #18 0x0000000010010c10 in main (argc=3D2, argv=3D0x51c1a040) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/ctest.cxx= :189 > #19 0x000000001000fc9c in ._start () > #20 0x000000005074c8a0 in .text () from /libexec/ld-elf.so.1 >=20 > The specific Makefile code to invoke ctest is... >=20 > # Special rule for the target test > test: > @$(CMAKE_COMMAND) -E cmake_echo_color --switch=3D$(COLOR) --cyan = "Running tests..." > /usr/local/bin/ctest --force-new-ctest-process $(ARGS) > .PHONY : test > # Special rule for the target test > test/fast: test > .PHONY : test/fast >=20 > which because of ctest's problem leads to... >=20 > ... > Linking C executable pngvalid > [100%] Built target pngvalid > (cd /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16; if ! = /usr/bin/env = XDG_DATA_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = XDG_CONFIG_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR=3D"/tmp" = XDG_DATA_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = XDG_CONFIG_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR=3D"/tmp" = DONTSTRIP=3Dyes NO_PIE=3Dyes SHELL=3D/bin/sh NO_LINT=3DYES = PREFIX=3D/usr/local LOCALBASE=3D/usr/local LIBDIR=3D"/usr/lib" = CC=3D"cc" CFLAGS=3D"-pipe -g -fno-strict-aliasing" CPP=3D"cpp" = CPPFLAGS=3D"" LDFLAGS=3D"" LIBS=3D"" CXX=3D"c++" CXXFLAGS=3D"-pipe -g = -fno-strict-aliasing " MANPREFIX=3D"/usr/local" = BSD_INSTALL_PROGRAM=3D"install -o root -g wheel -m 555" = BSD_INSTALL_LIB=3D"install -o root -g wheel -m 444" = BSD_INSTALL_SCRIPT=3D"install -o root -g wheel -m 555" = BSD_INSTALL_DATA=3D"install -o root -g wheel -m 0644" = BSD_INSTALL_MAN=3D"instal! > l -o roo > t -g wheel -m 444" /usr/bin/make -f Makefile -j4 = DESTDIR=3D/usr/obj/portswork/usr/ports/graphics/png/work/stage test; = then if [ x !=3D xTry to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before = reporting the failure to the maintainer. ] ; then echo "=3D=3D=3D> = Compilation failed unexpectedly."; (echo Try to set = MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the failure to the = maintainer.) | /usr/bin/fmt 75 79 ; fi; false; fi) > Running tests... > terminate called after throwing an instance of 'std::length_error' > what(): vector::reserve > Abort trap (core dumped) > *** [test] Error code 134 >=20 > make[2]: stopped in = /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16 > 1 error >=20 > make[2]: stopped in = /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16 > [: xTry: unexpected operator > *** Error code 1 >=20 > Stop. > make[1]: stopped in /usr/ports/graphics/png > *** Error code 1 >=20 > Stop. > make: stopped in /usr/ports/graphics/png >=20 >=20 > Even just ctest as a command gets the vector::reserve size problem = from the large magic number: >=20 > $ ctest > ********************************* > No test configuration file found! > ********************************* > terminate called after throwing an instance of 'std::length_error' > what(): vector::reserve > Abort trap (core dumped) >=20 >=20 > [So far I've only sidestepped having graphic/png run ctest to allow = some things that depend on graphics/png to not be blocked by this.] >=20 >=20 >=20 >=20 > For my context the overall environment has (but ports might force = other ports as alternatives to): >=20 > # more /etc/make.conf > #CPP=3Dclang-cpp > #CC=3Dclang > #CXX=3Dclang++ > WRKDIRPREFIX=3D/usr/obj/portswork > WITH_DEBUG=3D > MALLOC_PRODUCTION=3D >=20 > # more /etc/src.conf > #CPP=3Dclang-cpp > #CC=3Dclang > #CXX=3Dclang++ > #CFLAGS+=3D-DELF_VERBOSE > #WITH_DEBUG_FILES=3D > #WITHOUT_CLANG=3D >=20 > # which cc > /usr/bin/cc >=20 > # cc --version > cc (GCC) 4.2.1 20070831 patched [FreeBSD] > Copyright (C) 2007 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There = is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR = PURPOSE. >=20 > # which clang > /usr/bin/clang >=20 > # clang --version > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) = 20140512 > Target: powerpc64-unknown-freebsd10.1 > Thread model: posix >=20 >=20 >=20 >=20 >=20 > Other context details: >=20 > $ cd /usr/ports > $ svnlite info > Path: . > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 380683 > Node Kind: directory > Schedule: normal > Last Changed Author: demon > Last Changed Rev: 380683 > Last Changed Date: 2015-03-07 03:31:11 -0800 (Sat, 07 Mar 2015) >=20 > $ svnlite st --no-ignore > ? .snap > I distfiles > M graphics/libGL/bsd.mesalib.mk > I packages > ? restoresymtable >=20 > $ svnlite diff graphics/libGL/bsd.mesalib.mk > Index: graphics/libGL/bsd.mesalib.mk > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- graphics/libGL/bsd.mesalib.mk (revision 380683) > +++ graphics/libGL/bsd.mesalib.mk (working copy) > @@ -136,6 +136,10 @@ > CONFIGURE_ARGS+=3D--enable-vdpau > .endif >=20 > +.if ${ARCH} =3D=3D powerpc64 > +CFLAGS+=3D -mminimal-toc > +.endif > + > post-patch: > @${REINPLACE_CMD} -e 's|-ffast-math|${FAST_MATH}|' -e = 's|x86_64|amd64|' \ > ${WRKSRC}/configure >=20 > $ cd /usr/src > $ svnlite info > Path: . > Working Copy Root Path: /usr/src > URL: https://svn0.us-west.freebsd.org/base/stable/10 > Relative URL: ^/stable/10 > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 279507 > Node Kind: directory > Schedule: normal > Last Changed Author: ngie > Last Changed Rev: 279507 > Last Changed Date: 2015-03-01 14:12:24 -0800 (Sun, 01 Mar 2015) >=20 > $ svnlite st --no-ignore > ? .snap > ? restoresymtable > M sys/ddb/db_main.c > M sys/ddb/db_script.c > I sys/powerpc/conf/GENERIC64vtsc > I sys/powerpc/conf/GENERICvtsc > M sys/powerpc/ofw/ofw_machdep.c > M sys/powerpc/ofw/ofwcall64.S > M sys/powerpc/powerpc/dump_machdep.c >=20 > sys/powerpc/ofw/ofw_machdep.c has a PowerMac G5 specific change to = avoid intermittent boot problems. >=20 > sys/ddb/... and sys/powerpc/ofw/ofwcall64.S are just to help me get = evidence if I do end up with another early-boot failure. DDB and GDB are = listed in sys/powerpc/conf/GENERIC64vtsc for the same reason. >=20 > sys/powerpc/powerpc/dump_machdep.c is from me forcing the DMA transfer = size for dumps to be small enough not to be rejected as too large of a = DMA request size. >=20 > sys/powerpc/conf/GENERIC64vtsc turns off ps3 in order to turn on both = vt and sc. It includes the standard GENERIC64. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >=20 From owner-freebsd-ports@FreeBSD.ORG Wed Mar 18 09:50:42 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 992B2A3F for ; Wed, 18 Mar 2015 09:50:42 +0000 (UTC) Received: from portscout.freebsd.org (portscout.freebsd.org [IPv6:2001:1900:2254:206a::50:6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 83854BD1 for ; Wed, 18 Mar 2015 09:50:42 +0000 (UTC) Received: from portscout.freebsd.org ([127.0.1.123]) by portscout.freebsd.org (8.14.9/8.14.9) with ESMTP id t2I9ogXL002454 for ; Wed, 18 Mar 2015 09:50:42 GMT (envelope-from portscout@FreeBSD.org) Received: (from portscout@localhost) by portscout.freebsd.org (8.14.9/8.14.9/Submit) id t2I9ogWU002453; Wed, 18 Mar 2015 09:50:42 GMT (envelope-from portscout@FreeBSD.org) Message-Id: <201503180950.t2I9ogWU002453@portscout.freebsd.org> X-Authentication-Warning: portscout.freebsd.org: portscout set sender to portscout@FreeBSD.org using -f Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain MIME-Version: 1.0 Date: Wed, 18 Mar 2015 09:50:42 +0000 From: portscout@FreeBSD.org To: ports@freebsd.org Subject: FreeBSD ports you maintain which are out of date X-Mailer: portscout/0.8.1 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 09:50:42 -0000 Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/ports@freebsd.org.html Port | Current version | New version ------------------------------------------------+-----------------+------------ devel/gitg | 3.14.1 | 3.15.2 ------------------------------------------------+-----------------+------------ graphics/entangle | 0.6.1 | 0.7.0 ------------------------------------------------+-----------------+------------ textproc/py-jaxml | 3.02 | 20.00 ------------------------------------------------+-----------------+------------ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. From owner-freebsd-ports@FreeBSD.ORG Wed Mar 18 12:59:13 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A5188FF for ; Wed, 18 Mar 2015 12:59:13 +0000 (UTC) Received: from smtp205.alice.it (smtp205.alice.it [82.57.200.101]) by mx1.freebsd.org (Postfix) with ESMTP id 146F13E1 for ; Wed, 18 Mar 2015 12:59:12 +0000 (UTC) Received: from soth.ventu (79.2.52.145) by smtp205.alice.it (8.6.060.28) (authenticated as acanedi@alice.it) id 547D8A4D168E47F5; Wed, 18 Mar 2015 13:59:05 +0100 Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.15.1/8.14.9) with ESMTP id t2ICx37h056367; Wed, 18 Mar 2015 13:59:04 +0100 (CET) (envelope-from ml@netfence.it) Message-ID: <55097697.4050100@netfence.it> Date: Wed, 18 Mar 2015 13:59:03 +0100 From: Andrea Venturoli User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: ports@freebsd.org Subject: Netdisco Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dgeo@centrale-marseille.fr X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 12:59:13 -0000 Hello. After discovering this software from UPDATING, I decided to give it a try. The box is 8.4-RELEASE-p24/amd64 running PERL 5.18. What I get, however, is: > # netdisco-daemon status > Sorry, can't find libs required for App::Netdisco. > BEGIN failed--compilation aborted at /usr/local/bin/netdisco-daemon line 28. More or less this happens whatever Netdisco script I call. Where should I look into? I guess the culprit is: > BEGIN { > use Path::Class; However I have p5-Path-Class-0.35 installed. I already issued a "portupgrade -Rf netdisco", but it didn't help. Any help is appreciated. bye & Thanks av. From owner-freebsd-ports@FreeBSD.ORG Wed Mar 18 13:05:32 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4D451F1 for ; Wed, 18 Mar 2015 13:05:32 +0000 (UTC) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 65CF06DC for ; Wed, 18 Mar 2015 13:05:32 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YYDf8-000829-CC; Wed, 18 Mar 2015 14:05:30 +0100 Date: Wed, 18 Mar 2015 14:05:30 +0100 From: Kurt Jaeger To: Andrea Venturoli Subject: Re: Netdisco Message-ID: <20150318130530.GU62590@home.opsec.eu> References: <55097697.4050100@netfence.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55097697.4050100@netfence.it> Cc: ports@freebsd.org, dgeo@centrale-marseille.fr X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 13:05:32 -0000 Hi! > After discovering this software from UPDATING, I decided to give it a try. > > The box is 8.4-RELEASE-p24/amd64 running PERL 5.18. > > What I get, however, is: > > # netdisco-daemon status > > Sorry, can't find libs required for App::Netdisco. > > BEGIN failed--compilation aborted at /usr/local/bin/netdisco-daemon line 28. I can reproduce it om 10.1amd64 with perl 5.20.2. -- pi@opsec.eu +49 171 3101372 5 years to go ! From owner-freebsd-ports@FreeBSD.ORG Wed Mar 18 13:39:43 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2CAA5D5C for ; Wed, 18 Mar 2015 13:39:43 +0000 (UTC) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EB3F0B99 for ; Wed, 18 Mar 2015 13:39:42 +0000 (UTC) Received: by igbue6 with SMTP id ue6so43906899igb.1 for ; Wed, 18 Mar 2015 06:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=UBWsgka6nxo569YVP0KgZQXn/L1VctMU7mTZg9peoLA=; b=Jg0vuC56kN+JFifGaQ1IdLgR+nA4EMu5EnzUtpxaAM+O9kHOkkjoCKGNejOZITasNE GZFJaEvKtf5CkuT4VoFyj4bL38jSmC4FnGbnILndSXuzx2eqpiKWC6F8eYgS4AE+UWx3 Qo+EX1q20fHOq3Tjgw+h6535wf3avOd4A5pExquf498fHvErbKY8A3ZGthtV8zNxBn1N Seq13wcGhT7QSTlk4Kcm69CHJp4onyGOYYJiVlkjIwNPxG17rOtymi6mO6ME2rzjYwAs c+fQyzVaprKU7KDfC3LIsKo84RQGuaewQC5vlrMg3AD1yRjvyRJ7EdPjpGk0tNvUrf1V Vw3w== MIME-Version: 1.0 X-Received: by 10.43.66.131 with SMTP id xq3mr10227885icb.9.1426685982376; Wed, 18 Mar 2015 06:39:42 -0700 (PDT) Received: by 10.36.116.137 with HTTP; Wed, 18 Mar 2015 06:39:42 -0700 (PDT) Date: Wed, 18 Mar 2015 09:39:42 -0400 Message-ID: Subject: www/spawn-fcgi IPv6 Bugfix From: Robert Simmons To: "freebsd-ports@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 13:39:43 -0000 Greetings, Is there a committer available to review and commit the following. I have approved the patch: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198483 From owner-freebsd-ports@FreeBSD.ORG Wed Mar 18 13:44:05 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 086DEF23 for ; Wed, 18 Mar 2015 13:44:05 +0000 (UTC) Received: from talisker.lacave.net (talisker.lacave.net [217.112.180.250]) by mx1.freebsd.org (Postfix) with SMTP id 3C6B7C6C for ; Wed, 18 Mar 2015 13:44:03 +0000 (UTC) Received: (qmail 54571 invoked from network); 18 Mar 2015 13:37:21 -0000 Received: from localhost (HELO talisker.lacave.net) (127.0.0.1) by localhost with SMTP; 18 Mar 2015 13:37:21 -0000 X-Virus-Scanned: amavisd-new at lacave.net Received: from talisker.lacave.net ([127.0.0.1]) by talisker.lacave.net (talisker.lacave.net [127.0.0.1]) (amavisd-new, port 10025) with LMTP id D3sxAs7Gp4TT for ; Wed, 18 Mar 2015 14:37:20 +0100 (CET) Received: from MIDORI.local (unknown [192.168.2.72]) (using TLSv1.1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fred.meduse.lacave) by talisker.lacave.net (Postfix) with ESMTPSA id BFC5839805D for ; Wed, 18 Mar 2015 14:37:20 +0100 (CET) Date: Wed, 18 Mar 2015 14:37:19 +0100 From: "F. Senault" Reply-To: "F. Senault" Organization: Secte de l'Elephant Fuschia X-Priority: 3 (Normal) Message-ID: <1986004191.20150318143719@lacave.net> To: ports@freebsd.org Subject: Re: Netdisco In-Reply-To: <55097697.4050100@netfence.it> References: <55097697.4050100@netfence.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 13:44:05 -0000 Wednesday, March 18, 2015, 1:59:03 PM, you wrote: > Hello. > After discovering this software from UPDATING, I decided to give it a try. > The box is 8.4-RELEASE-p24/amd64 running PERL 5.18. > What I get, however, is: >> # netdisco-daemon status >> Sorry, can't find libs required for App::Netdisco. >> BEGIN failed--compilation aborted at /usr/local/bin/netdisco-daemon line 28. You need a NEDISCO_HOME env variable defined (by default, point it to /var/run/netdisco) : | 14:35 grappa:~# netdisco-daemon status | Sorry, can't find libs required for App::Netdisco. | BEGIN failed--compilation aborted at /usr/local/bin/netdisco-daemon line 28. | 14:35 grappa:~# setenv NETDISCO_HOME /var/run/netdisco | 14:35 grappa:~# netdisco-daemon status | Netdisco Daemon [Running] HTH, Fred From owner-freebsd-ports@FreeBSD.ORG Wed Mar 18 14:32:27 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A634E1B1; Wed, 18 Mar 2015 14:32:27 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id 7D2D32C1; Wed, 18 Mar 2015 14:32:27 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 419FE5A9F27; Wed, 18 Mar 2015 14:32:21 +0000 (UTC) Date: Wed, 18 Mar 2015 14:32:21 +0000 From: Brooks Davis To: Mark Millard Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets error: llvm-build: error: invalid native target: 'powerpc64' (not in project) Message-ID: <20150318143221.GB52442@spindle.one-eyed-alien.net> References: <9682273F-8B85-4351-AB2B-011240D40327@dsl-only.net> <160E2B60-047A-4E5B-A258-334155CDEC0B@dsl-only.net> <1E76AC30-BCB1-4FEE-8FA5-5EECF1F757E8@dsl-only.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline In-Reply-To: <1E76AC30-BCB1-4FEE-8FA5-5EECF1F757E8@dsl-only.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 14:32:27 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable It appears that I added powerpc64 (and several others) to the devel/llvm* ports version of this patch, but didn't do it for lang/clang*. I'll sync them up. -- Brooks On Tue, Mar 17, 2015 at 08:02:47PM -0700, Mark Millard wrote: > patch-utils_llvm-build_llvmbuild_main.py is missing a powerpc64 entry, su= ch as illustrated below. >=20 > $ svnlite diff /usr/ports/lang/clang36 > Index: /usr/ports/lang/clang36/files/patch-utils_llvm-build_llvmbuild_mai= n.py > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/ports/lang/clang36/files/patch-utils_llvm-build_llvmbuild_main.p= y (revision 381120) > +++ /usr/ports/lang/clang36/files/patch-utils_llvm-build_llvmbuild_main.p= y (working copy) > @@ -3,7 +3,7 @@ > =20 > --- utils/llvm-build/llvmbuild/main.py.orig > +++ utils/llvm-build/llvmbuild/main.py > -@@ -633,7 +633,13 @@ > +@@ -633,7 +633,14 @@ > =20 > # We handle a few special cases of target names here for historical > # reasons, as these are the names configure currently comes up with. > @@ -13,6 +13,7 @@ > + 'i386' : 'X86', > + 'mips' : 'Mips', > + 'powerpc' : 'PowerPC', > ++ 'powerpc64' : 'PowerPC', > + 'sparc64' : 'Sparc', > + 'x86' : 'X86', > 'x86_64' : 'X86', >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2015-Mar-16, at 11:00 PM, Mark Millard wrote: >=20 > The 2 powerpc (non-64) build attempts for clang 3.6 did not get this prob= lem. >=20 > So this specific problem is powerpc64 specific. >=20 > Bootstrapping powerpc (non-64) clang 3.6 via gcc 4.8.4 (the current lang/= gcc) works fine. (In absence of any c++ port lang/clang36 automatically ins= talled lang/gcc (currently gcc 4.8.4) in order to bootstrap itself.) >=20 > Bootstrapping powerpc (non-64) clang 3.6 via gcc5 (by having lang/gcc5 al= ready installed first) still reports an error for not declaring ::sscanf, j= ust like powerpc64 based on gcc5 for bootstrapping did. >=20 > (This might be llvm/clang making use of only where an include of= would be required to be involved in order to guarantee the :: (g= lobal) declaration/definition. The way the C++ standard (all vintages) is w= ritten gcc 4.8.4 and gcc5 could be this different and both be valid/conform= ing.) >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2015-Mar-16, at 05:04 PM, Mark Millard wrote: >=20 > Basic context (more context details listed later): >=20 > # freebsd-version -ku; uname -ap > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 1= 1 19:23:14 PDT 2015 root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/s= ys/GENERIC64vtsc-NODEBUG powerpc powerpc64 >=20 >=20 > The problem: >=20 > portmaster -tDK --no-confirm lang/clang36 is how I started the build. >=20 > The error report was after it reported entering the directory: >=20 > /usr/obj/portswork/usr/ports/lang/clang36/work/llvm-3.6.0.src/tools/clang= /lib/Driver/ >=20 > The report was: >=20 > llvm-build: error: invalid native target: 'powerpc64' (not in project) >=20 >=20 > I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. But powerpc64 l= ikely does. I've not yet tried from a powerpc (non-64) FreeBSD build. >=20 > I'll note that with top -PaSCHopid I watched it compile the PowerPc code = generator software: it shoudl be able to handle PowerPCs fine. >=20 > My guess is a conversion of naming conventions is required someplace: >=20 > FreeBSD using powerpc64 vs. clang using ppc64. (Big endian context.) >=20 > This likely would matter for little endian naming as well (ppc64le on the= clang end of things I expect).=20 >=20 >=20 >=20 >=20 > Context details: >=20 > # svnlite info /usr/ports/lang/clang36 > Path: lang/clang36 > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 > Relative URL: ^/head/lang/clang36 > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 381120 > Node Kind: directory > Schedule: normal > Last Changed Author: brooks > Last Changed Rev: 380295 > Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) >=20 > It used gcc5 to bootstrap as there was no clang present and that is the o= nly gcc port installed: >=20 > # svnlite info /usr/ports/lang/gcc5 > Path: lang/gcc5 > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 > Relative URL: ^/head/lang/gcc5 > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 381120 > Node Kind: directory > Schedule: normal > Last Changed Author: gerald > Last Changed Rev: 380943 > Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) >=20 > # more /etc/make.conf > #CPP=3Dclang-cpp > #CC=3Dclang > #CXX=3Dclang++ > WRKDIRPREFIX=3D/usr/obj/portswork > #WITH_DEBUG=3D > MALLOC_PRODUCTION=3D >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 >=20 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.o= rg" >=20 --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUJjHQACgkQXY6L6fI4GtSBuwCgsvPnavBdg0zrxEjKlle3mLjw qJMAoMAG5rw0I1GC/NbyzA7D23VR17Ju =fGr3 -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-freebsd-ports@FreeBSD.ORG Wed Mar 18 18:13:22 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B568307 for ; Wed, 18 Mar 2015 18:13:22 +0000 (UTC) Received: from melout.ec-m.fr (mel1.ec-m.fr [147.94.19.87]) by mx1.freebsd.org (Postfix) with ESMTP id 26E35254 for ; Wed, 18 Mar 2015 18:13:21 +0000 (UTC) Received: from dgeo.sysadm.ec-m.fr (dgeo.sysadm.ec-m.fr [147.94.19.169]) by director1.localdomain (Postfix) with ESMTPSA id ABAA999F5; Wed, 18 Mar 2015 14:31:08 +0000 (UTC) Message-ID: <55098D41.8050200@centrale-marseille.fr> Date: Wed, 18 Mar 2015 15:35:45 +0100 From: geoffroy desvernay User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Kurt Jaeger , Andrea Venturoli Subject: Re: Netdisco References: <55097697.4050100@netfence.it> <20150318130530.GU62590@home.opsec.eu> In-Reply-To: <20150318130530.GU62590@home.opsec.eu> OpenPGP: url=http://dgeo.perso.ec-m.fr/0x7C253D52.pgp Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7R4RdFmdo9fawDOMBiwFDkO3d5GE32Mof" Cc: ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 18:13:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7R4RdFmdo9fawDOMBiwFDkO3d5GE32Mof Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/18/2015 14:05, Kurt Jaeger wrote: > Hi! >=20 >> After discovering this software from UPDATING, I decided to give it a = try. >> >> The box is 8.4-RELEASE-p24/amd64 running PERL 5.18. >> >> What I get, however, is: >>> # netdisco-daemon status >>> Sorry, can't find libs required for App::Netdisco. >>> BEGIN failed--compilation aborted at /usr/local/bin/netdisco-daemon l= ine 28. >=20 > I can reproduce it om 10.1amd64 with perl 5.20.2. >=20 Exact: one have to use 'netdisco' user to launch these commands. I'll add this in pkg-message next time I modify the port. --=20 *geoffroy desvernay* C.R.I - Administration syst=E8mes et r=E9seaux Ecole Centrale de Marseille Tel: (+33|0)4 91 05 45 24 Fax: (+33|0)4 91 05 44 26 --7R4RdFmdo9fawDOMBiwFDkO3d5GE32Mof Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVCY1BAAoJED/P9AlFh6DwGs4QAJnV7xusxXWol0Axq8i0CUXi xjF9pSp6eHi5u2SEklrui7UKpBYdIketoxeJ5AEmUlbwhPQPX1lWjM8v+kU25unT 4DIifFM+IkPK4C98W2k6CLuVyrO0oYaApYPTOl7vOe0LnnIUal30XXzU3WdO6OeW Q9tCrfx3roBx6o6Lb6FhZuIylvyg99Q0Z0B11DaMYLVUWbkebvdcGKtViJ9w2xdX 75uzOBBDGFcZqEkmFj/E08YmHJMH7lEktLOEqAE2B8DojaleKUbzof7cI6WXrY5h kX+i+oKTHFlk+COqVvSOwUo754Xmh9T+vF3GyTqHjNYfSByG/Jk5KD3rZh5QQfD2 ke71/m7L0mNbKAwMVQDVG6KHXr6obg+2Kp0xcC3t4tn877P5d3TXllRx3+lGsnzP X++ikJfHAOO93qwwZjSUxJ3KDs3nvmKfASpGifEoUvIkemgmmsQMLxOdMXHa6BVQ qaZW8vyv85IgI/LPKNQT8kRJv85TAkt0AM6N1lR034S5pgp9tKW8tcFAaKgb+aE1 0YfGBm9aJtWpc2i/EOfOoJJLLSbrhddiqHVv3JAzE02IFgqlp2/F+VZ+TbiioSQi XPzegnzoJM5WTrmb+k66NAx2nIQAcW9bY+vwfa0naQ3RdRidkN/iDw67iia0AzTi LBt3KUUj1jrVQBi4IzTU =Pjw+ -----END PGP SIGNATURE----- --7R4RdFmdo9fawDOMBiwFDkO3d5GE32Mof-- From owner-freebsd-ports@FreeBSD.ORG Wed Mar 18 21:39:09 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D729F3E for ; Wed, 18 Mar 2015 21:39:09 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D9D4FEB4 for ; Wed, 18 Mar 2015 21:39:07 +0000 (UTC) Received: (qmail 31813 invoked from network); 18 Mar 2015 21:39:01 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 18 Mar 2015 21:39:01 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Wed, 18 Mar 2015 17:39:01 -0400 (EDT) Received: (qmail 26815 invoked from network); 18 Mar 2015 21:39:01 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Mar 2015 21:39:01 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 12A131C4052; Wed, 18 Mar 2015 14:38:56 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc64 11.0-CURRENT: CROSS_TOOLCHAIN=powerpc64-gcc rejects -m elf32ppc_fbsd for linking boot1.elf Date: Wed, 18 Mar 2015 14:38:58 -0700 Message-Id: <122C9C88-24F9-4FA7-BCAC-293ED0DB946A@dsl-only.net> To: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-ports@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 21:39:09 -0000 Basic context (more details given later): > # freebsd-version -ku; uname -apKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed = Mar 11 19:23:14 PDT 2015 = root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBU= G powerpc powerpc64 1100062 1100062 No clang is built or installed. The problem: > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc WITHOUT_CLANG_BOOTSTRAP=3D = WITHOUT_CLANG_IS_CC=3D WITHOUT_CLANG=3D WITHOUT_CLANG_EXTRAS=3D = WITHOUT_CLANG_FULL=3D WITHOUT_LLDB=3D WITHOUT_GCC_BOOTSTRAP=3D = WITHOUT_GCC=3D buildworld buildkernel KERNCONF=3DGENERIC64vtsc-NODEBUG = TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 processes up to: > /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -ffreestanding = -msoft-float -Os -I/usr/srcC/sys/boot/powerpc/boot1.chrp/../../common = -I/usr/srcC/sys/boot/powerpc/boot1.chrp/../../../ -D_STANDALONE=20 > -m32 -mcpu=3Dpowerpc -m32 -mcpu=3Dpowerpc -std=3Dgnu99 -nostdlib = -static -Wl,-N -m elf32ppc_fbsd -m elf32ppc_fbsd -o boot1.elf boot1.o = ashldi3.o syncicache.o -L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ and then gets for the above command... > powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such file = or directory > powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such file = or directory > powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' > powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >=20 > *** [boot1.elf] Error code 1 >=20 > make[6]: stopped in /usr/srcC/sys/boot/powerpc/boot1.chrp > 1 error The -m options seems to be from the likes of... > # $FreeBSD: head/sys/boot/powerpc/Makefile.inc 227739 2011-11-19 = 19:25:57Z andreast $ >=20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > LDFLAGS+=3D -m elf32ppc_fbsd > .endif >=20 > .include "../Makefile.inc" and (extracted from using find ... -print): > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/srcC/sys/boot/ofw/Makefile.inc > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/srcC/sys/boot/uboot/Makefile.inc > LD=3D"${LD} -m elf32ppc_fbsd" > /usr/srcC/Makefile.inc1 When I looked at "man gcc" I did not find any "-m text" options = or any -melf32ppc_fbsd option. It would suggest that "-m elf32ppc_fbsd" = is not normally valid --matching the complaints by = powerpc64-portbld-freebsd11.0-gcc. Is there a FreeBSD-specific addition to gcc missing in powerpc64-gcc? Context details: WITHOUT_CLANG=3D (bootstrap too) is important to getting this far in my = context. (It was in the make command shown earlier.) # more /etc/src.conf CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ X_COMPILER_TYPE=3Dgcc CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 LDADD+=3D-L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ NO_WERROR=3D The CC=3D, CXX=3D, CPP=3D assignments matching the XCC, XCXX, and XCPP = assignments for CROSS_TOOLCHAIN=3Dpowerpc64-gcc are important to getting = this far: otherwise gcc 4.2.1 is used for some things. I also listed = CROSS_BINUTILS_PREFIX and X_COMPILER_TYPE when I added the assignments. = I do not know if they are needed. libc++ include and library path handling did not automatically work so I = added the explicit CXXFLAGS+=3D and LDADD+=3D. If there had been a CXX = specific LDADDCXX I would have used it instead. NO_WERROR=3D is for avoiding stopping for the warnings: I'm not trying = to clean up the status relative to compiler warnings. # svnlite info /usr/srcC/ Path: /usr/srcC Working Copy Root Path: /usr/srcC URL: https://svn0.us-west.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279514 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 279514 Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) # svnlite status /usr/srcC/ --no-ignore ? /usr/srcC/.snap M /usr/srcC/Makefile M /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h ? /usr/srcC/restoresymtable M /usr/srcC/sys/ddb/db_main.c M /usr/srcC/sys/ddb/db_script.c ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc-NODEBUG ? /usr/srcC/sys/powerpc/conf/GENERICvtsc ? /usr/srcC/sys/powerpc/conf/GENERICvtsc-NODEBUG M /usr/srcC/sys/powerpc/ofw/ofw_machdep.c M /usr/srcC/sys/powerpc/ofw/ofwcall64.S IntrusiveRefCntPtr.h needed an internal friend status established across = typename parameters in order to compile. I have a PowerMac G5 specific change to make booting reliable and some = changes for getting information from early boot failures in case I get = any more of them. I build without ps3 in order to allow having both vt = and sc in the build. # ls -FPal /usr/local/include/iconv* -rw-r--r-- 1 root wheel 9348 Mar 12 02:47 = /usr/local/include/iconv.h_alt powerpc64-gcc automatically finds files in /usr/local/include/ such that = they can be used when others with different content but the same name = are appropriate. I renamed /usr/local/include/iconv.h to avoid it being = an example of that. I will not list how I got powerpc64-xtoolchain-gcc (and so = powerpc64-gcc) to finish installing on a powerpc64 11.0-CURRENT. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ports@FreeBSD.ORG Thu Mar 19 00:40:59 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3A3F6F3 for ; Thu, 19 Mar 2015 00:40:59 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5514E6CE for ; Thu, 19 Mar 2015 00:40:59 +0000 (UTC) Received: from [192.168.0.113] ([112.198.64.48]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MIe0O-1YWBax1V2O-002JjA for ; Thu, 19 Mar 2015 01:40:56 +0100 Message-ID: <550A1AF4.9000201@gmx.net> Date: Thu, 19 Mar 2015 08:40:20 +0800 From: Simon Wright User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: ports@freebsd.org Subject: Security patch for Drupal 6/7 needed Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:sXsIxF0zDACKDiHHFT1oMvHEV5wjP4jPuk4dOC+J1hzGP1TiyFO RnX36v8Pyn2Z4M1VF/Q49we7qlzzrOdXoZkJGXUK15H3x9dezqEqMVB1nCCNxZpMQKWVlxJ 9u5EvJq2ePcmHVQwzpK787zkF+KtTUlMBBo5xljeJ2xyGDDxwVNoRD5JnJC656XVURRhOMy JJ3kQE/hMYlD/MDV5jt7A== X-UI-Out-Filterresults: notjunk:1; X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 00:40:59 -0000 Hi all I am the maintainer of Drupal 6 & 7. Upstrem have just released a moderately critical security update but I am travelling with no access to my systems. If someone can quickly write and test a patch I will approve it. There are a couple of points listed on the release notes but nothing major. Thanks Simon. From owner-freebsd-ports@FreeBSD.ORG Thu Mar 19 02:40:39 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68DC7C66 for ; Thu, 19 Mar 2015 02:40:39 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1F162348 for ; Thu, 19 Mar 2015 02:40:38 +0000 (UTC) Received: (qmail 32179 invoked from network); 19 Mar 2015 02:40:37 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 19 Mar 2015 02:40:37 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Wed, 18 Mar 2015 22:40:37 -0400 (EDT) Received: (qmail 588 invoked from network); 19 Mar 2015 02:40:37 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Mar 2015 02:40:37 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 949211C43A6; Wed, 18 Mar 2015 19:40:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 11.0-CURRENT: CROSS_TOOLCHAIN=powerpc64-gcc rejects -m elf32ppc_fbsd for linking boot1.elf From: Mark Millard In-Reply-To: <122C9C88-24F9-4FA7-BCAC-293ED0DB946A@dsl-only.net> Date: Wed, 18 Mar 2015 19:40:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <62E9089D-AF22-49F2-A20B-8719C1922EC7@dsl-only.net> References: <122C9C88-24F9-4FA7-BCAC-293ED0DB946A@dsl-only.net> To: freebsd-toolchain@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-ports@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 02:40:39 -0000 It looks to me like the space between -m and elf32ppc_fbsd in "-m = elf32ppc_fbsd" is likely not allowed for powerpc64-gcc (gcc 4.9.1): (shown ignoring binary file matches) > # pwd > /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work > # find . -type f -exec grep elf32ppc_fbsd {} \; -print | more > #define LINK_OS_FREEBSD_SPEC32 "-melf32ppc_fbsd " = LINK_OS_FREEBSD_SPEC_DEF32 > ./gcc-4.9.1/gcc/config/rs6000/freebsd64.h > -melf32ppc_fbsd %{p:%nconsider using `-pg' instead of `-p' with = gprof(1)} %{v:-V} %{assert*} %{R*} %{rpath*} %{defsym*} = %{shared:-Bshareable %{h*} %{soname*}} %{!shared: %{!static: = %{rdynamic: -export-dynamic} %{!dynamic-linker:-dynamic-linker = /libexec/ld-elf32.so.1}} %{static:-Bstatic}} = %{symbolic:-Bsymbolic} > ./build-gcc/gcc/specs > #define LINK_OS_FREEBSD_SPEC32 "-melf32ppc_fbsd " = LINK_OS_FREEBSD_SPEC_DEF32 > = ./stage/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/plugin/inclu= de/config/rs6000/freebsd64.h This might explain the elf32gcc_fbsd file missing notices that I = reported before. However when I removed the spaces from the Makefile.inc*'s that use "-m = elf..." (see later) powerpc64-gcc produced: > /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -ffreestanding = -msoft-float -Os -I/usr/srcC/sys/boot/powerpc/boot1.chrp/../../common = -I/usr/srcC/sys/boot/powerpc/boot1.chrp/../../../ -D_STANDALONE=20 > -m32 -mcpu=3Dpowerpc -m32 -mcpu=3Dpowerpc -std=3Dgnu99 -nostdlib = -static -Wl,-N -melf32ppc_fbsd -melf32ppc_fbsd -o boot1.elf boot1.o = ashldi3.o syncicache.o -L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ > powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-melf32ppc_fbsd' > powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-melf32ppc_fbsd' It looks like elf32ppc_fbsd mode usage with such -m notation is = disallowed in powerpc64-gcc. [I tried a few experimental, manual gcc5 command lines and got the same = results there. So it may not be just powerpc64-gcc.] Being disallowed overall would imply that WITH_GCC_BOOTSTRAP=3D (4.2.1 = or some alternative) is required for such use and = /usr/srcC/Makefile.inc1 would need to make use of the alternative that = allows elf32ppc_fbsd where it is used. So for my purposes WITHOUT_LIB32=3D WITHOUT_BOOT=3D relative to seeing what can be done with powerpc64-xtoolchain-gcc: I'm = not checking if there is a different way to do an equivalent of = -melf32ppc_fbsd. The -m elf...'s that I tried changing were as below. I only tried = elf32ppc_fbsd contexts. > # svnlite diff /usr/srcC/Makefile.inc1 /usr/srcC/sys/boot | more > Index: /usr/srcC/Makefile.inc1 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/srcC/Makefile.inc1 (revision 279514) > +++ /usr/srcC/Makefile.inc1 (working copy) > @@ -396,7 +396,7 @@ > MACHINE_CPU=3D"i686 mmx sse sse2" > LIB32WMAKEFLAGS=3D \ > AS=3D"${AS} --32" \ > - LD=3D"${LD} -m elf_i386_fbsd -Y = P,${LIB32TMP}/usr/lib32" > + LD=3D"${LD} -melf_i386_fbsd -Y = P,${LIB32TMP}/usr/lib32" > =20 > .elif ${TARGET_ARCH} =3D=3D "powerpc64" > .if empty(TARGET_CPUTYPE) > @@ -406,7 +406,7 @@ > .endif > LIB32WMAKEENV=3D MACHINE=3Dpowerpc MACHINE_ARCH=3Dpowerpc > LIB32WMAKEFLAGS=3D \ > - LD=3D"${LD} -m elf32ppc_fbsd" > + LD=3D"${LD} -melf32ppc_fbsd" > .endif > =20 > =20 > Index: /usr/srcC/sys/boot/i386/Makefile.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/srcC/sys/boot/i386/Makefile.inc (revision 279514) > +++ /usr/srcC/sys/boot/i386/Makefile.inc (working copy) > @@ -14,7 +14,7 @@ > CFLAGS+=3D -m32 > ACFLAGS+=3D -m32 > # LD_FLAGS is passed directly to ${LD}, not via ${CC}: > -LD_FLAGS+=3D -m elf_i386_fbsd > +LD_FLAGS+=3D -melf_i386_fbsd > AFLAGS+=3D --32 > .endif > =20 > Index: /usr/srcC/sys/boot/ofw/Makefile.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/srcC/sys/boot/ofw/Makefile.inc (revision 279514) > +++ /usr/srcC/sys/boot/ofw/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ > =20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -melf32ppc_fbsd > .endif > =20 > .include "../Makefile.inc" > Index: /usr/srcC/sys/boot/powerpc/Makefile.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/srcC/sys/boot/powerpc/Makefile.inc (revision 279514) > +++ /usr/srcC/sys/boot/powerpc/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ > =20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -melf32ppc_fbsd > .endif > =20 > .include "../Makefile.inc" > Index: /usr/srcC/sys/boot/uboot/Makefile.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/srcC/sys/boot/uboot/Makefile.inc (revision 279514) > +++ /usr/srcC/sys/boot/uboot/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ > =20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -melf32ppc_fbsd > .endif > =20 > .include "../Makefile.inc" =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-18, at 02:38 PM, Mark Millard = wrote: Basic context (more details given later): > # freebsd-version -ku; uname -apKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed = Mar 11 19:23:14 PDT 2015 = root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBU= G powerpc powerpc64 1100062 1100062 No clang is built or installed. The problem: > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc WITHOUT_CLANG_BOOTSTRAP=3D = WITHOUT_CLANG_IS_CC=3D WITHOUT_CLANG=3D WITHOUT_CLANG_EXTRAS=3D = WITHOUT_CLANG_FULL=3D WITHOUT_LLDB=3D WITHOUT_GCC_BOOTSTRAP=3D = WITHOUT_GCC=3D buildworld buildkernel KERNCONF=3DGENERIC64vtsc-NODEBUG = TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 processes up to: > /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -ffreestanding = -msoft-float -Os -I/usr/srcC/sys/boot/powerpc/boot1.chrp/../../common = -I/usr/srcC/sys/boot/powerpc/boot1.chrp/../../../ -D_STANDALONE=20 > -m32 -mcpu=3Dpowerpc -m32 -mcpu=3Dpowerpc -std=3Dgnu99 -nostdlib = -static -Wl,-N -m elf32ppc_fbsd -m elf32ppc_fbsd -o boot1.elf boot1.o = ashldi3.o syncicache.o -L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ and then gets for the above command... > powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such file = or directory > powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such file = or directory > powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' > powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >=20 > *** [boot1.elf] Error code 1 >=20 > make[6]: stopped in /usr/srcC/sys/boot/powerpc/boot1.chrp > 1 error The -m options seems to be from the likes of... > # $FreeBSD: head/sys/boot/powerpc/Makefile.inc 227739 2011-11-19 = 19:25:57Z andreast $ >=20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > LDFLAGS+=3D -m elf32ppc_fbsd > .endif >=20 > .include "../Makefile.inc" and (extracted from using find ... -print): > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/srcC/sys/boot/ofw/Makefile.inc > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/srcC/sys/boot/uboot/Makefile.inc > LD=3D"${LD} -m elf32ppc_fbsd" > /usr/srcC/Makefile.inc1 When I looked at "man gcc" I did not find any "-m text" options = or any -melf32ppc_fbsd option. It would suggest that "-m elf32ppc_fbsd" = is not normally valid --matching the complaints by = powerpc64-portbld-freebsd11.0-gcc. Is there a FreeBSD-specific addition to gcc missing in powerpc64-gcc? Context details: WITHOUT_CLANG=3D (bootstrap too) is important to getting this far in my = context. (It was in the make command shown earlier.) # more /etc/src.conf CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ X_COMPILER_TYPE=3Dgcc CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 LDADD+=3D-L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ NO_WERROR=3D The CC=3D, CXX=3D, CPP=3D assignments matching the XCC, XCXX, and XCPP = assignments for CROSS_TOOLCHAIN=3Dpowerpc64-gcc are important to getting = this far: otherwise gcc 4.2.1 is used for some things. I also listed = CROSS_BINUTILS_PREFIX and X_COMPILER_TYPE when I added the assignments. = I do not know if they are needed. libc++ include and library path handling did not automatically work so I = added the explicit CXXFLAGS+=3D and LDADD+=3D. If there had been a CXX = specific LDADDCXX I would have used it instead. NO_WERROR=3D is for avoiding stopping for the warnings: I'm not trying = to clean up the status relative to compiler warnings. # svnlite info /usr/srcC/ Path: /usr/srcC Working Copy Root Path: /usr/srcC URL: https://svn0.us-west.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279514 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 279514 Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) # svnlite status /usr/srcC/ --no-ignore ? /usr/srcC/.snap M /usr/srcC/Makefile M /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h ? /usr/srcC/restoresymtable M /usr/srcC/sys/ddb/db_main.c M /usr/srcC/sys/ddb/db_script.c ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc-NODEBUG ? /usr/srcC/sys/powerpc/conf/GENERICvtsc ? /usr/srcC/sys/powerpc/conf/GENERICvtsc-NODEBUG M /usr/srcC/sys/powerpc/ofw/ofw_machdep.c M /usr/srcC/sys/powerpc/ofw/ofwcall64.S IntrusiveRefCntPtr.h needed an internal friend status established across = typename parameters in order to compile. I have a PowerMac G5 specific change to make booting reliable and some = changes for getting information from early boot failures in case I get = any more of them. I build without ps3 in order to allow having both vt = and sc in the build. # ls -FPal /usr/local/include/iconv* -rw-r--r-- 1 root wheel 9348 Mar 12 02:47 = /usr/local/include/iconv.h_alt powerpc64-gcc automatically finds files in /usr/local/include/ such that = they can be used when others with different content but the same name = are appropriate. I renamed /usr/local/include/iconv.h to avoid it being = an example of that. I will not list how I got powerpc64-xtoolchain-gcc (and so = powerpc64-gcc) to finish installing on a powerpc64 11.0-CURRENT. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ports@FreeBSD.ORG Thu Mar 19 04:29:03 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62FC9B44 for ; Thu, 19 Mar 2015 04:29:03 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1BBA3FDD for ; Thu, 19 Mar 2015 04:29:02 +0000 (UTC) Received: (qmail 6267 invoked from network); 19 Mar 2015 04:29:01 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 19 Mar 2015 04:29:01 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Thu, 19 Mar 2015 00:29:01 -0400 (EDT) Received: (qmail 25187 invoked from network); 19 Mar 2015 04:29:00 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Mar 2015 04:29:00 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id BBB011C439E; Wed, 18 Mar 2015 21:28:53 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: On using powerpc64-xtoolchain-gcc for buildworld buildkernel on a powerpc64 11.0-CURRENT -r279514 variant Date: Wed, 18 Mar 2015 21:28:58 -0700 Message-Id: <4B4B5E10-43B5-4993-AE45-E23CBC22030B@dsl-only.net> To: FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 04:29:03 -0000 Basic starting context: > # freebsd-version -ku; uname -apKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed = Mar 11 19:23:14 PDT 2015 = root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBU= G powerpc powerpc64 1100062 1100062 No clang present to start with: I did delete-old at the end of the = 10.1-STABLE -> 11.0-CURRENT upgrade before realizing I'd end up with no = clang at all and no direct way to build it. No initial clang means no initial C++11 library either. (Beyond gcc = 4.2.1's range of coverage.) I have a PowerMac G5 specific change to make booting reliable and some = changes for getting information from early boot failures in case I get = any more of them. So it is not a strict -r279514 build. So for CROSS_TOOLCHAIN=3Dpowerpc64-gcc how much was I able to include in = buildworld buildkernel (I've not tried including gcc yet)? Well doing... > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ > WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ > WITHOUT_LLDB=3D \ > WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 using the context... > # more /etc/src.conf > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 > LDADD+=3D-L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ > NO_WERROR=3D completed buildworld buildkernel. I have not tried installkernel nor installworld yet. WITH_BOOT=3D and = WITH_LIB32=3D materials would be missing or come from other types of = builds that I've done. Unfortunately there is more to getting the above to work then just the = above. Also the below includes notes about why various things are as = they are above. Various oddities need to be avoided/sidestepped for = CROSS_TOOLCHAIN=3Dpowerpc64-gcc use... The first oddity is that on a powerpc64 11.0-CURRENT = powerpc64-xtoolchain-gcc fails to complete its installation because = powerpc64-gcc fails to complete its installation. The powerpc64-gcc = installation problems do not happen on powerpc (non-64) 11.0-CURRENT but = do happen on powerpc64, suggesting TARGET !=3D TARGET_ARCH handling = issues for the port. The problems were 4 mismatched file names and one = file also not put into staging. I copied appropriate files to the = missing names and place and from that status the installation was able = to continue and complete. buildworld attempts to use clang's then-non-existent table generation = programs if WITH_CLANG=3D was used: So I used... WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_LLDB=3D "-m elf32pcc_fbsd" and -melf32pcc_fbsd were not supported on the command = line for powerpc64-gcc: I did not try to change things so that gcc 4.2.1 = would be used just for WITH_LIB32=3D and WITH_BOOT=3D. I was just trying = to figure what and how I can use powerpc64-xtools --and where I can not = currently do so. So I used... WITHOUT_BOOT=3D WITHOUT_LIB32=3D powerpc64-gcc automatically looks in /usr/local/include for header files = (like most such ports) and this can pick up the wrong file(s). I ended = up renaming /usr/local/include/iconv.h so that it would not be found and used where a file with different = content from my /usr/srcC/... was needed. I needed to have head's lib/libnv/test/dnv_tests.cc and = lib/libnv/test/nv_tests.cc from -r279760 or later in order to remove = ambiguous overload issues. > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ > WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ > WITHOUT_LLDB=3D \ > WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 When CROSS_TOOLCHAIN=3D..., XCC=3D..., XCXX=3D..., XCPP=3D... are in use = various build stages do not use those but instead use the original = CC=3D..., CXX=3D..., CPP=3D... (legacy, bootstrap-tools, build-tools, = cross-tools, kernel-tools, lib32's build-tools). So I used /etc/src.conf = to force those last 3 assignments to globally be the same as the X... = assignments that CROSS_TOOLCHAIN=3Dpowerpc64-gcc uses: > # more /etc/src.conf > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 > LDADD+=3D-L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ > NO_WERROR=3D and I listed the other two assignments that = CROSS_TOOLCHAIN=3Dpowerpc64-gcc picks up. (I do not know that it was = necessary to do so.) Looking up the libc++ headers and library did not work automatically so = I added the CXXFLAGS+=3D... and LDADD+=3D... into /etc/src.conf as = indicated above. If there had been a LDADDCXX available I would have = used it instead of LDADD. NO_WERROR=3D was used to avoid stopping at various warnings. I choose to use: WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D but there was no specific problem that prompted me to do that. I do not = yet know how well it would work if gcc was built. Other points learned in the process... As noted above "-m elf32ppc_fbsd" was not allowed by powerpc64-gcc (gcc = 4.9.1): it may not allow the space for -m in general. So I tied the = below but they were also rejected (in a different way)... (I only used = elf32ppc_fbsd contexts.) > # svnlite diff /usr/srcC/Makefile.inc1 /usr/srcC/sys/boot | more > Index: /usr/srcC/Makefile.inc1 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/srcC/Makefile.inc1 (revision 279514) > +++ /usr/srcC/Makefile.inc1 (working copy) > @@ -396,7 +396,7 @@ > MACHINE_CPU=3D"i686 mmx sse sse2" > LIB32WMAKEFLAGS=3D \ > AS=3D"${AS} --32" \ > - LD=3D"${LD} -m elf_i386_fbsd -Y = P,${LIB32TMP}/usr/lib32" > + LD=3D"${LD} -melf_i386_fbsd -Y = P,${LIB32TMP}/usr/lib32" > =20 > .elif ${TARGET_ARCH} =3D=3D "powerpc64" > .if empty(TARGET_CPUTYPE) > @@ -406,7 +406,7 @@ > .endif > LIB32WMAKEENV=3D MACHINE=3Dpowerpc MACHINE_ARCH=3Dpowerpc > LIB32WMAKEFLAGS=3D \ > - LD=3D"${LD} -m elf32ppc_fbsd" > + LD=3D"${LD} -melf32ppc_fbsd" > .endif > =20 > =20 > Index: /usr/srcC/sys/boot/i386/Makefile.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/srcC/sys/boot/i386/Makefile.inc (revision 279514) > +++ /usr/srcC/sys/boot/i386/Makefile.inc (working copy) > @@ -14,7 +14,7 @@ > CFLAGS+=3D -m32 > ACFLAGS+=3D -m32 > # LD_FLAGS is passed directly to ${LD}, not via ${CC}: > -LD_FLAGS+=3D -m elf_i386_fbsd > +LD_FLAGS+=3D -melf_i386_fbsd > AFLAGS+=3D --32 > .endif > =20 > Index: /usr/srcC/sys/boot/ofw/Makefile.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/srcC/sys/boot/ofw/Makefile.inc (revision 279514) > +++ /usr/srcC/sys/boot/ofw/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ > =20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -melf32ppc_fbsd > .endif > =20 > .include "../Makefile.inc" > Index: /usr/srcC/sys/boot/powerpc/Makefile.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/srcC/sys/boot/powerpc/Makefile.inc (revision 279514) > +++ /usr/srcC/sys/boot/powerpc/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ > =20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -melf32ppc_fbsd > .endif > =20 > .include "../Makefile.inc" > Index: /usr/srcC/sys/boot/uboot/Makefile.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/srcC/sys/boot/uboot/Makefile.inc (revision 279514) > +++ /usr/srcC/sys/boot/uboot/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ > =20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -melf32ppc_fbsd > .endif > =20 > .include "../Makefile.inc" I did experiment with compiles of clang some and one thing that I = discovered was: The following file needed to be updated to be language compliant: > # svnlite diff = /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h > Index: /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h = (revision 279514) > +++ /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h = (working copy) > @@ -155,7 +155,7 @@ > =20 > template > IntrusiveRefCntPtr(IntrusiveRefCntPtr&& S) : Obj(S.get()) { > - S.Obj =3D 0; > + S.Obj =3D 0; /* access to private member needs friendship */ > } > =20 > template > @@ -197,6 +197,10 @@ > private: > void retain() { if (Obj) IntrusiveRefCntPtrInfo::retain(Obj); = } > void release() { if (Obj) = IntrusiveRefCntPtrInfo::release(Obj); } > + > +/* FIX for Obj private access issue */ > + template > + friend class IntrusiveRefCntPtr; > }; > =20 > template Upstream llvm has this sort of change already, not with the comments. Other context details: My list of what files are different than svn is: # svnlite status /usr/srcC/ --no-ignore ? /usr/srcC/.snap M /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h ? /usr/srcC/restoresymtable M /usr/srcC/sys/ddb/db_main.c M /usr/srcC/sys/ddb/db_script.c ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc-NODEBUG ? /usr/srcC/sys/powerpc/conf/GENERICvtsc ? /usr/srcC/sys/powerpc/conf/GENERICvtsc-NODEBUG M /usr/srcC/sys/powerpc/ofw/ofw_machdep.c M /usr/srcC/sys/powerpc/ofw/ofwcall64.S But IntrusiveRefCntPtr.h does not matter if clang building is not = involved. And the rest existed in my environment before I started this = powerpc64-xtoolchain-gcc exploration. lib/libnv/test/dnv_tests.cc and lib/libnv/test/nv_tests.cc are from = later than the rest of the unmodified source code, teh rest being = from... # svnlite info /usr/srcC/ Path: . Working Copy Root Path: /usr/srcC URL: https://svn0.us-west.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279514 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 279514 Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) # more /etc/make.conf #CPP=3D/usr/local/bin/clang-cpp36 #CC=3D/usr/local/bin/clang36 #CXX=3D/usr/local/bin/clang++36 WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ports@FreeBSD.ORG Thu Mar 19 07:27:48 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52C25F33 for ; Thu, 19 Mar 2015 07:27:48 +0000 (UTC) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1734221C for ; Thu, 19 Mar 2015 07:27:48 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YYUrq-000BzC-0F; Thu, 19 Mar 2015 08:27:46 +0100 Date: Thu, 19 Mar 2015 08:27:45 +0100 From: Kurt Jaeger To: Simon Wright Subject: Re: Security patch for Drupal 6/7 needed Message-ID: <20150319072745.GW62590@home.opsec.eu> References: <550A1AF4.9000201@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <550A1AF4.9000201@gmx.net> Cc: ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 07:27:48 -0000 Hi! > I am the maintainer of Drupal 6 & 7. Upstrem have just released a > moderately critical security update but I am travelling with no access > to my systems. If someone can quickly write and test a patch I will > approve it. > > There are a couple of points listed on the release notes but nothing major. Update done (version and distinfo was all it needed). -- pi@opsec.eu +49 171 3101372 5 years to go ! From owner-freebsd-ports@FreeBSD.ORG Thu Mar 19 09:26:40 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C09FA3 for ; Thu, 19 Mar 2015 09:26:40 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E574319B for ; Thu, 19 Mar 2015 09:26:39 +0000 (UTC) Received: (qmail 25210 invoked from network); 19 Mar 2015 09:26:38 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 19 Mar 2015 09:26:38 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Thu, 19 Mar 2015 05:26:38 -0400 (EDT) Received: (qmail 26741 invoked from network); 19 Mar 2015 09:26:38 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Mar 2015 09:26:38 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 591111C43A6; Thu, 19 Mar 2015 02:26:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: On using powerpc64-xtoolchain-gcc for buildworld buildkernel on a powerpc64 11.0-CURRENT -r279514 variant From: Mark Millard In-Reply-To: <4B4B5E10-43B5-4993-AE45-E23CBC22030B@dsl-only.net> Date: Thu, 19 Mar 2015 02:26:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0273C21A-C8BD-4D67-9A2B-E4C9938148AF@dsl-only.net> References: <4B4B5E10-43B5-4993-AE45-E23CBC22030B@dsl-only.net> To: FreeBSD PowerPC ML X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 09:26:40 -0000 After the previously described buildworld/buildkernel sequence: installkernel then shutdown -r now and so-far-so-good after the reboot installworld then shutdown -r now and so-far-so-good after the reboot delete-old and delete-libs then shutdown -r now and still good after the = reboot $ dmesg -a | head ... FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 18 20:11:15 PDT 2015 root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc gcc version 4.9.1 (FreeBSD Ports Collection for powerpc64)=20 ... Of course this is in part based on prior boot1.elf establishment on the = media (WITHOUT_BOOT=3D) and it lacks lib32 (WITHOUT_LIB32=3D) --at least = once I had delete-old and delete-old-libs delete things. (The delete-old and delete-old-libs may have made doing another = buildworld buildkernel a mess since I did not set up for keeping gcc = 4.2.1 related things as active generally. libstdc++ is gone, for = example. I'm not sure legacy will build without libstdc++ and libstdc++ = may well not be automatically regenerated. But I wanted to check on the = lack of old context still being okay for booting and basic operation. I = can always go back and duplicate my paranoia-copy from just before = installkernel.) Also I forgot to mention in the oddities section: establishing libcxxrt = and libc++... I needed to get libcxxrt and libc++ in place before buildworld = buildkernel but after powerpc64-xtoolchain-gcc was installed, using a = context something like... > # more /etc/src.conf > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > #CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 > #LDADD+=3D-L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ > NO_WERROR=3D If I remember right a summary would be... cd /usr/srcC/lib/libcxxrt/; make; make install cd /usr/srcC/lib/libc++/; make; make install in that order. These are what established some context for using > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 > LDADD+=3D-L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ in /etc/src.conf during buildworld/buildkernel, unless I misremembering = something. Now that the rebuilds are installed and running the appropriate paths = are different: > CXXFLAGS+=3D-I/usr/include/c++/v1 > LDADD+=3D-L/usr/lib -lc++ =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-18, at 09:28 PM, Mark Millard = wrote: Basic starting context: > # freebsd-version -ku; uname -apKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed = Mar 11 19:23:14 PDT 2015 = root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBU= G powerpc powerpc64 1100062 1100062 No clang present to start with: I did delete-old at the end of the = 10.1-STABLE -> 11.0-CURRENT upgrade before realizing I'd end up with no = clang at all and no direct way to build it. No initial clang means no initial C++11 library either. (Beyond gcc = 4.2.1's range of coverage.) I have a PowerMac G5 specific change to make booting reliable and some = changes for getting information from early boot failures in case I get = any more of them. So it is not a strict -r279514 build. So for CROSS_TOOLCHAIN=3Dpowerpc64-gcc how much was I able to include in = buildworld buildkernel (I've not tried including gcc yet)? Well doing... > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ > WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ > WITHOUT_LLDB=3D \ > WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 using the context... > # more /etc/src.conf > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 > LDADD+=3D-L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ > NO_WERROR=3D completed buildworld buildkernel. I have not tried installkernel nor installworld yet. WITH_BOOT=3D and = WITH_LIB32=3D materials would be missing or come from other types of = builds that I've done. Unfortunately there is more to getting the above to work then just the = above. Also the below includes notes about why various things are as = they are above. Various oddities need to be avoided/sidestepped for = CROSS_TOOLCHAIN=3Dpowerpc64-gcc use... The first oddity is that on a powerpc64 11.0-CURRENT = powerpc64-xtoolchain-gcc fails to complete its installation because = powerpc64-gcc fails to complete its installation. The powerpc64-gcc = installation problems do not happen on powerpc (non-64) 11.0-CURRENT but = do happen on powerpc64, suggesting TARGET !=3D TARGET_ARCH handling = issues for the port. The problems were 4 mismatched file names and one = file also not put into staging. I copied appropriate files to the = missing names and place and from that status the installation was able = to continue and complete. buildworld attempts to use clang's then-non-existent table generation = programs if WITH_CLANG=3D was used: So I used... WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_LLDB=3D "-m elf32pcc_fbsd" and -melf32pcc_fbsd were not supported on the command = line for powerpc64-gcc: I did not try to change things so that gcc 4.2.1 = would be used just for WITH_LIB32=3D and WITH_BOOT=3D. I was just trying = to figure what and how I can use powerpc64-xtools --and where I can not = currently do so. So I used... WITHOUT_BOOT=3D WITHOUT_LIB32=3D powerpc64-gcc automatically looks in /usr/local/include for header files = (like most such ports) and this can pick up the wrong file(s). I ended = up renaming /usr/local/include/iconv.h so that it would not be found and used where a file with different = content from my /usr/srcC/... was needed. I needed to have head's lib/libnv/test/dnv_tests.cc and = lib/libnv/test/nv_tests.cc from -r279760 or later in order to remove = ambiguous overload issues. > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ > WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ > WITHOUT_LLDB=3D \ > WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 When CROSS_TOOLCHAIN=3D..., XCC=3D..., XCXX=3D..., XCPP=3D... are in use = various build stages do not use those but instead use the original = CC=3D..., CXX=3D..., CPP=3D... (legacy, bootstrap-tools, build-tools, = cross-tools, kernel-tools, lib32's build-tools). So I used /etc/src.conf = to force those last 3 assignments to globally be the same as the X... = assignments that CROSS_TOOLCHAIN=3Dpowerpc64-gcc uses: > # more /etc/src.conf > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 > LDADD+=3D-L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ > NO_WERROR=3D and I listed the other two assignments that = CROSS_TOOLCHAIN=3Dpowerpc64-gcc picks up. (I do not know that it was = necessary to do so.) Looking up the libc++ headers and library did not work automatically so = I added the CXXFLAGS+=3D... and LDADD+=3D... into /etc/src.conf as = indicated above. If there had been a LDADDCXX available I would have = used it instead of LDADD. NO_WERROR=3D was used to avoid stopping at various warnings. I choose to use: WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D but there was no specific problem that prompted me to do that. I do not = yet know how well it would work if gcc was built. Other points learned in the process... As noted above "-m elf32ppc_fbsd" was not allowed by powerpc64-gcc (gcc = 4.9.1): it may not allow the space for -m in general. So I tied the = below but they were also rejected (in a different way)... (I only used = elf32ppc_fbsd contexts.) > # svnlite diff /usr/srcC/Makefile.inc1 /usr/srcC/sys/boot | more > Index: /usr/srcC/Makefile.inc1 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/srcC/Makefile.inc1 (revision 279514) > +++ /usr/srcC/Makefile.inc1 (working copy) > @@ -396,7 +396,7 @@ > MACHINE_CPU=3D"i686 mmx sse sse2" > LIB32WMAKEFLAGS=3D \ > AS=3D"${AS} --32" \ > - LD=3D"${LD} -m elf_i386_fbsd -Y = P,${LIB32TMP}/usr/lib32" > + LD=3D"${LD} -melf_i386_fbsd -Y = P,${LIB32TMP}/usr/lib32" >=20 > .elif ${TARGET_ARCH} =3D=3D "powerpc64" > .if empty(TARGET_CPUTYPE) > @@ -406,7 +406,7 @@ > .endif > LIB32WMAKEENV=3D MACHINE=3Dpowerpc MACHINE_ARCH=3Dpowerpc > LIB32WMAKEFLAGS=3D \ > - LD=3D"${LD} -m elf32ppc_fbsd" > + LD=3D"${LD} -melf32ppc_fbsd" > .endif >=20 >=20 > Index: /usr/srcC/sys/boot/i386/Makefile.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/srcC/sys/boot/i386/Makefile.inc (revision 279514) > +++ /usr/srcC/sys/boot/i386/Makefile.inc (working copy) > @@ -14,7 +14,7 @@ > CFLAGS+=3D -m32 > ACFLAGS+=3D -m32 > # LD_FLAGS is passed directly to ${LD}, not via ${CC}: > -LD_FLAGS+=3D -m elf_i386_fbsd > +LD_FLAGS+=3D -melf_i386_fbsd > AFLAGS+=3D --32 > .endif >=20 > Index: /usr/srcC/sys/boot/ofw/Makefile.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/srcC/sys/boot/ofw/Makefile.inc (revision 279514) > +++ /usr/srcC/sys/boot/ofw/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ >=20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -melf32ppc_fbsd > .endif >=20 > .include "../Makefile.inc" > Index: /usr/srcC/sys/boot/powerpc/Makefile.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/srcC/sys/boot/powerpc/Makefile.inc (revision 279514) > +++ /usr/srcC/sys/boot/powerpc/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ >=20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -melf32ppc_fbsd > .endif >=20 > .include "../Makefile.inc" > Index: /usr/srcC/sys/boot/uboot/Makefile.inc > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/srcC/sys/boot/uboot/Makefile.inc (revision 279514) > +++ /usr/srcC/sys/boot/uboot/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ >=20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -melf32ppc_fbsd > .endif >=20 > .include "../Makefile.inc" I did experiment with compiles of clang some and one thing that I = discovered was: The following file needed to be updated to be language compliant: > # svnlite diff = /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h > Index: /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h = (revision 279514) > +++ /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h = (working copy) > @@ -155,7 +155,7 @@ >=20 > template > IntrusiveRefCntPtr(IntrusiveRefCntPtr&& S) : Obj(S.get()) { > - S.Obj =3D 0; > + S.Obj =3D 0; /* access to private member needs friendship */ > } >=20 > template > @@ -197,6 +197,10 @@ > private: > void retain() { if (Obj) IntrusiveRefCntPtrInfo::retain(Obj); } > void release() { if (Obj) IntrusiveRefCntPtrInfo::release(Obj); = } > + > +/* FIX for Obj private access issue */ > + template > + friend class IntrusiveRefCntPtr; > }; >=20 > template Upstream llvm has this sort of change already, not with the comments. Other context details: My list of what files are different than svn is: # svnlite status /usr/srcC/ --no-ignore ? /usr/srcC/.snap M /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h ? /usr/srcC/restoresymtable M /usr/srcC/sys/ddb/db_main.c M /usr/srcC/sys/ddb/db_script.c ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc-NODEBUG ? /usr/srcC/sys/powerpc/conf/GENERICvtsc ? /usr/srcC/sys/powerpc/conf/GENERICvtsc-NODEBUG M /usr/srcC/sys/powerpc/ofw/ofw_machdep.c M /usr/srcC/sys/powerpc/ofw/ofwcall64.S But IntrusiveRefCntPtr.h does not matter if clang building is not = involved. And the rest existed in my environment before I started this = powerpc64-xtoolchain-gcc exploration. lib/libnv/test/dnv_tests.cc and lib/libnv/test/nv_tests.cc are from = later than the rest of the unmodified source code, teh rest being = from... # svnlite info /usr/srcC/ Path: . Working Copy Root Path: /usr/srcC URL: https://svn0.us-west.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279514 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 279514 Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) # more /etc/make.conf #CPP=3D/usr/local/bin/clang-cpp36 #CC=3D/usr/local/bin/clang36 #CXX=3D/usr/local/bin/clang++36 WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ports@FreeBSD.ORG Thu Mar 19 10:14:08 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1BDF2E4 for ; Thu, 19 Mar 2015 10:14:08 +0000 (UTC) Received: from portscout.freebsd.org (portscout.freebsd.org [IPv6:2001:1900:2254:206a::50:6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 07BCA932 for ; Thu, 19 Mar 2015 10:14:08 +0000 (UTC) Received: from portscout.freebsd.org ([127.0.1.123]) by portscout.freebsd.org (8.14.9/8.14.9) with ESMTP id t2JAE7qb034282 for ; Thu, 19 Mar 2015 10:14:07 GMT (envelope-from portscout@FreeBSD.org) Received: (from portscout@localhost) by portscout.freebsd.org (8.14.9/8.14.9/Submit) id t2JAE7dt034281; Thu, 19 Mar 2015 10:14:07 GMT (envelope-from portscout@FreeBSD.org) Message-Id: <201503191014.t2JAE7dt034281@portscout.freebsd.org> X-Authentication-Warning: portscout.freebsd.org: portscout set sender to portscout@FreeBSD.org using -f Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain MIME-Version: 1.0 Date: Thu, 19 Mar 2015 10:14:07 +0000 From: portscout@FreeBSD.org To: ports@freebsd.org Subject: FreeBSD ports you maintain which are out of date X-Mailer: portscout/0.8.1 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 10:14:08 -0000 Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/ports@freebsd.org.html Port | Current version | New version ------------------------------------------------+-----------------+------------ devel/rubygem-holidays | 1.0.5 | 1.2.0 ------------------------------------------------+-----------------+------------ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. From owner-freebsd-ports@FreeBSD.ORG Thu Mar 19 12:13:06 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1942EBDE for ; Thu, 19 Mar 2015 12:13:06 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B2FA487E for ; Thu, 19 Mar 2015 12:13:05 +0000 (UTC) Received: (qmail 30776 invoked from network); 19 Mar 2015 12:13:04 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 19 Mar 2015 12:13:04 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Thu, 19 Mar 2015 08:13:03 -0400 (EDT) Received: (qmail 17926 invoked from network); 19 Mar 2015 12:13:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Mar 2015 12:13:03 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 380A81C43AA; Thu, 19 Mar 2015 05:13:01 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: lib/csu/powerpc64/ requires/uses gcc command; does not use CC, XCC, or the like; its Makefile explains what caused the choice... Date: Thu, 19 Mar 2015 05:13:01 -0700 Message-Id: To: FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 12:13:06 -0000 For a CROSS_TOOLCHAIN=3Dpowerpc64-gcc based 11.0-CURRENT previously = built via WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D and for which = delete-old had cleaned out the 4.2.1 gcc and for which a rebuild is = attempted with... make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ WITHOUT_LLDB=3D \ WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITH_GNUCXX=3D \ WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ buildworld buildkernel \ KERNCONF=3DGENERIC64vtsc-NODEBUG \ TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 using... # more /etc/src.conf CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ X_COMPILER_TYPE=3Dgcc CXXFLAGS+=3D-I/usr/include/c++/v1 LDADD+=3D-L/usr/lib -lc++ NO_WERROR=3D It turns out that lib/csu/powerpc64/ still tries to use the gcc command: CC=3D'gcc -I/usr/obj/usr/srcC/tmp/usr/include/c++/v1' mkdep -f .depend = -a -I/usr/srcC/lib/csu/powerpc64/../common = -I/usr/srcC/lib/csu/powerpc64/../../libc/include -std=3Dgnu99 = /usr/srcC/lib/csu/powerpc64/crt1.c /usr/srcC/lib/csu/powerpc64/crti.S = /usr/srcC/lib/csu/powerpc64/crtn.S ... /usr/bin/mkdep: gcc: not found That stops the build. lib/csu/powerpc64/Makefile reports... # XXX: See the log for r232932 as to why the above -mlongcall is needed. = Since # clang doesn't support -mlongcall, and testing shows a clang linked = with a # clang-built csu segfaults, this must currently be compiled with gcc. = Once # clang supports -mlongcall, or we get a fixed ld, this can be = revisited. CC:=3D gcc COMPILER_TYPE:=3D gcc So this lead to another after-booted-as-gcc-4.9.1-based type of = oddity... Currently I'm having /usr/bin/gcc and /usr/bin/g++ be manually placed = symbolic links to the powerpc64-gcc programs, much like I've directed = /usr/lib/libstdc++.a and /usr/lib/libstdc++.so to reference the matching = libc++ file in the same directory in order to avoid complaints about not = finding -lstdc++ when I attempt the above make command. I've noticed that /usr/bin/cc and /usr/bin/c++ are still there for the = powerpc64-gcc experimental sequence that I've gone through and they are = still gcc 4.2.1. So I could point gcc and g++ to those to better match = the old context. But I'm exploring avoiding gcc 4.2.1 as much as I = reasonably can. I'm still avoiding building clang because a quick try got lost of error = reports, such as reports of attempts to use deleted functions. That = would seem to make an independent exploration direction. For now I'm = just checking on having a way to rebuild again but from the = powerpc64-gcc (4.9.1) build, this time including WITH_GCC_BOOTSTRAP=3D = and WITH_GCC=3D and WITH_GNUCXX=3D but avoiding their use. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ports@FreeBSD.ORG Thu Mar 19 20:59:00 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 598809C7 for ; Thu, 19 Mar 2015 20:59:00 +0000 (UTC) Received: from relay.mailchannels.net (tkt-001-i373.relay.mailchannels.net [174.136.5.175]) by mx1.freebsd.org (Postfix) with ESMTP id 8A09981B for ; Thu, 19 Mar 2015 20:58:59 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|xochitl Received: from smtp4.ore.mailhop.org (ip-10-204-4-183.us-west-2.compute.internal [10.204.4.183]) by relay.mailchannels.net (Postfix) with ESMTPA id A9C5110007B for ; Thu, 19 Mar 2015 20:58:51 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|xochitl Received: from smtp4.ore.mailhop.org (smtp4.ore.mailhop.org [10.21.145.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Thu, 19 Mar 2015 20:58:51 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|xochitl X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1426798731801:3356575518 X-MC-Ingress-Time: 1426798731801 Received: from [149.142.103.161] (helo=localhost) by smtp4.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YYhWh-0007oK-OC for ports@freebsd.org; Thu, 19 Mar 2015 20:58:48 +0000 X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 149.142.103.161 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX1+CBnnm2qPD9tuzGlfCQyLC From: Aric Gregson To: ports@freebsd.org Subject: Anyone able to use citrix_ica? Date: Thu, 19 Mar 2015 13:58:42 -0700 Message-ID: <86wq2c7lh9.fsf@freeenv.i-did-not-set--mail-host-address--so-tickle-me> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-AuthUser: xochitl X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 20:59:00 -0000 Hello, I am wondering if anyone has been able to get the citrix_ica to function? I am able to install it seemingly without problems, but it will never run. I get a 'permission denied' error when trying to run it from the CLI and nothing happens when using the web start. I used to have a modified version of this or a similar package before the new linux support, but since moving to the new linux support in FreeBSD I have not been able to get the citrix client working. Does anyone know how to get Citrix web client working on FreeBSD? Thanks, Aric From owner-freebsd-ports@FreeBSD.ORG Thu Mar 19 22:51:41 2015 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F246D80D; Thu, 19 Mar 2015 22:51:40 +0000 (UTC) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A3946CA; Thu, 19 Mar 2015 22:51:40 +0000 (UTC) Received: from [194.109.74.9] ([194.109.74.9]) by smtp-cloud6.xs4all.net with ESMTP id 5aqT1q00B0C1dyS01aqTDq; Thu, 19 Mar 2015 23:50:28 +0100 Message-ID: <550B52B3.8070502@xs4all.net> Date: Thu, 19 Mar 2015 23:50:27 +0100 From: Kai User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: ehaupt@FreeBSD.org Subject: FreeBSD Port: rsync-3.1.1_3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: ports@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 22:51:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello Ehaupt, I'm running into an issue when rsyncing to a freebsd host (10.1, running rsync-3.1.1, "pkg install rsync" version). When rsyncing a deep directorystructure that contains a socket I get the following error (backup is a nested dirstructure created to isolate this): > $ rsync -avH backup/ backup@freebsd-jail:/tmp/backup/ sending > incremental file list created directory /tmp/backup ./ rsync: mknod > "/tmp/backup/rTimeMachine/franks/140103-154024/franks/Library/Application > Support/iPhone Simulator/5.0/Library/Application > Support/Ubuquity/ubiquity.socket" failed: File name too long (63) > rTimeMachine/ rTimeMachine/franks/ > rTimeMachine/franks/140103-154024/ > rTimeMachine/franks/140103-154024/franks/ > rTimeMachine/franks/140103-154024/franks/Library/ > rTimeMachine/franks/140103-154024/franks/Library/Application > Support/ > rTimeMachine/franks/140103-154024/franks/Library/Application > Support/iPhone Simulator/ > rTimeMachine/franks/140103-154024/franks/Library/Application > Support/iPhone Simulator/5.0/ > rTimeMachine/franks/140103-154024/franks/Library/Application > Support/iPhone Simulator/5.0/Library/ > rTimeMachine/franks/140103-154024/franks/Library/Application > Support/iPhone Simulator/5.0/Library/Application Support/ > rTimeMachine/franks/140103-154024/franks/Library/Application > Support/iPhone Simulator/5.0/Library/Application Support/Ubuquity/ > > sent 433 bytes received 303 bytes 1,472.00 bytes/sec total size > is 0 speedup is 0.00 rsync error: some files/attrs were not > transferred (see previous errors) (code 23) at main.c(1183) > [sender=3.1.1] After cd'ing into the dir, the rsync works perfectly: > $ rsync -avH Ubuquity/ backup@freebsd-jail:/tmp/backup/ sending > incremental file list ./ ubiquity.socket > > sent 84 bytes received 22 bytes 212.00 bytes/sec total size is 0 > speedup is 0.00 > quadraginta:/tmp/backup/rTimeMachine/franks/140103-154024/franks/Library/Application > Support/iPhone Simulator/5.0/Library/Application Support $ Looking at man mknod(2): > [ENAMETOOLONG] A component of a pathname exceeded 255 > characters, or an entire path name exceeded 1023 characters. This shouldn't be a problem whilst looking at the path, I'm counting about 155 characters in total. What's wrong? Kind regards, Kai Storbeck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVC1KtAAoJEJrnqPcB7lLxAHEQAJZJvqB0dGDubqSed9ESCsyG QpgHAKLWaAiqyoutk1uZ7uG6ryluFOWPm09Ys3YriUmM5Kp6D4qGbudCqDJZawot myjimcRjqsdG6D6ncDVuCrQ+BEwTXLk9+YcRqe9fs8p0/2H0W+Job2mWtjGX14QH HF5hDD/M+ftyaTntqFb/b1ShTz4XK0G4Om3liWZqs7k8rqSv/fqe3MsJ2Y5u1zIi YiYLkg748p2vqp3zjYtD0kmdqDxTJSyxtzZd1X+vkK0fOUtwhb/aAG9g92RDcaeF ehcs7SfpuuDLbyq5WUZiGCJHGoVX+g4iCKhzJaxS34AbAUsynnT5KsG2chXa4E1x FMXmoqXmoKqfHNA++920Cmt1UcYiRW48TUqXQIcNlJ7A4lkuqw6yxt/26qmGssYI dpPPS7qD/pCY0a1Be102+43oEgW70x5H7LtJMoFoYPIIXu4Lmu+y+/EaP+wv6MLf dvi53CQxQ/S/BmcAKtkZI8rabPnZdwpjhZesrXgIhXK/bhRKKRMIEK23JxHIWIzy 3TebG3vzJeMAZwlN4/XH+KGYXw9lV+U9Qc4EZ0qk7QF4XppBrHOfyPRuUTuTong1 /4G76WsE0aeAJq5wCg8F58OtfSG72cjjVjKHgrf7igncLhLT7+fDGtjK9CUD7zcS W5FIhuYOgN39n+bqey6m =bA6s -----END PGP SIGNATURE----- From owner-freebsd-ports@FreeBSD.ORG Fri Mar 20 00:26:34 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 751C8DE6 for ; Fri, 20 Mar 2015 00:26:34 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 29B9B6D for ; Fri, 20 Mar 2015 00:26:33 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YYkX0-0000mr-Jd for freebsd-ports@freebsd.org; Fri, 20 Mar 2015 01:11:18 +0100 Received: from c-69-253-3-227.hsd1.pa.comcast.net ([69.253.3.227]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Mar 2015 01:11:18 +0100 Received: from mainland by c-69-253-3-227.hsd1.pa.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Mar 2015 01:11:18 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-ports@freebsd.org From: Geoffrey Mainland Subject: Re: net/unison240 depends on lang/ocaml-nox11 Date: Thu, 19 Mar 2015 20:11:13 -0400 Lines: 72 Message-ID: <550B65A1.9080402@apeiron.net> References: <5507555C.7030508@FreeBSD.org> <5507F80F.70609@FreeBSD.org> <55080F30.9010104@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org Cc: freebsd-ports@freebsd.org X-Gmane-NNTP-Posting-Host: c-69-253-3-227.hsd1.pa.comcast.net User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 In-Reply-To: <55080F30.9010104@FreeBSD.org> X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 00:26:34 -0000 On 03/17/2015 07:25 AM, Guido Falsi wrote: > On 03/17/15 11:44, Jeremie Le Hen wrote: >> On Tue, Mar 17, 2015 at 10:46 AM, Guido Falsi wrote: >>> On 03/17/15 09:31, Jeremie Le Hen wrote: >>>> On Mon, Mar 16, 2015 at 11:12 PM, Guido Falsi wrote: >>>>> On 03/16/15 22:37, Jeremie Le Hen wrote: >>>>>> Actually, I've just realized that I fixed net/unison232 in my local tree :o). >>>>>> >>>>>> Would you mind submitting it and applying the same for unison240? >>>>>> >>>>> >>>>> I never noticed this since it never happened to me and nobody else >>>>> reported it. >>>>> >>>>> Anyway now that you draw my attention, yes, it needs fixing. >>>>> >>>>> Your patch looks correct, but please allow me a little time for some >>>>> testing. >>>> >>>> OK thanks! :) >>> >>> Just committed it. Thanks again for reporting the issue! >> >> Thanks! >> >> I don't want to abuse your time, but "make checksum" is broken on >> net/unison240 :). >> > > Looks like distfiles were rerolled. 2.48 has the same problem. > > Will commit updated checksums shortly! > > Thanks again. I still get the same error Jeremie was getting with poudriere. I think the BUILD_DEPENDS should not be set unconditionally. The below patch fixes the problem for me. Does this look correct to you? Thanks, Geoff diff --git a/net/unison/Makefile b/net/unison/Makefile index 7404beb..461ebab 100644 --- a/net/unison/Makefile +++ b/net/unison/Makefile @@ -15,7 +15,7 @@ COMMENT?= User-level file synchronization tool LICENSE= GPLv3 -BUILD_DEPENDS= ocamlc:${PORTSDIR}/lang/ocaml + PLIST_SUB= PORTVERSION=${PORTVERSION} USES= gmake @@ -38,11 +38,13 @@ OPTIONS_DEFAULT?= DOCS X11 .if ${PORT_OPTIONS:MX11} MAKE_ARGS+= UISTYLE=gtk2 PLIST_SUB+= TEXT="" +BUILD_DEPENDS= ocamlc:${PORTSDIR}/lang/ocaml BUILD_DEPENDS+= lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 \ icotool:${PORTSDIR}/graphics/icoutils RUN_DEPENDS+= lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 SUB_FILES+= ${PORTNAME}.desktop .else +BUILD_DEPENDS= ocamlc:${PORTSDIR}/lang/ocaml-nox11 MAKE_ARGS+= UISTYLE=text PLIST_SUB+= TEXT="@comment " PKGMESSAGE= ${PKGDIR}/pkg-message.nox11 From owner-freebsd-ports@FreeBSD.ORG Fri Mar 20 07:26:57 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B8B9897 for ; Fri, 20 Mar 2015 07:26:57 +0000 (UTC) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 32304EA5 for ; Fri, 20 Mar 2015 07:26:56 +0000 (UTC) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-07v.sys.comcast.net with comcast id 5jSu1q0022Bo0NV01jSut5; Fri, 20 Mar 2015 07:26:54 +0000 Received: from www.cyberbotx.com ([107.5.48.95]) by resomta-ch2-05v.sys.comcast.net with comcast id 5jSt1q00G23DSHF01jSte7; Fri, 20 Mar 2015 07:26:54 +0000 Received: from 192.168.2.2 (SquirrelMail authenticated user cyberbotx) by www.cyberbotx.com with HTTP; Fri, 20 Mar 2015 03:26:54 -0400 Message-ID: <082281810b1723c5b47aaf826998ea37.squirrel@www.cyberbotx.com> Date: Fri, 20 Mar 2015 03:26:54 -0400 Subject: Is it possibly to detect which OpenSSL is used for a port? From: "Naram Qashat" To: freebsd-ports@FreeBSD.org User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1426836414; bh=YtjWdukVRQ1tYrm+yH01Cf4cavWqkv2ITzb1tcSCT8E=; h=Received:Received:Received:Message-ID:Date:Subject:From:To: MIME-Version:Content-Type; b=SVlrNG60Q58apXurBmZUiITip79ACZo7DheCwu7f8k6l4BI0usG78GxOZL08BYSbO 5tK4BLgHYnl0TkDyLZEnLDEE9d8jo/sqgyP/gZBqAl14gGSJjeKcgQYy1zCBJi+W+Y P380+KengZcRTA5jETWNoH3tlgaf+as4TDt8VE0+bmQeRnq0RMqom9qCU7YyLLVzf0 W+J8tKDyfTylKpZ7gyNj6jL+4pNGgjn9KQChfDTwQhtZLWBAdZYmJYcnUpHO3hsGHm msnX7rf+QfQggzGRYUFo/uxeFaOmwaPRbdq/kGeOXHXiv7ssXiy1NIj5vExzhofQu9 0kL4oSfGJ9gnQ== X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 07:26:57 -0000 So, I know that WITH_OPENSSL_BASE=yes or WITH_OPENSSL_PORT=yes can be set by a user to say they specifically want either the base or the ports version of OpenSSL. But is there a way to determine within a port which OpenSSL is being used, either base or ports? Should I check if OPENSSLBASE is set to /usr? Is there some other (or better) way to do it? From owner-freebsd-ports@FreeBSD.ORG Fri Mar 20 08:43:49 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2A5A383 for ; Fri, 20 Mar 2015 08:43:49 +0000 (UTC) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A001AC8 for ; Fri, 20 Mar 2015 08:43:49 +0000 (UTC) Received: by yhim52 with SMTP id m52so8498193yhi.2 for ; Fri, 20 Mar 2015 01:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=7yuVNC8p2q35ty6LB55LHYE7w5N+KyrBY3tUYCZb0F4=; b=0xQeVjUawdB9qYbq+qUsp7mWP1v0DZ/ewPRzlpEkpPrYqCbM1H5BqWyEtIMzoVSiiN hI7qu2bX3zAXXDko9mBGc/p8o6n3MEh1LUiwmGheSAoDpPrIyhge9O2jTOLg8PheftA0 mzRElLDHzUULRK8EqpgL/G0pYFdxb4PJB9nblFKQD/kRbLJDYGSdWMxdAjKThPTzg6QZ qIyHPrEyjoN4+bbrJwXv0HpJWLXr55Cnn5EuIHkxJZTqXefeNNKL28geBhhXNdVRtU/p qZe8T3tpRs/1ncWhGh3bmI+3wiuk0CxEubWmxv1nGnhtdE4EsoDgKRoMh7pO/8sRWKzo NPCQ== MIME-Version: 1.0 X-Received: by 10.52.31.66 with SMTP id y2mr18527425vdh.16.1426841028717; Fri, 20 Mar 2015 01:43:48 -0700 (PDT) Received: by 10.52.29.106 with HTTP; Fri, 20 Mar 2015 01:43:48 -0700 (PDT) In-Reply-To: References: <4c18dec0d168e393ff5dddfdc65c7ec6@sdf.org> <20150228074951.GD62590@home.opsec.eu> <20150228110834.GF62590@home.opsec.eu> Date: Fri, 20 Mar 2015 11:43:48 +0300 Message-ID: Subject: Re: Initial squid 3.5 port From: Pavel Timofeev Cc: ports-list freebsd Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 08:43:50 -0000 Hello! The new shar file squid35-20.03.15.shar was uploaded today. Look at this PR https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198089. You can find my comments about progress there. I'm asking people who is using www/squid: please, test it as much as possible! P.S. It's a new port (shar) now just for testing. Of course, it will/can be converted to patch for www/squid when it's recognized as ready. 2015-03-11 12:07 GMT+03:00 Pavel Timofeev : > Hi! I've just made a small update there > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198089 > > 2015-02-28 15:30 GMT+03:00 Pavel Timofeev : >> Ok, I'll do my best. >> >> 2015-02-28 14:08 GMT+03:00 Kurt Jaeger : >>> Hi! >>> >>>> > Just in case, I uploaded it here https://yadi.sk/d/EcRxwc6BevgDc >>>> >>>> I've created >>>> >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198089 >>>> >>>> with that shar and I'm build-testing it right now. >>> >>> build testing: works on 10.1a, fails on 9.3a, 8.4i. >>> >>> poudriere build logs can be found at >>> >>> http://people.freebsd.org/~pi/logs/www__squid35* >>> >>> Older builds are with a custom config, newer builds with the generic config. >>> >>> Can you investigate the cause of the issue ? >>> >>> -- >>> pi@opsec.eu +49 171 3101372 5 years to go ! From owner-freebsd-ports@FreeBSD.ORG Fri Mar 20 10:27:00 2015 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB2FBD17; Fri, 20 Mar 2015 10:27:00 +0000 (UTC) Received: from critical.ch (critical.ch [IPv6:2a01:4f8:d16:2743::1:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx.critical.ch", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5ED5278E; Fri, 20 Mar 2015 10:27:00 +0000 (UTC) Received: from wiggles.local (dynamic.wline.6rd.res.cust.swisscom.ch [IPv6:2a02:120b:c3f9:27d0:dad3:85ff:fe79:dd2] (may be forged)) (authenticated bits=0) by critical.ch (8.14.9/8.14.9/critical-1.0) with ESMTP id t2KAQvoF002941; Fri, 20 Mar 2015 11:26:57 +0100 (CET) (envelope-from ehaupt@FreeBSD.org) Date: Fri, 20 Mar 2015 11:26:52 +0100 From: Emanuel Haupt To: Kai Subject: Re: FreeBSD Port: rsync-3.1.1_3 Message-Id: <20150320112652.b52f41b26968933912692727@FreeBSD.org> In-Reply-To: <550B52B3.8070502@xs4all.net> References: <550B52B3.8070502@xs4all.net> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.25; amd64-portbld-freebsd10.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: ports@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 10:27:00 -0000 Kai wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hello Ehaupt, > > I'm running into an issue when rsyncing to a freebsd host (10.1, > running rsync-3.1.1, "pkg install rsync" version). > > When rsyncing a deep directorystructure that contains a socket I get > the following error (backup is a nested dirstructure created to > isolate this): > > > $ rsync -avH backup/ backup@freebsd-jail:/tmp/backup/ sending > > incremental file list created directory /tmp/backup ./ rsync: mknod > > "/tmp/backup/rTimeMachine/franks/140103-154024/franks/Library/Application > > Support/iPhone Simulator/5.0/Library/Application > > Support/Ubuquity/ubiquity.socket" failed: File name too long (63) > > rTimeMachine/ rTimeMachine/franks/ > > rTimeMachine/franks/140103-154024/ > > rTimeMachine/franks/140103-154024/franks/ > > rTimeMachine/franks/140103-154024/franks/Library/ > > rTimeMachine/franks/140103-154024/franks/Library/Application > > Support/ > > rTimeMachine/franks/140103-154024/franks/Library/Application > > Support/iPhone Simulator/ > > rTimeMachine/franks/140103-154024/franks/Library/Application > > Support/iPhone Simulator/5.0/ > > rTimeMachine/franks/140103-154024/franks/Library/Application > > Support/iPhone Simulator/5.0/Library/ > > rTimeMachine/franks/140103-154024/franks/Library/Application > > Support/iPhone Simulator/5.0/Library/Application Support/ > > rTimeMachine/franks/140103-154024/franks/Library/Application > > Support/iPhone Simulator/5.0/Library/Application Support/Ubuquity/ > > > > sent 433 bytes received 303 bytes 1,472.00 bytes/sec total size > > is 0 speedup is 0.00 rsync error: some files/attrs were not > > transferred (see previous errors) (code 23) at main.c(1183) > > [sender=3.1.1] > > After cd'ing into the dir, the rsync works perfectly: > > $ rsync -avH Ubuquity/ backup@freebsd-jail:/tmp/backup/ sending > > incremental file list ./ ubiquity.socket > > > > sent 84 bytes received 22 bytes 212.00 bytes/sec total size is 0 > > speedup is 0.00 > > quadraginta:/tmp/backup/rTimeMachine/franks/140103-154024/franks/Library/Application > > Support/iPhone Simulator/5.0/Library/Application Support $ > > Looking at man mknod(2): > > [ENAMETOOLONG] A component of a pathname exceeded 255 > > characters, or an entire path name exceeded 1023 characters. > > This shouldn't be a problem whilst looking at the path, I'm counting > about 155 characters in total. > > What's wrong? Hi Kai Can you identify the particular file that causes the problem? If so, could you please show me the output of $ stat file What filesystem is this file on? Emanuel > > Kind regards, > Kai Storbeck > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQIcBAEBCAAGBQJVC1KtAAoJEJrnqPcB7lLxAHEQAJZJvqB0dGDubqSed9ESCsyG > QpgHAKLWaAiqyoutk1uZ7uG6ryluFOWPm09Ys3YriUmM5Kp6D4qGbudCqDJZawot > myjimcRjqsdG6D6ncDVuCrQ+BEwTXLk9+YcRqe9fs8p0/2H0W+Job2mWtjGX14QH > HF5hDD/M+ftyaTntqFb/b1ShTz4XK0G4Om3liWZqs7k8rqSv/fqe3MsJ2Y5u1zIi > YiYLkg748p2vqp3zjYtD0kmdqDxTJSyxtzZd1X+vkK0fOUtwhb/aAG9g92RDcaeF > ehcs7SfpuuDLbyq5WUZiGCJHGoVX+g4iCKhzJaxS34AbAUsynnT5KsG2chXa4E1x > FMXmoqXmoKqfHNA++920Cmt1UcYiRW48TUqXQIcNlJ7A4lkuqw6yxt/26qmGssYI > dpPPS7qD/pCY0a1Be102+43oEgW70x5H7LtJMoFoYPIIXu4Lmu+y+/EaP+wv6MLf > dvi53CQxQ/S/BmcAKtkZI8rabPnZdwpjhZesrXgIhXK/bhRKKRMIEK23JxHIWIzy > 3TebG3vzJeMAZwlN4/XH+KGYXw9lV+U9Qc4EZ0qk7QF4XppBrHOfyPRuUTuTong1 > /4G76WsE0aeAJq5wCg8F58OtfSG72cjjVjKHgrf7igncLhLT7+fDGtjK9CUD7zcS > W5FIhuYOgN39n+bqey6m > =bA6s > -----END PGP SIGNATURE----- > From owner-freebsd-ports@FreeBSD.ORG Fri Mar 20 10:30:29 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C663F6B for ; Fri, 20 Mar 2015 10:30:29 +0000 (UTC) Received: from portscout.freebsd.org (portscout.freebsd.org [IPv6:2001:1900:2254:206a::50:6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 67C207BD for ; Fri, 20 Mar 2015 10:30:29 +0000 (UTC) Received: from portscout.freebsd.org ([127.0.1.123]) by portscout.freebsd.org (8.14.9/8.14.9) with ESMTP id t2KAUTov028375 for ; Fri, 20 Mar 2015 10:30:29 GMT (envelope-from portscout@FreeBSD.org) Received: (from portscout@localhost) by portscout.freebsd.org (8.14.9/8.14.9/Submit) id t2KAUTpE028374; Fri, 20 Mar 2015 10:30:29 GMT (envelope-from portscout@FreeBSD.org) Message-Id: <201503201030.t2KAUTpE028374@portscout.freebsd.org> X-Authentication-Warning: portscout.freebsd.org: portscout set sender to portscout@FreeBSD.org using -f Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain MIME-Version: 1.0 Date: Fri, 20 Mar 2015 10:30:29 +0000 From: portscout@FreeBSD.org To: ports@freebsd.org Subject: FreeBSD ports you maintain which are out of date X-Mailer: portscout/0.8.1 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 10:30:29 -0000 Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/ports@freebsd.org.html Port | Current version | New version ------------------------------------------------+-----------------+------------ lang/yabasic | 2.767 | 2.768 ------------------------------------------------+-----------------+------------ net/jsch | 0.1.51 | 0.1.52 ------------------------------------------------+-----------------+------------ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. From owner-freebsd-ports@FreeBSD.ORG Fri Mar 20 10:32:27 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A806EDC; Fri, 20 Mar 2015 10:32:27 +0000 (UTC) Received: from critical.ch (critical.ch [IPv6:2a01:4f8:d16:2743::1:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx.critical.ch", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E5F387C; Fri, 20 Mar 2015 10:32:27 +0000 (UTC) Received: from wiggles.local (dynamic.wline.6rd.res.cust.swisscom.ch [IPv6:2a02:120b:c3f9:27d0:dad3:85ff:fe79:dd2] (may be forged)) (authenticated bits=0) by critical.ch (8.14.9/8.14.9/critical-1.0) with ESMTP id t2KAWOkv003081; Fri, 20 Mar 2015 11:32:25 +0100 (CET) (envelope-from ehaupt@FreeBSD.org) Date: Fri, 20 Mar 2015 11:32:19 +0100 From: Emanuel Haupt To: Aric Gregson Subject: Re: Anyone able to use citrix_ica? Message-Id: <20150320113219.1a5495ecd9570e29021c5133@FreeBSD.org> In-Reply-To: <86wq2c7lh9.fsf@freeenv.i-did-not-set--mail-host-address--so-tickle-me> References: <86wq2c7lh9.fsf@freeenv.i-did-not-set--mail-host-address--so-tickle-me> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.25; amd64-portbld-freebsd10.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, xmj@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 10:32:27 -0000 Aric Gregson wrote: > Hello, > > I am wondering if anyone has been able to get the citrix_ica to > function? I am able to install it seemingly without problems, but it > will never run. I get a 'permission denied' error when trying to run > it from the CLI and nothing happens when using the web start. > > I used to have a modified version of this or a similar package before > the new linux support, but since moving to the new linux support in > FreeBSD I have not been able to get the citrix client working. Does > anyone know how to get Citrix web client working on FreeBSD? > > Thanks, Aric It has been broken for me for quite some time. I've tried to update to the most recent version but couldn't get it to work. In case anyone would like to pickup from where I've left off, it's available on the phabricator: https://reviews.freebsd.org/D1856 Current status: - files are most likely installed into the wrong path, however - firefox plugin can be created with nspluginwrapper and does show up in about:config - trying to connect fails, tcpdump showed no connection attempts Emanuel From owner-freebsd-ports@FreeBSD.ORG Fri Mar 20 11:28:48 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B5538FE for ; Fri, 20 Mar 2015 11:28:48 +0000 (UTC) Received: from mail37.atl51.rsgsv.net (mail37.atl51.rsgsv.net [205.201.135.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3FA0ED57 for ; Fri, 20 Mar 2015 11:28:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=k1; d=mail37.atl51.rsgsv.net; h=Subject:From:Reply-To:To:Date:Message-ID:List-ID:List-Unsubscribe:Sender:Content-Type:MIME-Version; i=prima=3Drentacarprima.com@mail37.atl51.rsgsv.net; bh=RlPXMKqHqKsCRxJFkoYZVDxWrc8=; b=LfgAA8tr1esKgJ2GWmwEkt6ToPQfx4yEfy2lu6MKGYQjwHxLgBqyQh61fTU7WMGo86WruG0Lat4K 25zCKl1IJDpMBodXpKWqjAWQN8xgMeHcU1WVtnEFFs++7WjpIHRlZSV5Gx2dSU4zcjPD38l4HsK6 CXtZPc1z8r+yGXvFOe8= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=k1; d=mail37.atl51.rsgsv.net; b=1SNFhB8Oge/AfdvGlHkAmqvkgLIlhUEYs6nfnfa3czXvxsh3MeUKh32iCk/6z2dc+iC7FVXSfVC1 3OBX8aozZ6QZqFhCZVWTIxzEOlS/mI66qQTEcepQvGL+tKqI4gCKJRR9fPGf3SC1tol692sa1CS0 kbLexk/WJwYKx19SyZ4=; Received: from (127.0.0.1) by mail37.atl51.rsgsv.net id h1g26u1mr1of for ; Fri, 20 Mar 2015 11:10:49 +0000 (envelope-from ) Subject: =?utf-8?Q?Wishing=20you=20a=20Happy=20Eastern=20from=20Prima=20Rent=20a=20Car?= From: =?utf-8?Q?Prima=20Rent=20a=20Car?= Reply-To: =?utf-8?Q?Prima=20Rent=20a=20Car?= To: Date: Fri, 20 Mar 2015 11:10:49 +0000 Message-ID: X-Mailer: MailChimp Mailer - **CIDb9f4cb0b1cc05265e036** X-Campaign: mailchimpb9847da4b7e67330bdeb1e761.b9f4cb0b1c X-campaignid: mailchimpb9847da4b7e67330bdeb1e761.b9f4cb0b1c X-Report-Abuse: Please report abuse for this campaign here: http://www.mailchimp.com/abuse/abuse.phtml?u=b9847da4b7e67330bdeb1e761&id=b9f4cb0b1c&e=c05265e036 X-MC-User: b9847da4b7e67330bdeb1e761 X-Feedback-ID: 6209146:6209146.2118849:us2:mc X-Accounttype: pd Sender: "Prima Rent a Car" x-mcda: FALSE MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format="fixed" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 11:28:48 -0000 ITB 2015 : Prima Rent will be there ------------------------------------------------------------ http://us2.campaign-archive2.com/?u=3Db9847da4b7e67330bdeb1e761&id=3Db9f4c= b0b1c&e=3Dc05265e036 Remember we have all sorts of vehicles for rent available this Easters=2C= from Economy to luxury=2C mobility=2C bikes and scooters; all with the qu= ality and service we are know for. Please make your booking in advance to= secure your rental. The number of vehicles available is limited. With more than 20 years experience in the rental of Vehicles on the Costa= del Sol. We offer the rental of all kind of vehicles=2C including Cars fr= om the Economy Class=2C till the Luxury Class=2C minivans and compact cars= =2E We also offer Eco and Hybrid Vehicles. From our locations in M=C3=A1laga= Center and Marbella we also offer Bikes=2C Motorbikes=2C Segways=2C and M= obility Scooters. We offer our services from : * M=C3=A1laga Airport : Including our Vip Service with delivery/return dir= ectly at Arrivals=2C with no Queues. * M=C3=A1laga Center : From the very center of the SoHo quarters=2C and wi= th delivery to Hotels * M=C3=A1laga Port : At the Cruise Terminal=2C ment for Cruise Travellers * Puerto Ban=C3=BAs Marbella : At El Corte Ingl=C3=A9s Ban=C3=BAs=2C Eco a= nd Luxury Cars=2C as well as Bikes and Mopeds >From our New Marbella office we are offering all our well known services a= nd VIP treatment to our customers=2C as well as : * Luxury Cars=2C including Porsche=2C Mini=2C Audi=2C and Mercedes * Delivery/Return of cars at the famous =E2=80=9CGolden Mile=E2=80=9D of t= he Costa del Sol. * Rental of Bicycles=2C electric and manual=2C Mopeds and Segways. * Rental of Mobility Vehicles=2C for street use=2C as well as inside the S= hopping Centre COME SEE US !! Kind Regards Ana Mar=C3=ADa Garc=C3=ADa Manager - Prima Rent a Car =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ** Twitter (https://www.twitter.com/PrimaRent/) | ** Facebook (https://www.facebook.com/prima.rent.1) | ** Recomendar a amigos (http://us2.forward-to-friend2.com/forward?u=3Db9= 847da4b7e67330bdeb1e761&id=3Db9f4cb0b1c&e=3Dc05265e036) Copyright =C2=A9 2015 Prima Rent a Car=2C All rights reserved. You are receiving this email because you rented from us at Prima Rent a C= ar Our Address is : Prima Rent a Car C/ Ildefonso Marzo=2C 9 Malaga=2C MALAGA 29003 Spain Email Marketing Powered by MailChimp http://www.mailchimp.com/monkey-rewards/?utm_source=3Dfreemium_newsletter&= utm_medium=3Demail&utm_campaign=3Dmonkey_rewards&aid=3Db9847da4b7e67330bde= b1e761&afl=3D1 ** Dar de baja de esta lista (http://rentacarprima.us2.list-manage.com/uns= ubscribe?u=3Db9847da4b7e67330bdeb1e761&id=3D0831ec76b4&e=3Dc05265e036&c=3Db9= f4cb0b1c) | ** Actualizar Preferencias (http://rentacarprima.us2.list-manage1.com/pr= ofile?u=3Db9847da4b7e67330bdeb1e761&id=3D0831ec76b4&e=3Dc05265e036) From owner-freebsd-ports@FreeBSD.ORG Fri Mar 20 15:37:18 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0DECA108; Fri, 20 Mar 2015 15:37:18 +0000 (UTC) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A3DA0CFC; Fri, 20 Mar 2015 15:37:17 +0000 (UTC) Received: by wegp1 with SMTP id p1so85046256weg.1; Fri, 20 Mar 2015 08:37:16 -0700 (PDT) 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=Oak29biAbCq4C0SqAYVx6kMM4EaDjBkjhuqibb++aHY=; b=wbGvDVV8T/S79mlxC/pm9tMq0QfVWgFkbibR25XogBgcY6GGMvZPZ4hP56/H/+hCEB qWjs9PnBe6c5bZQl06vkd4oKzb6G/b6lN0ncE4Tgz/85ELz824il7O6bCd93xfyrQtoY /Trt6q+fdQkpWI5XRb16n/gPIz+SjoD99GxPpnuHnGvKptTLsv3ulbLmD8+XMvTGrFax smerSRecwIojWLcyFpVOjtR1wyWoASg/Ktl8CKGJoXcOm1MGOCXn5AUL6KB8py17dqaL OJwKpr0JDn7Gh8yaI2ZuOQzaiues7bsgpZPJ05mQoIuog/Hz5YDqeXwJFyFqqYEpZae2 pLvw== X-Received: by 10.194.76.69 with SMTP id i5mr22175735wjw.3.1426865836091; Fri, 20 Mar 2015 08:37:16 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id l9sm3491433wij.16.2015.03.20.08.37.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Mar 2015 08:37:15 -0700 (PDT) Sender: Baptiste Daroussin Date: Fri, 20 Mar 2015 16:37:13 +0100 From: Baptiste Daroussin To: x11@FreeBSD.org, ports@FreeBSD.org Subject: [HEADSUP] WIP on fonts Message-ID: <20150320153711.GB87678@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3uo+9/B/ebqu+fSQ" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 15:37:18 -0000 --3uo+9/B/ebqu+fSQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, Some of you may have notice some work on the font area. The goal of this work is to prevent every single font package to act differently and most of the time not correctly. The change will be done in multiple steps: 1/ Convert every ports to USES=fonts 2/ Remove @fc and @fontsdir keywords to only keep @fcfontsdir 3/ Move all fonts from ${LOCALBASE}/lib/X11/fonts to ${LOCALBASE}/share/fonts in order to make the fonts following XDG as well as making them working for non-x11 world (wayland for example) Best regards, Bapt --3uo+9/B/ebqu+fSQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEUEARECAAYFAlUMPqcACgkQ8kTtMUmk6ExQQACXTyNTdExcCi3XnTLyM4/s0uvk UQCdF1MCRyp+G5LOgqR/neA0Lv88ZDE= =ITFb -----END PGP SIGNATURE----- --3uo+9/B/ebqu+fSQ-- From owner-freebsd-ports@FreeBSD.ORG Fri Mar 20 16:26:00 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A20E413 for ; Fri, 20 Mar 2015 16:26:00 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D1AC72DF for ; Fri, 20 Mar 2015 16:25:59 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t2KGSFnY035567 for ; Fri, 20 Mar 2015 09:28:15 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <20150320153711.GB87678@ivaldir.etoilebsd.net> References: <20150320153711.GB87678@ivaldir.etoilebsd.net> From: "Chris H" Subject: Re: [HEADSUP] WIP on fonts Date: Fri, 20 Mar 2015 09:28:15 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 16:26:00 -0000 On Fri, 20 Mar 2015 16:37:13 +0100 Baptiste Daroussin wrote > Hi all, > > Some of you may have notice some work on the font area. > > The goal of this work is to prevent every single font package to act > differently and most of the time not correctly. .. > 3/ Move all fonts from ${LOCALBASE}/lib/X11/fonts to ${LOCALBASE}/share/fonts Won't this invalidate the current entries in /etc/X11/xorg.conf? eg; FontPath "/usr/local/lib/X11/fonts/{...}" P.S. Thanks for doing this. Consistency is nice! :) --Chris From owner-freebsd-ports@FreeBSD.ORG Fri Mar 20 16:51:01 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B0AFE5F for ; Fri, 20 Mar 2015 16:51:01 +0000 (UTC) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B871D847 for ; Fri, 20 Mar 2015 16:51:00 +0000 (UTC) Received: by weop45 with SMTP id p45so86664211weo.0 for ; Fri, 20 Mar 2015 09:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=feWi+zEcnWfnbfVc3Wgv6s6iymWsw8LvvxY2O5bppkg=; b=KO+ktDn4NF+0ewFOZlN55M30WbXHB/7mDJxuhjeOFsSS+VrO3yj+86UJjDPJdBRiBX HL5wFSg8uMLZCKUwcKjNYSXtviCS6q55VXKyPYX7WX2ZmmXu6URYD/r46016CkviPpc4 iG2AGs9XLMSv9wDylIwz3eTdiQTg8YLWu404TxE8hO2u75ZfYSv1J2/4hnK/LTXzMOrB vy6e2UkDd+ATp4C4rI/nZS6Yuh1LCY/sEnHCpP5x+tjBTmvSDqQvG16OnQz5O+9JIdoK o834fMw7ycQOqb4m6tfirCZmvEXf7KgmDVTWhReoaBdwRLwUuSYgTSS5iNIfRuIzkcLJ /ZCQ== X-Received: by 10.194.157.68 with SMTP id wk4mr43423109wjb.130.1426870259238; Fri, 20 Mar 2015 09:50:59 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id fs8sm3757459wib.8.2015.03.20.09.50.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Mar 2015 09:50:58 -0700 (PDT) Sender: Baptiste Daroussin Date: Fri, 20 Mar 2015 17:50:56 +0100 From: Baptiste Daroussin To: Chris H Subject: Re: [HEADSUP] WIP on fonts Message-ID: <20150320165056.GC87678@ivaldir.etoilebsd.net> References: <20150320153711.GB87678@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PuGuTyElPB9bOcsM" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 16:51:01 -0000 --PuGuTyElPB9bOcsM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 20, 2015 at 09:28:15AM -0700, Chris H wrote: > On Fri, 20 Mar 2015 16:37:13 +0100 Baptiste Daroussin = wrote >=20 > > Hi all, > >=20 > > Some of you may have notice some work on the font area. > >=20 > > The goal of this work is to prevent every single font package to act > > differently and most of the time not correctly. > .. > > 3/ Move all fonts from ${LOCALBASE}/lib/X11/fonts to ${LOCALBASE}/share= /fonts >=20 > Won't this invalidate the current entries in /etc/X11/xorg.conf? > eg; > FontPath "/usr/local/lib/X11/fonts/{...}" >=20 > P.S. Thanks for doing this. Consistency is nice! :) >=20 > --Chris >=20 Yes this will, that is why I plan to add an entry in UPDATING, anyway xorg = is supposed to be able to work without those FontPath now so it might be seaml= ess for most(all?) users. Best regards, Bapt --PuGuTyElPB9bOcsM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUMT/AACgkQ8kTtMUmk6EzYqgCbBGaymkTk7nG74/eRgAbdO80j nSYAoIjQxhHP/oenbciWnKUnm3qUUWPX =bzuh -----END PGP SIGNATURE----- --PuGuTyElPB9bOcsM-- From owner-freebsd-ports@FreeBSD.ORG Fri Mar 20 17:18:51 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37A5D734 for ; Fri, 20 Mar 2015 17:18:51 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0CF2CACA for ; Fri, 20 Mar 2015 17:18:50 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t2KHL7YB046524 for ; Fri, 20 Mar 2015 10:21:07 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <20150320165056.GC87678@ivaldir.etoilebsd.net> References: <20150320153711.GB87678@ivaldir.etoilebsd.net> , <20150320165056.GC87678@ivaldir.etoilebsd.net> From: "Chris H" Subject: Re: [HEADSUP] WIP on fonts Date: Fri, 20 Mar 2015 10:21:07 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <01126e6b54fe63e01bd4d3be74de1dd4@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 17:18:51 -0000 On Fri, 20 Mar 2015 17:50:56 +0100 Baptiste Daroussin wrote > On Fri, Mar 20, 2015 at 09:28:15AM -0700, Chris H wrote: > > On Fri, 20 Mar 2015 16:37:13 +0100 Baptiste Daroussin > > wrote > > > Hi all, > > > > > > Some of you may have notice some work on the font area. > > > > > > The goal of this work is to prevent every single font package to act > > > differently and most of the time not correctly. > > .. > > > 3/ Move all fonts from ${LOCALBASE}/lib/X11/fonts to > > > ${LOCALBASE}/share/fonts > > > Won't this invalidate the current entries in /etc/X11/xorg.conf? > > eg; > > FontPath "/usr/local/lib/X11/fonts/{...}" > > > > P.S. Thanks for doing this. Consistency is nice! :) > > > > --Chris > > > Yes this will, that is why I plan to add an entry in UPDATING, anyway xorg is > supposed to be able to work without those FontPath now so it might be > seamless for most(all?) users. Ahh. Good. I was just wondering if it was going to be like when X was moved from /usr, to /usr/local, and a symlink was placed to reconcile the change. But IMHO a note in UPDATING should be good enough. It encourages those who don't, to start reading it. :-) Thanks again, and sorry for the bother. --Chris --Chris -- From owner-freebsd-ports@FreeBSD.ORG Fri Mar 20 18:02:32 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D757137E for ; Fri, 20 Mar 2015 18:02:32 +0000 (UTC) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DBFE4E for ; Fri, 20 Mar 2015 18:02:32 +0000 (UTC) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-07v.sys.comcast.net with comcast id 5u0u1q00529Cfhx01u2XV7; Fri, 20 Mar 2015 18:02:31 +0000 Received: from www.cyberbotx.com ([107.5.48.95]) by resomta-ch2-03v.sys.comcast.net with comcast id 5u2X1q00B23DSHF01u2XUP; Fri, 20 Mar 2015 18:02:31 +0000 Received: from 192.168.2.2 (SquirrelMail authenticated user cyberbotx) by www.cyberbotx.com with HTTP; Fri, 20 Mar 2015 14:02:31 -0400 Message-ID: <1b89602a13f212214de4f70feaf3f11e.squirrel@www.cyberbotx.com> Date: Fri, 20 Mar 2015 14:02:31 -0400 Subject: Re: Is it possibly to detect which OpenSSL is used for a port? From: "Naram Qashat" To: freebsd-ports@FreeBSD.org User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1426874551; bh=iH6M4owgNr78/HC++pc3ZuKQxyOFeZETM1t0EgKQUmk=; h=Received:Received:Received:Message-ID:Date:Subject:From:To: MIME-Version:Content-Type; b=dudY8Hlxk+06wxU/1GrJHWZ5tMVF0N4rUShjME3R+9bCIjX4hm1ohCupfZfLDh1Z1 qj+MvloNB8G+T5u5ZaRB+vDquo7rnuRCg5ZEbeyQJY2NSTOjDgWxWZqYpE7eeehGtj SQVDJ3afbfN3017RAx03bPZn4XV17voBTXUB1QGy7piD02T1UuRucHuTLtPpV1dFYB QFqEZSArSZ4q7GCF+5xEZIZJXvlynmUbThivomvX+Q4gSO5MeYqPVTU6/Mi4ZQ1cwP YYrTVKrmku9xdwG0E/sCUgPISuabMmWMdsRsFPCR2lDL8uXiKUC5LSYMWa9ZzKG1XZ TKh3h2yxnwVhw== X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 18:02:33 -0000 This isn't quite what I'm looking for. I want to be able to tell within a port's Makefile if the user wanted the base or ports OpenSSL to be used. I've been trying to port TDE to FreeBSD, and tdelibs uses pkg-config to check for OpenSSL. This would work if the only form of OpenSSL was in ports, but the base OpenSSL doesn't have a pkg-config file to use, so I need to know which is going to be used so I can determine when this pkg-config check can be removed. > Naram Qashat schrieb:, > >> So, I know that WITH_OPENSSL_BASE=yes or WITH_OPENSSL_PORT=yes can be >> set >> by a user to say they specifically want either the base or the ports >> version of OpenSSL. But is there a way to determine within a port which >> OpenSSL is being used, either base or ports? Should I check if >> OPENSSLBASE >> is set to /usr? Is there some other (or better) way to do it? > > You can check the shared binaries with "ldd". > > $ ldd /usr/local/libexec/dovecot/imap-login > /usr/local/libexec/dovecot/imap-login: > libssl.so.6 => /usr/lib/libssl.so.6 (0x33cb7000) > libcrypto.so.6 => /lib/libcrypto.so.6 (0x33d04000) > librt.so.1 => /usr/lib/librt.so.1 (0x33e66000) > libc.so.7 => /lib/libc.so.7 (0x33e6b000) > > We look for libssl .... > > $ ldd /usr/local/libexec/dovecot/imap-login | grep libssl.so > libssl.so.6 => /usr/lib/libssl.so.6 (0x33cb7000) > > This dovecot was build with the openssl-port. > > $ ldd /usr/local/bin/stunnel | grep libssl.so > libssl.so.6 => /usr/lib/libssl.so.6 (0x33cab000) > > This stunnel was build with OpenSSL from base. > > > kind regards Dirk > > - Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany > - [dirk.meyer@dinoex.sub.org],[dirk.meyer@guug.de],[dinoex@FreeBSD.org] > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > From owner-freebsd-ports@FreeBSD.ORG Fri Mar 20 18:43:44 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4AF3ED8 for ; Fri, 20 Mar 2015 18:43:44 +0000 (UTC) Received: from biertje.skysmurf.nl (unknown [IPv6:2001:984:78b5:1:21b:78ff:fea8:3f22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5E77A7B8 for ; Fri, 20 Mar 2015 18:43:44 +0000 (UTC) Received: from biertje.skysmurf.nl (localhost [127.0.0.1]) by biertje.skysmurf.nl (8.14.9/8.14.9) with ESMTP id t2KIhcnB092378; Fri, 20 Mar 2015 19:43:38 +0100 (CET) (envelope-from fonz@biertje.skysmurf.nl) Received: (from fonz@localhost) by biertje.skysmurf.nl (8.14.9/8.14.9/Submit) id t2KIhaH1092377; Fri, 20 Mar 2015 19:43:36 +0100 (CET) (envelope-from fonz) Date: Fri, 20 Mar 2015 19:43:36 +0100 From: "A.J. \"Fonz\" van Werven" To: Chris H Subject: Re: [HEADSUP] WIP on fonts Message-ID: <20150320184336.GA92357@biertje.skysmurf.nl> References: <20150320153711.GB87678@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 18:43:44 -0000 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Chris H wrote: > P.S. Thanks for doing this. Consistency is nice! :) Seconded. It has already been bugging me somewhat (not enough to complain, but still) that different font ports are/were doing the exact same things differently. Also, kudos for making the announcement so maintainers of font ports know what's going on with "their" ports. AvW --=20 I'm not completely useless, I can be used as a bad example. --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVDGpXAAoJEAfP7gJTaCe8nFkQAMKfdtf67fh7TcSYol7/mxqs M0dPKEW9DvY6aEI1VvWH6ZBAF9GS6OLdxYzseYE4ZdZxpZrOV+0Fv0nB8Yat+JpE E2/ulQ9vtTqhz5cAAi48EqFCb+EREGUrQkGLggz2nWRMzWX3tFp5CRBA5P+hrIbc NZG+4/qpZdPlSqqhDM2KZPg66cuAWBju58iETxhqWxOPNxQvs0d9EmlrWjO8d+AV wirUyIPf7vcJSnanKn1YtbbH/d8I8/PFNEf9NBo+cI2Q+elGba59G0XpxPhxTeHm VSNmwSzntX+1Jq5y0uK6daH5TN3cIZEGYyFgsi2XyC5DA3glPfuyCBrR+Qamrh51 e7Q1jZ86UIJpGb8aJxX9lreH8C9G99ZIEZJ/eo1Q+nX0rWi6dkLuCrqrVBMPDKLx BYkxXarO19fgqkhB6T47T/ajUw14wKVxfvbaB3XkEWcTOgdl1++0IJpZLEf0nK2G iudmVm5iyxbxoAuhMh7s5d8U2ahjtfmYfYwN0xWRHX+M460eWPZx2wGNQ7pQyNns 0o7lByjzg6PgaQuiVJ3Gb9mQA18er5GSaUyi/ELYk/hmKzoHpIADTBt7RWj2Rp/y fnzIPHZVy1uBn+IGpiGVLTwz1IISBwk1k5lBHYBSNWPKqyoR90pMAmIVlzs3srBu oQuq1kXVb7JLf4nqAAzM =/1zz -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- From owner-freebsd-ports@FreeBSD.ORG Fri Mar 20 19:55:41 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 117D8EA3 for ; Fri, 20 Mar 2015 19:55:41 +0000 (UTC) Received: from luigi.brtsvcs.net (luigi.brtsvcs.net [IPv6:2607:fc50:1000:1f00::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E054713B for ; Fri, 20 Mar 2015 19:55:40 +0000 (UTC) Received: from chombo.houseloki.net (c-71-59-211-166.hsd1.or.comcast.net [71.59.211.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by luigi.brtsvcs.net (Postfix) with ESMTPSA id B18E92D4F8E; Fri, 20 Mar 2015 19:55:32 +0000 (UTC) Received: from [IPv6:2601:7:2580:181:baca:3aff:fe83:bd29] (unknown [IPv6:2601:7:2580:181:baca:3aff:fe83:bd29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by chombo.houseloki.net (Postfix) with ESMTPSA id 44E4E8A4; Fri, 20 Mar 2015 12:55:30 -0700 (PDT) Message-ID: <550C7B27.6050604@bluerosetech.com> Date: Fri, 20 Mar 2015 12:55:19 -0700 From: list_freebsd@bluerosetech.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Dirk Meyer , freebsd-ports@freebsd.org Subject: Re: Is it possibly to detect which OpenSSL is used for a port? References: <082281810b1723c5b47aaf826998ea37.squirrel@www.cyberbotx.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 19:55:41 -0000 On 2015-03-20 09:51, Dirk Meyer wrote: > We look for libssl .... > > $ ldd /usr/local/libexec/dovecot/imap-login | grep libssl.so > libssl.so.6 => /usr/lib/libssl.so.6 (0x33cb7000) > > This dovecot was build with the openssl-port. That output shows it's linked to the in-base OpenSSL. From owner-freebsd-ports@FreeBSD.ORG Fri Mar 20 19:58:21 2015 Return-Path: Delivered-To: freebsd-ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62539F7A for ; Fri, 20 Mar 2015 19:58:21 +0000 (UTC) Received: from luigi.brtsvcs.net (luigi.brtsvcs.net [IPv6:2607:fc50:1000:1f00::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3DC66166 for ; Fri, 20 Mar 2015 19:58:21 +0000 (UTC) Received: from chombo.houseloki.net (c-71-59-211-166.hsd1.or.comcast.net [71.59.211.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by luigi.brtsvcs.net (Postfix) with ESMTPSA id A1F7D2D4F8D; Fri, 20 Mar 2015 19:58:20 +0000 (UTC) Received: from [IPv6:2601:7:2580:181:baca:3aff:fe83:bd29] (unknown [IPv6:2601:7:2580:181:baca:3aff:fe83:bd29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by chombo.houseloki.net (Postfix) with ESMTPSA id 890E88A7; Fri, 20 Mar 2015 12:58:19 -0700 (PDT) Message-ID: <550C7BD1.30005@bluerosetech.com> Date: Fri, 20 Mar 2015 12:58:09 -0700 From: list_freebsd@bluerosetech.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Naram Qashat , freebsd-ports@FreeBSD.org Subject: Re: Is it possibly to detect which OpenSSL is used for a port? References: <1b89602a13f212214de4f70feaf3f11e.squirrel@www.cyberbotx.com> In-Reply-To: <1b89602a13f212214de4f70feaf3f11e.squirrel@www.cyberbotx.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 19:58:21 -0000 On 2015-03-20 11:02, Naram Qashat wrote: > This isn't quite what I'm looking for. I want to be able to tell within a > port's Makefile if the user wanted the base or ports OpenSSL to be used. > I've been trying to port TDE to FreeBSD, and tdelibs uses pkg-config to > check for OpenSSL. This would work if the only form of OpenSSL was in > ports, but the base OpenSSL doesn't have a pkg-config file to use, so I > need to know which is going to be used so I can determine when this > pkg-config check can be removed. `grep WITH_OPENSSL_ Makefile` If the port expresses an opinion about which OpenSSL to use, it has to use WITH_OPENSSL_PORT or WITH_OPENSSL_BASE. From owner-freebsd-ports@FreeBSD.ORG Fri Mar 20 20:11:55 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3ACF36CB for ; Fri, 20 Mar 2015 20:11:55 +0000 (UTC) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E8E63399 for ; Fri, 20 Mar 2015 20:11:54 +0000 (UTC) Received: by qgez102 with SMTP id z102so13550728qge.3 for ; Fri, 20 Mar 2015 13:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=TAnQVLO9Uaaiw06uf4eeX+BxhmzvavodRFT76TqeXAo=; b=eVKEgbBwi8JIP6gfR0JnhewBZ7oMI5j/xB9QNILxXSYGocbK8pbNrTvFmpgViEkSgL 3sOOCRvX0XGfi/eLioul2zy9krK00YytKSnEzHz0AiB4LK1KAuL7EpEs0JVh9vhEn3Jm GV+R/sG9HzSq2822u5gY8RskRCx3WK2SMzE7xg4+bx7bIm5Gs6eDn9YpeTsZ1Uw1m8gk toxT9DPLL5/hlENBYkH4V/5AFDvod8Zjqk3MklL5NSYZ6eC1TUS0CtYFg3pzbIM1davb 3ZBpPtV3Fl0DZw90vR/L++iMnMIFY+MaZrmiiKoLge58UEvr2wcid9s15cFsJQfutGzI L5lw== X-Received: by 10.140.152.10 with SMTP id 10mr76571906qhy.40.1426882313520; Fri, 20 Mar 2015 13:11:53 -0700 (PDT) MIME-Version: 1.0 From: Henry Hu Date: Fri, 20 Mar 2015 20:11:50 +0000 Message-ID: Subject: Depending on port flag? To: "freebsd-ports@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 20:11:55 -0000 Recently, I tried to use mpv with VAAPI. The default mpv port does not enable VAAPI, so I enabled and installed it from ports. However, mpv still can't use VAAPI. After some investigation, it turns out that it depends on ffmpeg with VAAPI enabled, and the default ffmpeg also has it disabled. After rebuilding ffmpeg with VAAPI, it works. So if mpv's VAAPI flag is enabled, it should depend on ffmpeg's VAAPI flag. Is there a formal method to depend on another port's flag currently? There are hackish method like "depend on this file which is only installed when that flag is enabled", but there should be a better method. From owner-freebsd-ports@FreeBSD.ORG Fri Mar 20 21:17:37 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24B51BE for ; Fri, 20 Mar 2015 21:17:37 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B63FFD29 for ; Fri, 20 Mar 2015 21:17:35 +0000 (UTC) Received: (qmail 4946 invoked from network); 20 Mar 2015 21:17:29 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 20 Mar 2015 21:17:29 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Fri, 20 Mar 2015 17:17:29 -0400 (EDT) Received: (qmail 10081 invoked from network); 20 Mar 2015 21:17:28 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 20 Mar 2015 21:17:28 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id CB0301C43AE; Fri, 20 Mar 2015 14:17:23 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc64 11.0-CURRENT CROSS_TOOLSCHAIN=powerpc64-gcc: -pg compile gets ../libcxxrt/terminate.cc:36:7: internal compiler error: Segmentation fault Date: Fri, 20 Mar 2015 14:17:26 -0700 Message-Id: To: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-ports@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 21:17:37 -0000 It turns out that I had to rebuild powerpc64-gcc after booting into the = powerpc64-gcc based installed world (and kernel). The below notes start = from before that rebuild of powerpc64-gcc. Basic context (more detail later): > # dmesg | head > ... > FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 18 20:11:15 PDT 2015 > root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc > gcc version 4.9.1 (FreeBSD Ports Collection for powerpc64)=20 > ... (So this is was bootstrapped via a buildworld buildkernel with = CROSS_TOOLSCHAIN=3Dpowerpc64-gcc involved.) > # freebsd-version -ku; uname -apKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed = Mar 18 20:11:15 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100062 1100062 WITHOUT_BOOT=3D and WITHOUT=3DLIB32=3D were used for the above build. Also WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D . And WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D = WITHOUT_LLDB=3D . > # more /etc/src.conf > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > WITH_LIBCPLUSPLUS=3D > # CXXFLAGS For buildworld/buildkernel CROSS_TOOLCHAIN=3Dpowerpc64-gcc = use... > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 -std=3Dgnu+=3D11 = -L/usr/obj/usr/srcC/lib/libc++ > NO_WERROR=3D The active build with the compiler crash was working on: > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ > WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ > WITHOUT_LLDB=3D \ > WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITHOUT_GNUCXX=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 in the above context. But it turns out that I can show the problem in a = much quicker form then waiting for the rebuild to get to that point. The problem: For the quicker form of test: having done buildworld buildkernel from = the gcc 4.2.1 based powerpc64 SSD but using powerpc64-gcc via = CROSS_TOOLCHAIN=3Dpowerpc64-gcc (much like the above)... installworld (and installkernel) to another SSD that is effectively = initially a copy of the gcc 4.2.1 based one with the powerpc64-gcc = present. Then reboot into that newer SSD. Using the above /etc/src.conf = then try something like: > mkdir -p /tmp/lib \ > && mkdir -p /tmp/usr/lib \ > && mkdir -p /tmp/usr/srcC/lib/libcxxrt \ > && cd /usr/srcC/lib/libcxxrt/ \ > && MAKEOBJDIRPREFIX=3D/tmp \ > make CROSS_TOOLCHAIN=3Dpowerpc64-gcc DIRPRFX=3Dlib/libcxxrt/ = DESTDIR=3D/tmp obj depend all install The point being to get the involved .cc files to be compiled in the = normal way, including in the form that uses -pg. This which works fine on the original SSD (given that SSD's = /etc/src.conf that uses = CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 and = LDADD+=3D-L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ ). The result for -pg for contrib/libcxxrt/terminate.cc on the gcc 4.9.1 = based SSD was consistently: > /usr/srcC/lib/libcxxrt/../../contrib/libcxxrt/terminate.cc: In = function 'void std::terminate()': > /usr/srcC/lib/libcxxrt/../../contrib/libcxxrt/terminate.cc:36:7: = internal compiler error: Segmentation fault > void terminate() > ^ > no stack trace because unwind library not available > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > *** [terminate.po] Error code 1 >=20 > make[4]: stopped in /usr/srcC/lib/libcxxrt > 1 error >=20 > make[4]: stopped in /usr/srcC/lib/libcxxrt > *** [all_subdir_libcxxrt] Error code 2 Rebuilding powerpc64-gcc from the booted powerpc64-gcc based SSD (in my = case via gcc5 use and portmaster) and trying again shows that the = rebuild has removed the above crash status for -pg use. (Until the powerpc64-gcc port avoids failing for file name/placement = problems when used on powerpc64's, having powerpc64-gcc rebuild itself = in such a context is a no-go: It fails between removing itself and = putting back the newer materials. That does not leave enough materials = around for a portmaster with -C to continue after a hand adjusted group = of file names/placements.) There appears to be some form of binary incompatibility for -pg that = requires the powerpc64-gcc rebuild to get the new binary context right. = Once it matches it seems fine. Context details, mostly applying to both gcc 4.2.1 based world/kernel = with powperpc-gcc in use for cross compiling and gcc 4.9.1 based = world/kernel: powerpc64-gcc automatically looks in /usr/local/include for header files = (like most such ports) and this can pick up the wrong file(s). I ended = up renaming /usr/local/include/iconv.h so that it would not be found and used where a file with different = content from my /usr/srcC/... was needed. In my experiments at times for the 4.9.1 based live-world I've placed = the following symbolic links: > # ls -FPal /usr/lib/libstdc* > lrwxr-xr-x 1 root wheel 8 Mar 19 03:47 /usr/lib/libstdc++.a@ -> = libc++.a > lrwxr-xr-x 1 root wheel 9 Mar 19 03:47 /usr/lib/libstdc++.so@ -> = libc++.so >=20 > # ls -FPal /usr/bin/gcc /usr/bin/g++ > lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/g++@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/gcc@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc For example csu/powerpc64/... uses "gcc" directly, ignoring XCC and CC. The CC, CXX, and CPP in... > # more /etc/src.conf > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > ... that essentially duplicate the XCC, XCXX, XCPP assignments from = CROSS_TOOLCHAIN=3Dpowerpc64-gcc are there because otherwise various = stages do not use the cross tools (legacy, bootstrap-tools, build-tools, = cross-tools, kernel-tools, lib32's build-tools). In the running world built-via-powerpc64-gcc environment /etc/src.conf = having ... > # CXXFLAGS For buildworld/buildkernel CROSS_TOOLCHAIN=3Dpowerpc64-gcc = use... > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 -std=3Dgnu+=3D11 = -L/usr/obj/usr/srcC/lib/libc++ is used because otherwise (for example)... > /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -fpic -DPIC -O2 = -pipe -DHAVE_CONFIG_H -I/usr/srcC/contrib/atf = -I/usr/srcC/lib/atf/libatf-c++/../libatf-c -I. -DHAVE_CONFIG_H = -fstack-protector -Wsyste > m-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter = -Wpointer-arith -Wno-uninitialized -c = /usr/srcC/contrib/atf/atf-c++/detail/application.cpp -o application.So ends up with... > In file included from = /usr/srcC/contrib/atf/atf-c++/detail/application.cpp:26:0: > /usr/srcC/contrib/atf/atf-c++/detail/application.hpp:29:19: fatal = error: ostream: No such file or directory > #include > ^ > compilation terminated. from lack of -I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 in CXXFLAGS and = the like. This is despite the /usr/srcC/Makefile.inc1 logic (that ends = up inactive for some reason): > .if ${XCC:M/*} > ... > .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} =3D=3D gcc > XCFLAGS+=3D -isystem ${WORLDTMP}/usr/include = -L${WORLDTMP}/usr/lib > XCXXFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 -std=3Dgnu++11 = -L${WORLDTMP}/../lib/libc++ > DEPFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 As for /etc/make.conf it looks like... > # more /etc/make.conf > #CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > #CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > #CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > #CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > #X_COMPILER_TYPE=3Dgcc > # CXFLAGS For normal powerpc64-gcc use... > # AVOID during buildworld/buildkernel activity. > # See /etc/src.conf for example buildworld/buildkernel values. > #CXXFLAGS+=3D-I/usr/include/c++/v1 -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++ > # > #CC=3D/usr/local/bin/gcc5 > #CXX=3D/usr/local/bin/g++5 > #CPP=3D/usr/local/bin/cpp5 > #CC=3D/usr/local/bin/clang36 > #CXX=3D/usr/local/bin/clang++36 > #CPP=3D/usr/local/bin/clang-cpp36 > WRKDIRPREFIX=3D/usr/obj/portswork > #WITH_DEBUG=3D > MALLOC_PRODUCTION=3D (Some of the comments show how gcc5/g++5 use was temporarily forced = while rebuilding powerpc64-gcc.) > # svnlite info /usr/srcC/ > Path: /usr/srcC > Working Copy Root Path: /usr/srcC > URL: https://svn0.us-west.freebsd.org/base/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 279514 > Node Kind: directory > Schedule: normal > Last Changed Author: adrian > Last Changed Rev: 279514 > Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) > # svnlite status /usr/srcC/ --no-ignore > ? /usr/srcC/.snap > M /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h > ? /usr/srcC/restoresymtable > M /usr/srcC/sys/ddb/db_main.c > M /usr/srcC/sys/ddb/db_script.c > ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc > ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc-NODEBUG > ? /usr/srcC/sys/powerpc/conf/GENERICvtsc > ? /usr/srcC/sys/powerpc/conf/GENERICvtsc-NODEBUG > M /usr/srcC/sys/powerpc/ofw/ofw_machdep.c > M /usr/srcC/sys/powerpc/ofw/ofwcall64.S IntrusiveRefCntPtr.h does not matter if clang building is not involved. = It needed a friend declaration to gain access to a private field, = otherwise compilation stopped. And the rest existed in my environment before I started this = powerpc64-xtoolchain-gcc exploration. lib/libnv/test/dnv_tests.cc and lib/libnv/test/nv_tests.cc are from = later (-r279760) than the rest of the unmodified source code. This is in = order to remove ambiguous overload issues. > # svnlite info /usr/ports > Path: /usr/ports > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 381120 > Node Kind: directory > Schedule: normal > Last Changed Author: dbn > Last Changed Rev: 381120 > Last Changed Date: 2015-03-12 10:13:39 -0700 (Thu, 12 Mar 2015) I have gcc5 and clang36 ports installed. I made no use of clang36. On a powerpc64 11.0-CURRENT powerpc64-xtoolchain-gcc fails to complete = its installation because powerpc64-gcc fails to complete its = installation. The problems were 4 mismatched file names and one file = also not put into staging. I copied appropriate files to the missing = names and place and from that status the installation was able to = continue and complete via postmaster with -C (as long as powerpc64-gcc = was not in use rebuilding itself: some other compiler was in use for = that activity instead). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ports@FreeBSD.ORG Fri Mar 20 21:49:22 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4DD5A5C6 for ; Fri, 20 Mar 2015 21:49:22 +0000 (UTC) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 11DCA79 for ; Fri, 20 Mar 2015 21:49:21 +0000 (UTC) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-05v.sys.comcast.net with comcast id 5xoz1q0082JGN3p01xpKSF; Fri, 20 Mar 2015 21:49:19 +0000 Received: from www.cyberbotx.com ([107.5.48.95]) by resomta-ch2-10v.sys.comcast.net with comcast id 5xpH1q00Q23DSHF01xpHQB; Fri, 20 Mar 2015 21:49:19 +0000 Received: from 192.168.2.2 (SquirrelMail authenticated user cyberbotx) by www.cyberbotx.com with HTTP; Fri, 20 Mar 2015 17:49:19 -0400 Message-ID: <600c966bf3ee8136f77b03fb39abcc95.squirrel@www.cyberbotx.com> In-Reply-To: <550C7BD1.30005@bluerosetech.com> References: <1b89602a13f212214de4f70feaf3f11e.squirrel@www.cyberbotx.com> <550C7BD1.30005@bluerosetech.com> Date: Fri, 20 Mar 2015 17:49:19 -0400 Subject: Re: Is it possibly to detect which OpenSSL is used for a port? From: "Naram Qashat" To: list_freebsd@bluerosetech.com User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1426888159; bh=81YoaFfmrQ8TPSasVcU6+BRP7ZkPJKJ8zWcW9jiq8Hc=; h=Received:Received:Received:Message-ID:Date:Subject:From:To: MIME-Version:Content-Type; b=YyrTX0P1Dc+BLVuG4lhRK3jq0I3+eXQgkWkapL5Eb2vLjcxtbTSrbnPvzNexD4TfU xewcnUQR/MletumMjmBMqzMXPat51PKFbRWQaJr65ax2FBQugHJUmRfkjeymHXbpXD GGFJGEUDt6BEVFs83pBNvkU3R7X7No6bhKG2sHeS3YpDpp8cAD2y9PE3pL0CD7p95/ T4jY14LS+//EyBOK8jeJkRSWiczXrICedUd/yyoEKUeOv/RaY5t/jWaKKTJzB0aAk7 HVBc0KXziL7TogeuZSvqpSRshvyFQe1NmoDfRtcjaImfD6dF5P6MjbCwDRRgnEDRUH HrcHgjuW4uJLA== Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 21:49:22 -0000 I've looked at bsd.openssl.mk and from what it says, those WITH_OPENSSL_* knobs are use-set, not port-set. So that doesn't help me. > On 2015-03-20 11:02, Naram Qashat wrote: >> This isn't quite what I'm looking for. I want to be able to tell within >> a >> port's Makefile if the user wanted the base or ports OpenSSL to be used. >> I've been trying to port TDE to FreeBSD, and tdelibs uses pkg-config to >> check for OpenSSL. This would work if the only form of OpenSSL was in >> ports, but the base OpenSSL doesn't have a pkg-config file to use, so I >> need to know which is going to be used so I can determine when this >> pkg-config check can be removed. > > `grep WITH_OPENSSL_ Makefile` > > If the port expresses an opinion about which OpenSSL to use, it has to > use WITH_OPENSSL_PORT or WITH_OPENSSL_BASE. > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > From owner-freebsd-ports@FreeBSD.ORG Fri Mar 20 23:27:35 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ACBBDA8D for ; Fri, 20 Mar 2015 23:27:35 +0000 (UTC) Received: from luigi.brtsvcs.net (luigi.brtsvcs.net [204.109.60.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 84C28C94 for ; Fri, 20 Mar 2015 23:27:35 +0000 (UTC) Received: from chombo.houseloki.net (c-71-59-211-166.hsd1.or.comcast.net [71.59.211.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by luigi.brtsvcs.net (Postfix) with ESMTPSA id CCD572D4F8D; Fri, 20 Mar 2015 23:27:33 +0000 (UTC) Received: from [IPv6:2601:7:2580:181:baca:3aff:fe83:bd29] (unknown [IPv6:2601:7:2580:181:baca:3aff:fe83:bd29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by chombo.houseloki.net (Postfix) with ESMTPSA id 838FC8D7; Fri, 20 Mar 2015 16:27:31 -0700 (PDT) Message-ID: <550CACD8.5010604@bluerosetech.com> Date: Fri, 20 Mar 2015 16:27:20 -0700 From: list_freebsd@bluerosetech.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Naram Qashat Subject: Re: Is it possibly to detect which OpenSSL is used for a port? References: <1b89602a13f212214de4f70feaf3f11e.squirrel@www.cyberbotx.com> <550C7BD1.30005@bluerosetech.com> <600c966bf3ee8136f77b03fb39abcc95.squirrel@www.cyberbotx.com> In-Reply-To: <600c966bf3ee8136f77b03fb39abcc95.squirrel@www.cyberbotx.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 23:27:35 -0000 On 2015-03-20 14:49, Naram Qashat wrote: > I've looked at bsd.openssl.mk and from what it says, those WITH_OPENSSL_* > knobs are use-set, not port-set. So that doesn't help me. I'm not sure what you read, but lines 5 through 10 of ports/Mk/bsd.openssl.mk are: # Use of 'USE_OPENSSL=yes' includes this Makefile after bsd.ports.pre.mk # # the user/port can now set this options in the makefiles. # # WITH_OPENSSL_BASE=yes - Use the version in the base system. # WITH_OPENSSL_PORT=yes - Use the OpenSSL port, even if base is up to date I can confirm that setting or testing those variables is how you modify the OpenSSL linking behaviour of a port. There's currently 51 ports that do so. Off hand, an example is www/nginx-devel. It can't use OpenSSL 0.9.8 if you enable SPDY, so it sets WITH_OPENSSL_PORT=yes if OSVERSION < 1000028. >> On 2015-03-20 11:02, Naram Qashat wrote: >>> This isn't quite what I'm looking for. I want to be able to tell within >>> a >>> port's Makefile if the user wanted the base or ports OpenSSL to be used. >>> I've been trying to port TDE to FreeBSD, and tdelibs uses pkg-config to >>> check for OpenSSL. This would work if the only form of OpenSSL was in >>> ports, but the base OpenSSL doesn't have a pkg-config file to use, so I >>> need to know which is going to be used so I can determine when this >>> pkg-config check can be removed. >> >> `grep WITH_OPENSSL_ Makefile` >> >> If the port expresses an opinion about which OpenSSL to use, it has to >> use WITH_OPENSSL_PORT or WITH_OPENSSL_BASE. >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> >> > > > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 00:34:18 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9460C98 for ; Sat, 21 Mar 2015 00:34:18 +0000 (UTC) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by mx1.freebsd.org (Postfix) with ESMTP id 527A13D6 for ; Sat, 21 Mar 2015 00:34:17 +0000 (UTC) Received: from ppp118-210-45-229.lns20.adl2.internode.on.net (HELO leader.local) ([118.210.45.229]) by ipmail06.adl2.internode.on.net with ESMTP; 21 Mar 2015 11:04:09 +1030 Message-ID: <550CBC80.5020607@ShaneWare.Biz> Date: Sat, 21 Mar 2015 11:04:08 +1030 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Naram Qashat , freebsd-ports@FreeBSD.org Subject: Re: Is it possibly to detect which OpenSSL is used for a port? References: <1b89602a13f212214de4f70feaf3f11e.squirrel@www.cyberbotx.com> In-Reply-To: <1b89602a13f212214de4f70feaf3f11e.squirrel@www.cyberbotx.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 00:34:18 -0000 On 21/03/2015 04:32, Naram Qashat wrote: > This isn't quite what I'm looking for. I want to be able to tell within a > port's Makefile if the user wanted the base or ports OpenSSL to be used. > I've been trying to port TDE to FreeBSD, and tdelibs uses pkg-config to > check for OpenSSL. This would work if the only form of OpenSSL was in > ports, but the base OpenSSL doesn't have a pkg-config file to use, so I > need to know which is going to be used so I can determine when this > pkg-config check can be removed. I created a new port devel/godot not long ago, it used pkg-config to find openssl so I set it to use openssl port as it was a quick easy fix till I got around to finding a better solution. I was then offered a patch to fix this, which removed a test whether "pkg config openssl" failed and changed 'pkg-config openssl --cflags --libs' to 'echo -lssl -lcrypto' https://svnweb.freebsd.org/ports/head/devel/godot/files/patch-platform_x11_detect.py?r1=377975&r2=380508 Having USE_OPENSSL=yes in your Makefile leads to LDFLAGS getting -rpath set to the location of the ssl libs. Therefore adding -lssl -lcrypto instead of the pkg-config response leads to finding the ssl libs based on the ssl option set at build time. Worst case you may need to re-order the LDFLAGS so that other "-L/path" entries are placed after the ssl search paths. If you still need tests then try testing ${OPENSSLBASE} == '/usr' # The makefile sets this variables: # OPENSSLBASE - "/usr" or ${LOCALBASE} # OPENSSLDIR - path to openssl # OPENSSLLIB - path to the libs # OPENSSLINC - path to the matching includes # OPENSSLRPATH - rpath for dynamic linker -- FreeBSD - the place to B...Software Developing Shane Ambler From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 01:04:57 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B21F285F for ; Sat, 21 Mar 2015 01:04:57 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 65BFD91C for ; Sat, 21 Mar 2015 01:04:56 +0000 (UTC) Received: (qmail 19555 invoked from network); 21 Mar 2015 01:04:55 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 21 Mar 2015 01:04:55 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Fri, 20 Mar 2015 21:04:55 -0400 (EDT) Received: (qmail 8956 invoked from network); 21 Mar 2015 01:04:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Mar 2015 01:04:55 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 4D7FF1C439E; Fri, 20 Mar 2015 18:04:49 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc64 11.0-CURRENT CROSS_TOOLSCHAIN=powerpc64-gcc when building with WITH_CLANG= defined: include/c++/v1/ problems... Date: Fri, 20 Mar 2015 18:04:53 -0700 Message-Id: To: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-ports@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 01:04:57 -0000 CROSS_TOOLCHAIN=3Dpowerpc64-gcc will not automatically use = /usr/include/c++/v1/ paths or /usr/lib/ paths. And those paths are only = appropriate sometimes. Other times paths such as = /usr/obj/usr/srcC/tmp/usr/include/c++/v1 and = /usr/obj/usr/srcC/lib/libc++ are appropriate.=20 The later material concludes that = _bootstrap-tools-lib/clang/libllvmtablegen and the like do not have a = well controlled c++ header/library(?) environment for = CROSS_TOOLCHAIN=3D... use. /etc/src.conf lines such as: > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++/. are a problem in general. So far I've not found a good hook for making = the distinctions for CROSS_TOOLSCHAIN=3Dpowerpc64-gcc : > # Actually only appropriate for for _includes _libraries _depend = everything build32 : > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++/.=20 > # > # Actually only appropriate for for _worldtmp _legacy _bootstrap-tools = _cleanobj _obj _build-tools _cross-tools : > CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. > # > # But for self-hosting in a CROSS_TOOLSCHAIN=3D... like manor = sometimes having both can work. Note: My context happens to be self-hosting: powerpc64 using = CROSS_TOOLCHAIN=3Dpowerpc64-gcc. I've taken advantage of that status in = the details of what I've done but I do not know what I'd do in a true = non-self-hosting context. Even for WITHOUT_CLANG=3D I've used > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++/.=20 in /etc/src.conf because, for example, without it atf-c++ ended up = with... > In file included from = /usr/srcC/contrib/atf/atf-c++/detail/application.cpp:26:0: > /usr/srcC/contrib/atf/atf-c++/detail/application.hpp:29:19: fatal = error: ostream: No such file or directory > #include > ^ > compilation terminated. This without-ostream case was despite the /usr/srcC/Makefile.inc1 logic = (that ends up inactive/ineffective for some reason at the time): > .if ${XCC:M/*} > ... > .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} =3D=3D gcc > XCFLAGS+=3D -isystem ${WORLDTMP}/usr/include = -L${WORLDTMP}/usr/lib > XCXXFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 -std=3Dgnu++11 = -L${WORLDTMP}/../lib/libc++ > DEPFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 Basic context (more detail later): > # dmesg | head > ... > FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 18 20:11:15 PDT 2015 > root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc > gcc version 4.9.1 (FreeBSD Ports Collection for powerpc64)=20 > ... (So this is was bootstrapped via a buildworld buildkernel with = CROSS_TOOLSCHAIN=3Dpowerpc64-gcc involved.) > # freebsd-version -ku; uname -apKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed = Mar 18 20:11:15 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100062 1100062 WITHOUT_BOOT=3D and WITHOUT=3DLIB32=3D were used for the above build. Also WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D . And WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D = WITHOUT_LLDB=3D . > # more /etc/src.conf > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > WITH_LIBCPLUSPLUS=3D > # > # CXXFLAGS For buildworld/buildkernel CROSS_TOOLCHAIN=3Dpowerpc64-gcc = use... > # spans being-built and (failing finding those directories) live and = so for > # -DNO_CLEAN after being-built ones are in place depends on = self-hodsting > # where the two are sufficient compatibile. > # > # I've used .../. paths so I can tell use of these from other sources = of paths. > # > # Actually only appropriate for for _includes _libraries _depend = everything build32 : > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++/.=20 > # > # Actually only appropriate for for _worldtmp _legacy _bootstrap-tools = _cleanobj _obj _build-tools _cross-tools : > #CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. > # > # But for self-hosting in a cross-tools like manor sometimes having = both can work. > # > NO_WERROR=3D was used as context for: > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ > WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D \ > WITH_LLDB=3D \ > WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITHOUT_GNUCXX=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 The problem: Without the /etc/src.conf line (or equivalent): > CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. when I turned on WITH_CLANG=3D (see above) in order to try to build = clang during buildworld it got... > --- _bootstrap-tools-lib/clang/libllvmtablegen --- > CC=3D'/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc ' mkdep -f = .depend -a = -I/usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/include = -I/usr/srcC/lib/clang/libllvmtablegen/../../../contrib > /llvm/tools/clang/include = -I/usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen = -I. = -I/usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/../../lib/clan= g/include -DLLVM_ON_UNI > X -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"powerpc64-unknown-freebsd11.0\" = -DLLVM_HOST_TRIPLE=3D\"powerpc64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT > =3D\"\" -I/usr/obj/usr/srcC/tmp/legacy/usr/include = -I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 -std=3Dc++11 = = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Err= or.c > pp = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Mai= n.cpp = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Rec= ord.cpp /usr/srcC/lib/clang/libllvmtablegen > /../../../contrib/llvm/lib/TableGen/SetTheory.cpp = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Str= ingMatcher.cpp = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib > /TableGen/TableGenBackend.cpp = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TGL= exer.cpp = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TGP= arser.cpp=20 > In file included from = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/include/llvm/ADT= /SmallVector.h:17:0, > from = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/include/llvm/ADT= /ArrayRef.h:14, > from = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/include/llvm/Sup= port/SourceMgr.h:19, > from = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/include/llvm/Tab= leGen/Error.h:18, > from = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Err= or.cpp:15: > = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/include/llvm/ADT= /iterator_range.h:22:19: fatal error: utility: No such file or directory > #include > ^ > compilation terminated. Removing > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu+=3D1= 1 -L/usr/obj/usr/srcC/lib/libc++/. from /etc/src.conf does not make the c++11 headers available at that = time. Only adding something like: > CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. did. (Luckily for what I'd doing having both CXXFLAGS+=3D... works out = okay.) I did not notice anything that suggested an intended way to deal with = the two contexts for CROSS_TOOLCHAIN=3Dpowerpc64-gcc use. Context details, mostly applying to both gcc 4.2.1 based world/kernel = with powperpc-gcc in use for cross compiling and gcc 4.9.1 based = world/kernel: powerpc64-gcc automatically looks in /usr/local/include for header files = (like most such ports) and this can pick up the wrong file(s). I ended = up renaming /usr/local/include/iconv.h so that it would not be found and used where a file with different = content from my /usr/srcC/... was needed. CROSS_TOOLCHAIN=3Dpowerpc64-gcc use does not allow -melf32ppc_fbsd for = WITH_BOOT=3D and WITH_LIB32=3D build activity to use. Even if there was = a powerpc-xtoolchain-gcc (and powerpc-gcc) around then selectively doing = just the WITH_BOOT=3D and WITH_LIB32=3D would still not seem a natural = fit. In my experiments at times for the 4.9.1 based live-world I've placed = the following symbolic links: > # ls -FPal /usr/lib/libstdc* > lrwxr-xr-x 1 root wheel 8 Mar 19 03:47 /usr/lib/libstdc++.a@ -> = libc++.a > lrwxr-xr-x 1 root wheel 9 Mar 19 03:47 /usr/lib/libstdc++.so@ -> = libc++.so >=20 > # ls -FPal /usr/bin/gcc /usr/bin/g++ > lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/g++@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/gcc@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc For example csu/powerpc64/... uses "gcc" directly, ignoring XCC and CC. The CC, CXX, and CPP in... > # more /etc/src.conf > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > ... that essentially duplicate the XCC, XCXX, XCPP assignments from = CROSS_TOOLCHAIN=3Dpowerpc64-gcc are there because otherwise various = stages do not use the cross tools (legacy, bootstrap-tools, build-tools, = cross-tools, kernel-tools, lib32's build-tools). Originally I was = investigating how far I could get without involving gcc 4.2.1 and what = would be involved. In the running world built-via-powerpc64-gcc environment /etc/src.conf = having ... > # CXXFLAGS For buildworld/buildkernel CROSS_TOOLCHAIN=3Dpowerpc64-gcc = use... > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu+=3D1= 1 -L/usr/obj/usr/srcC/lib/libc++/. is used because otherwise (for example)... > /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -fpic -DPIC -O2 = -pipe -DHAVE_CONFIG_H -I/usr/srcC/contrib/atf = -I/usr/srcC/lib/atf/libatf-c++/../libatf-c -I. -DHAVE_CONFIG_H = -fstack-protector -Wsyste > m-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter = -Wpointer-arith -Wno-uninitialized -c = /usr/srcC/contrib/atf/atf-c++/detail/application.cpp -o application.So ends up with... > In file included from = /usr/srcC/contrib/atf/atf-c++/detail/application.cpp:26:0: > /usr/srcC/contrib/atf/atf-c++/detail/application.hpp:29:19: fatal = error: ostream: No such file or directory > #include > ^ > compilation terminated. from lack of -I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. in CXXFLAGS = and the like. This is despite the /usr/srcC/Makefile.inc1 logic (that = ends up inactive/ineffective for some reason): > .if ${XCC:M/*} > ... > .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} =3D=3D gcc > XCFLAGS+=3D -isystem ${WORLDTMP}/usr/include = -L${WORLDTMP}/usr/lib > XCXXFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 -std=3Dgnu++11 = -L${WORLDTMP}/../lib/libc++ > DEPFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 As for /etc/make.conf it looks like... > # more /etc/make.conf > #CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > #CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > #CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > #CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > #X_COMPILER_TYPE=3Dgcc > # CXFLAGS For normal powerpc64-gcc use... > # AVOID during the buildworld/buildkernel activities: > # _includes _libraries _depend everything build32. > # See /etc/src.conf for example buildworld/buildkernel > # values for that context. > #CXXFLAGS+=3D-I/usr/include/c++/v1 -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++ > # > #CC=3D/usr/local/bin/gcc5 > #CXX=3D/usr/local/bin/g++5 > #CPP=3D/usr/local/bin/cpp5 > #CC=3D/usr/local/bin/clang36 > #CXX=3D/usr/local/bin/clang++36 > #CPP=3D/usr/local/bin/clang-cpp36 > WRKDIRPREFIX=3D/usr/obj/portswork > #WITH_DEBUG=3D > MALLOC_PRODUCTION=3D (Some of the comments show how gcc5/g++5 use was temporarily forced = while rebuilding powerpc64-gcc from a booted world that had been built = based on powerpc64-gcc in a gcc 4.2.1 world.) > # svnlite info /usr/srcC/ > Path: /usr/srcC > Working Copy Root Path: /usr/srcC > URL: https://svn0.us-west.freebsd.org/base/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 279514 > Node Kind: directory > Schedule: normal > Last Changed Author: adrian > Last Changed Rev: 279514 > Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) > # svnlite status /usr/srcC/ --no-ignore > ? /usr/srcC/.snap > M /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h > ? /usr/srcC/restoresymtable > M /usr/srcC/sys/ddb/db_main.c > M /usr/srcC/sys/ddb/db_script.c > ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc > ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc-NODEBUG > ? /usr/srcC/sys/powerpc/conf/GENERICvtsc > ? /usr/srcC/sys/powerpc/conf/GENERICvtsc-NODEBUG > M /usr/srcC/sys/powerpc/ofw/ofw_machdep.c > M /usr/srcC/sys/powerpc/ofw/ofwcall64.S IntrusiveRefCntPtr.h does not matter if clang building is not involved. = It needed a friend declaration to gain access to a private field, = otherwise compilation stopped. And the rest existed in my environment before I started this = powerpc64-xtoolchain-gcc exploration. lib/libnv/test/dnv_tests.cc and lib/libnv/test/nv_tests.cc are from = later (-r279760) than the rest of the unmodified source code. This is in = order to remove ambiguous overload issues. > # svnlite info /usr/ports > Path: /usr/ports > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 381120 > Node Kind: directory > Schedule: normal > Last Changed Author: dbn > Last Changed Rev: 381120 > Last Changed Date: 2015-03-12 10:13:39 -0700 (Thu, 12 Mar 2015) I have gcc5 and clang36 ports installed. I've made no use of clang36. On a powerpc64 11.0-CURRENT powerpc64-xtoolchain-gcc fails to complete = its installation because powerpc64-gcc fails to complete its = installation. The problems were 4 mismatched file names and one file = also not put into staging. I copied appropriate files to the missing = names and place and from that status the installation was able to = continue and complete via postmaster with -C (as long as powerpc64-gcc = was not in use rebuilding itself: some other compiler was in use for = that activity instead). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 06:14:42 2015 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 985F57A1 for ; Sat, 21 Mar 2015 06:14:42 +0000 (UTC) Received: from portsindexbuild.ysv.freebsd.org (portsindexbuild.ysv.freebsd.org [IPv6:2001:1900:2254:206a::16:6601]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6D1D9ABE for ; Sat, 21 Mar 2015 06:14:42 +0000 (UTC) Received: from portsindexbuild.ysv.freebsd.org ([127.0.1.2]) by portsindexbuild.ysv.freebsd.org (8.14.9/8.14.9) with ESMTP id t2L6EgU9067295 for ; Sat, 21 Mar 2015 06:14:42 GMT (envelope-from indexbuild@portsindexbuild.ysv.freebsd.org) Received: (from indexbuild@localhost) by portsindexbuild.ysv.freebsd.org (8.14.9/8.14.9/Submit) id t2L6EgR9067294 for ports@FreeBSD.org; Sat, 21 Mar 2015 06:14:42 GMT (envelope-from indexbuild) Date: Sat, 21 Mar 2015 06:14:42 GMT From: Ports Index build Message-Id: <201503210614.t2L6EgR9067294@portsindexbuild.ysv.freebsd.org> To: ports@FreeBSD.org Subject: INDEX build failed for 8.x X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 06:14:42 -0000 INDEX build failed with errors: make: stopped in /home/indexbuild/tindex/ports make: no system rules (sys.mk). Committers on the hook: Most recent SVN update was: Updating '.': At revision 381786. From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 06:27:24 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A488CD1 for ; Sat, 21 Mar 2015 06:27:24 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 037CEBF3 for ; Sat, 21 Mar 2015 06:27:23 +0000 (UTC) Received: (qmail 27325 invoked from network); 21 Mar 2015 06:27:21 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 21 Mar 2015 06:27:21 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sat, 21 Mar 2015 02:27:21 -0400 (EDT) Received: (qmail 22345 invoked from network); 21 Mar 2015 06:27:21 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Mar 2015 06:27:21 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id A99191C439E; Fri, 20 Mar 2015 23:27:13 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: CROSS_TOOLCHAIN=powerpc64-gcc mishandles "Substitution Failure Is Not An Error" when compiling clang and stops the build Date: Fri, 20 Mar 2015 23:27:19 -0700 Message-Id: <52182692-C48C-4438-8AF1-318828E8F966@dsl-only.net> To: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-ports@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 06:27:24 -0000 Basic context: > # dmesg | head > ... > FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 18 20:11:15 PDT 2015 > root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc > gcc version 4.9.1 (FreeBSD Ports Collection for powerpc64)=20 > ... > # freebsd-version -ku; uname -apKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed = Mar 18 20:11:15 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100062 1100062 > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ > WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D \ > WITH_LLDB=3D \ > WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITHOUT_GNUCXX=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 For the context set by: > # more /etc/src.conf > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > WITH_LIBCPLUSPLUS=3D > # > # CXXFLAGS For buildworld/buildkernel CROSS_TOOLCHAIN=3Dpowerpc64-gcc = use... > # spans being-built and (failing finding those directories) live and = so for > # -DNO_CLEAN after being-built ones are in place depends on = self-hodsting > # where the two are sufficient compatibile. > # > # I've used .../. paths so I can tell use of these from other sources = of paths. > # > # Actually only appropriate for for _includes _libraries _depend = everything build32 : > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++/. > # > # Actually only appropriate for for _worldtmp _legacy _bootstrap-tools = _cleanobj _obj _build-tools _cross-tools : > CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. > # > # But for self-hosting in a cross tools like manor sometimes having = both can work. > # > NO_WERROR=3D The problem: (Somewhat reformatted text...) > In file included from /usr/include/c++/v1/./algorithm:625:0, > from = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/= StringRef.h:13, > from = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/= StringMap.h:17, > from = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Supp= ort/SpecialCaseList.h:51, > from = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Speci= alCaseList.cpp:17: > /usr/include/c++/v1/./type_traits: >=20 > In instantiation of 'struct std::__1::__is_convertible&, = llvm::StringMap, 0u, 0u>': > /usr/include/c++/v1/./type_traits:943:62: > required from >=20 > 'struct std::__1::is_convertible&, = llvm::StringMap >' > /usr/include/c++/v1/./utility:269:77: > required by >=20 > substitution of 'template std::__1::pair<_T1, = _T2>::pair(const std::__1::pair<_U1, _U2>&, typename = std::__1::enable_if<(std::__1::is_convertible::value && = std::__1::is_convertible::value)>::type*) [with _U1 =3D = llvm::StringRef; _U2 =3D llvm::StringMap]' > = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/= StringMap.h:371:55: > required from >=20 > 'llvm::StringMap::MapEntryTy& = llvm::StringMap::GetOrCreateValue(llvm::StringRef, = InitTy) [with InitTy =3D llvm::StringMap; = ValueTy =3D llvm::StringMap; AllocatorTy =3D= llvm::MallocAllocator; llvm::StringMap::MapEntryTy =3D = llvm::StringMapEntry >]' > = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/= StringMap.h:375:43: > required from >=20 > 'llvm::StringMap::MapEntryTy& = llvm::StringMap::GetOrCreateValue(llvm::StringRef) = [with ValueTy =3D llvm::StringMap; = AllocatorTy =3D llvm::MallocAllocator; llvm::StringMap::MapEntryTy =3D = llvm::StringMapEntry >]' > = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/= StringMap.h:299:32: > required from >=20 > 'ValueTy& llvm::StringMap::operator[](llvm::StringRef) [with ValueTy =3D = llvm::StringMap; AllocatorTy =3D = llvm::MallocAllocator]' > = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Speci= alCaseList.cpp:120:21: > required from >=20 > here > /usr/include/c++/v1/./type_traits:881:87: error: use of deleted = function 'llvm::StringMap::StringMap(const = llvm::StringMap&)' > = sizeof(__is_convertible_imp::__test<_T2>(__is_convertible_imp::__source<_T= 1>())) =3D=3D 1 > = ^ and a little more... > In file included from = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Supp= ort/SpecialCaseList.h:51:0, > from = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Speci= alCaseList.cpp:17: > = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/= StringMap.h:226:7: > note: 'llvm::StringMap::StringMap(const = llvm::StringMap&)' is implicitly declared = as deleted because 'llvm::StringMap' = declares a move constructor or move assignment operator > class StringMap : public StringMapImpl { > ^ where... > namespace __is_convertible_imp > { > template char __test(_Tp); > template __two __test(...); > #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES > template _Tp&& __source(); > #else =20 > template typename remove_reference<_Tp>::type& __source(); > #endif > =20 > ... > } In other words: > __is_convertible_imp::__source&>() is a function returning llvm::StringMap&& = (an r-value reference, not a universal one). (I'm presuming rvalue = references but the overall point is the same even for const = llvm::StringMap& as the return type.) As for __is_convertible_imp::__test: > = __is_convertible_imp::__test= > > (llvm::StringMap) is a function returning a value of type char that is used when the = argument can be passed into a = llvm::StringMap type of parameter. Failure = of this to be possible is not of itself an error ("substitution failure = is not an error" for selecting template functions): it just means that = other example definitions of __is_convertible_imp::__test functions may = be used to match the argument instead. and > = __is_convertible_imp::__test= >(...) is a function returning a value of type __two for all potential, valid = argument lists. (_T2 is actually ignored.) When both = __is_convertible_imp::__test's are non-errors the prior one is picked by = the language rules: a better parameter vs. argument match. Note that the status of deleted copy constructors can contribute to if > = __is_convertible_imp::__test= > > (llvm::StringMap) is a match for the convertibility classifications and it is not an error = for them to do so. The size of the selected = __is_convertible_imp::__test= >'s result type indicates the is-convertible status (sizeof(char) !=3D = sizeof(__two)) and the sizeof use means that overall the expression is a = constexpr (compile time constant) that is based on the type analysis by = the compiler, with no actual constructions happening. But the powerpc64-gcc 4.9.1 compiler is not applying the principle of = "substitution failure is not an error" and is not using the implicitly = deleted-status to cause a mis-match for: > = __is_convertible_imp::__test= > > (llvm::StringMap) So the compiler rejects the code for supposed use of an implicitly = deleted StringMap(const StringMap &RHS) constructor. This is a wrong = classification for the code. It appears that powerpc64-gcc (gcc 4.9.1) is not up to compiling = 11.0-CURRENT -r279514's clang/llvm as-is. Context details, mostly applying to both gcc 4.2.1 based world/kernel = with powperpc-gcc in use for cross compiling and gcc 4.9.1 based = world/kernel: powerpc64-gcc automatically looks in /usr/local/include for header files = (like most such ports) and this can pick up the wrong file(s). I ended = up renaming /usr/local/include/iconv.h so that it would not be found and used where a file with different = content from my /usr/srcC/... was needed. CROSS_TOOLCHAIN=3Dpowerpc64-gcc use does not allow -melf32ppc_fbsd for = WITH_BOOT=3D and WITH_LIB32=3D build activity to use. Even if there was = a powerpc-xtoolchain-gcc (and powerpc-gcc) around then selectively doing = just the WITH_BOOT=3D and WITH_LIB32=3D would still not seem a natural = fit. In my experiments at times for the 4.9.1 based live-world I've placed = the following symbolic links: > # ls -FPal /usr/lib/libstdc* > lrwxr-xr-x 1 root wheel 8 Mar 19 03:47 /usr/lib/libstdc++.a@ -> = libc++.a > lrwxr-xr-x 1 root wheel 9 Mar 19 03:47 /usr/lib/libstdc++.so@ -> = libc++.so >=20 > # ls -FPal /usr/bin/gcc /usr/bin/g++ > lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/g++@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/gcc@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc For example csu/powerpc64/... uses "gcc" directly, ignoring XCC and CC. The CC, CXX, and CPP in... > # more /etc/src.conf > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > ... that essentially duplicate the XCC, XCXX, XCPP assignments from = CROSS_TOOLCHAIN=3Dpowerpc64-gcc are there because otherwise various = stages do not use the cross tools (legacy, bootstrap-tools, build-tools, = cross-tools, kernel-tools, lib32's build-tools). Originally I was = investigating how far I could get without involving gcc 4.2.1 and what = would be involved. In the running world built-via-powerpc64-gcc environment /etc/src.conf = having ... > # CXXFLAGS For buildworld/buildkernel CROSS_TOOLCHAIN=3Dpowerpc64-gcc = use... > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu+=3D1= 1 -L/usr/obj/usr/srcC/lib/libc++/. is used because otherwise (for example)... > /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -fpic -DPIC -O2 = -pipe -DHAVE_CONFIG_H -I/usr/srcC/contrib/atf = -I/usr/srcC/lib/atf/libatf-c++/../libatf-c -I. -DHAVE_CONFIG_H = -fstack-protector -Wsyste > m-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter = -Wpointer-arith -Wno-uninitialized -c = /usr/srcC/contrib/atf/atf-c++/detail/application.cpp -o application.So ends up with... > In file included from = /usr/srcC/contrib/atf/atf-c++/detail/application.cpp:26:0: > /usr/srcC/contrib/atf/atf-c++/detail/application.hpp:29:19: fatal = error: ostream: No such file or directory > #include > ^ > compilation terminated. from lack of -I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. in CXXFLAGS = and the like. This is despite the /usr/srcC/Makefile.inc1 logic (that = ends up inactive/ineffective for some reason): > .if ${XCC:M/*} > ... > .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} =3D=3D gcc > XCFLAGS+=3D -isystem ${WORLDTMP}/usr/include = -L${WORLDTMP}/usr/lib > XCXXFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 -std=3Dgnu++11 = -L${WORLDTMP}/../lib/libc++ > DEPFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 As for /etc/make.conf it looks like... > # more /etc/make.conf > #CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > #CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > #CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > #CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > #X_COMPILER_TYPE=3Dgcc > # CXFLAGS For normal powerpc64-gcc use... > # AVOID during the buildworld/buildkernel activities: > # _includes _libraries _depend everything build32. > # See /etc/src.conf for example buildworld/buildkernel > # values for that context. > #CXXFLAGS+=3D-I/usr/include/c++/v1 -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++ > # > #CC=3D/usr/local/bin/gcc5 > #CXX=3D/usr/local/bin/g++5 > #CPP=3D/usr/local/bin/cpp5 > #CC=3D/usr/local/bin/clang36 > #CXX=3D/usr/local/bin/clang++36 > #CPP=3D/usr/local/bin/clang-cpp36 > WRKDIRPREFIX=3D/usr/obj/portswork > #WITH_DEBUG=3D > MALLOC_PRODUCTION=3D (Some of the comments show how gcc5/g++5 use was temporarily forced = while rebuilding powerpc64-gcc from a booted world that had been built = based on powerpc64-gcc in a gcc 4.2.1 world.) > # svnlite info /usr/srcC/ > Path: /usr/srcC > Working Copy Root Path: /usr/srcC > URL: https://svn0.us-west.freebsd.org/base/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 279514 > Node Kind: directory > Schedule: normal > Last Changed Author: adrian > Last Changed Rev: 279514 > Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) > # svnlite status /usr/srcC/ --no-ignore > ? /usr/srcC/.snap > M /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h > ? /usr/srcC/restoresymtable > M /usr/srcC/sys/ddb/db_main.c > M /usr/srcC/sys/ddb/db_script.c > ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc > ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc-NODEBUG > ? /usr/srcC/sys/powerpc/conf/GENERICvtsc > ? /usr/srcC/sys/powerpc/conf/GENERICvtsc-NODEBUG > M /usr/srcC/sys/powerpc/ofw/ofw_machdep.c > M /usr/srcC/sys/powerpc/ofw/ofwcall64.S IntrusiveRefCntPtr.h does not matter if clang building is not involved. = It needed a friend declaration to gain access to a private field, = otherwise compilation stopped. And the rest existed in my environment before I started this = powerpc64-xtoolchain-gcc exploration. lib/libnv/test/dnv_tests.cc and lib/libnv/test/nv_tests.cc are from = later (-r279760) than the rest of the unmodified source code. This is in = order to remove ambiguous overload issues. > # svnlite info /usr/ports > Path: /usr/ports > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 381120 > Node Kind: directory > Schedule: normal > Last Changed Author: dbn > Last Changed Rev: 381120 > Last Changed Date: 2015-03-12 10:13:39 -0700 (Thu, 12 Mar 2015) I have gcc5 and clang36 ports installed. I've made no use of clang36. On a powerpc64 11.0-CURRENT powerpc64-xtoolchain-gcc fails to complete = its installation because powerpc64-gcc fails to complete its = installation. The problems were 4 mismatched file names and one file = also not put into staging. I copied appropriate files to the missing = names and place and from that status the installation was able to = continue and complete via postmaster with -C (as long as powerpc64-gcc = was not in use rebuilding itself: some other compiler was in use for = that activity instead). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 08:28:05 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B36CF9D0 for ; Sat, 21 Mar 2015 08:28:05 +0000 (UTC) Received: from portsmon.freebsd.org (portsmon.freebsd.org [IPv6:2001:1900:2254:206a::50:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A2651857 for ; Sat, 21 Mar 2015 08:28:05 +0000 (UTC) Received: from portsmon.freebsd.org ([127.0.1.104]) by portsmon.freebsd.org (8.14.9/8.14.9) with ESMTP id t2L8S5TU087590 for ; Sat, 21 Mar 2015 08:28:05 GMT (envelope-from linimon@FreeBSD.org) Date: Sat, 21 Mar 2015 08:28:05 GMT Message-Id: <201503210828.t2L8S5TU087590@portsmon.freebsd.org> From: linimon@FreeBSD.org To: ports@freebsd.org Reply-To: portmgr-feedback@FreeBSD.org Subject: FreeBSD unmaintained ports which are currently marked broken X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 08:28:05 -0000 As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as "broken" in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. One common problem is that recent versions of FreeBSD use clang instead of gcc by default. Another common problem is that the compiles succeed on the i386 and amd64 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 8.x/9.x/10.x/-current with target architecture'.) portname: audio/raproxy broken because: Unfetchable build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=raproxy portname: cad/cider broken because: Will not build with bmake and USES=fmake will not solve the issue build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=cad&portname=cider portname: deskutils/cdcat broken because: Fails to build with new p7zip build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutils&portname=cdcat portname: deskutils/glipper broken because: Uses unknown GNOME components pygnomedesktop and pygnomeextras build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutils&portname=glipper portname: deskutils/gnochm broken because: Uses unknown GNOME component pygnomeextras build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutils&portname=gnochm portname: deskutils/kupfer broken because: Uses unknown GNOME component pygnomedesktop build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutils&portname=kupfer portname: deskutils/timer-applet broken because: Uses unknown GNOME component pygnomedesktop build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutils&portname=timer-applet portname: devel/p5-Cdk broken because: Does not build with Perl 5.18 or above build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=p5-Cdk portname: devel/rubygem-debugger broken because: Does not build with Ruby 2.1 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=rubygem-debugger portname: devel/xtla broken because: Fails to package build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=xtla portname: editors/scribes broken because: Uses unknown GNOME component pygnomeextras build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=editors&portname=scribes portname: emulators/linux_base-gentoo-stage3 broken because: Fails to package build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=emulators&portname=linux_base-gentoo-stage3 portname: emulators/linux_dist-gentoo-stage3 broken because: Fails to package build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=emulators&portname=linux_dist-gentoo-stage3 portname: emulators/xzx broken because: Unfetchable build errors: http://beefy2.isc.freebsd.org/bulk/101amd64-quarterly/latest/logs/errors/xzx-4.6_4.log overview: http://portsmon.FreeBSD.org/portoverview.py?category=emulators&portname=xzx portname: games/py-pychess broken because: Uses unknown GNOME component pygnomedesktop build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=py-pychess portname: games/wmfortune broken because: No public disfiles build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=wmfortune portname: graphics/gnash broken because: unable to link in libboost_system build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=gnash portname: mail/mail-notification broken because: Run-time failure with Gnome 3 build errors: http://beefy1.isc.freebsd.org/bulk/93i386-RELENG_9_3/latest/logs/errors/mail-notification-5.4_11.log overview: http://portsmon.FreeBSD.org/portoverview.py?category=mail&portname=mail-notification portname: multimedia/bombono broken because: does not build on 10.x+ build errors: http://beefy2.isc.freebsd.org/bulk/101amd64-RELENG_10_1/latest/logs/errors/bombono-1.2.2_5.log overview: http://portsmon.FreeBSD.org/portoverview.py?category=multimedia&portname=bombono portname: net/nocatsplash broken because: Broken pkg-install script, should use USERS and UIDs build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=nocatsplash portname: security/arirang broken because: Does not build with Ruby 2.0 or newer build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=arirang portname: www/diamanda broken because: Does not work with current django build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=diamanda portname: x11-wm/ede broken because: Fails to link, tries to use internal fltk symbols build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-wm&portname=ede From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 08:28:11 2015 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96699ADA for ; Sat, 21 Mar 2015 08:28:11 +0000 (UTC) Received: from portsmon.freebsd.org (portsmon.freebsd.org [IPv6:2001:1900:2254:206a::50:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 83C82866 for ; Sat, 21 Mar 2015 08:28:11 +0000 (UTC) Received: from portsmon.freebsd.org ([127.0.1.104]) by portsmon.freebsd.org (8.14.9/8.14.9) with ESMTP id t2L8SBRa088615 for ; Sat, 21 Mar 2015 08:28:11 GMT (envelope-from linimon@FreeBSD.org) Date: Sat, 21 Mar 2015 08:28:11 GMT Message-Id: <201503210828.t2L8SBRa088615@portsmon.freebsd.org> From: linimon@FreeBSD.org To: ports@FreeBSD.org Reply-To: portmgr-feedback@FreeBSD.org Subject: FreeBSD ports which are currently marked broken X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 08:28:11 -0000 As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as "broken" in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. One common problem is that recent versions of FreeBSD use clang instead of gcc by default. Another common problem is that the compiles succeed on the i386 and amd64 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 8.x/9.x/10.x/-current with target architecture'.) portname: archivers/ruby-lha broken because: Does not build with Ruby 2.0 or Ruby 2.1 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archivers&portname=ruby-lha portname: archivers/ruby-zip broken because: Does not build with Ruby 2.1 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archivers&portname=ruby-zip portname: audio/aureal-kmod broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=aureal-kmod portname: audio/mp3splt-gtk broken because: Fails to configure build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=mp3splt-gtk portname: audio/padevchooser broken because: needs update to support pulseaudio 5.0 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=padevchooser portname: audio/raproxy broken because: Unfetchable build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=raproxy portname: audio/xmms-openspc broken because: does not build on FreeBSD 10.x and later build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=xmms-openspc portname: cad/cider broken because: Will not build with bmake and USES=fmake will not solve the issue build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=cad&portname=cider portname: databases/mariadb-client broken because: Does not build under FreeBSD 10 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=mariadb-client portname: databases/mariadb-server broken because: Does not build under FreeBSD 10 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=mariadb-server portname: databases/pydbdesigner broken because: Needs an unsupported version of wxWidgets build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=pydbdesigner portname: deskutils/cdcat broken because: Fails to build with new p7zip build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutils&portname=cdcat portname: deskutils/deskbar-applet broken because: Uses unknown GNOME components pygnomedesktop and evolutiondataserver build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutils&portname=deskbar-applet portname: deskutils/gimmie broken because: Uses unknown GNOME components pygnomedesktop and pygnomeextras build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutils&portname=gimmie portname: deskutils/glipper broken because: Uses unknown GNOME components pygnomedesktop and pygnomeextras build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutils&portname=glipper portname: deskutils/gnochm broken because: Uses unknown GNOME component pygnomeextras build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutils&portname=gnochm portname: deskutils/hamster-applet broken because: Uses unknown GNOME components pygnomedesktop and gnomecontrolcenter2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutils&portname=hamster-applet portname: deskutils/kupfer broken because: Uses unknown GNOME component pygnomedesktop build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutils&portname=kupfer portname: deskutils/ontv broken because: Uses unknown GNOME components pygnomedesktop and pygnomeextras build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutils&portname=ontv portname: deskutils/timer-applet broken because: Uses unknown GNOME component pygnomedesktop build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutils&portname=timer-applet portname: devel/frama-c broken because: Fails to build with ocamlgraph 1.8.6 build errors: http://beefy2.isc.freebsd.org/bulk/83amd64-default/latest/logs/errors/frama-c-20120901.log ((not currently populated)) overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=frama-c portname: devel/p5-Cdk broken because: Does not build with Perl 5.18 or above build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=p5-Cdk portname: devel/rubygem-debugger broken because: Does not build with Ruby 2.1 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=rubygem-debugger portname: devel/rubygem-igraph broken because: does not build with igraph-0.7.1 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=rubygem-igraph portname: devel/rubygem-rcov broken because: Does not work with Ruby 2.x build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=rubygem-rcov portname: devel/xtla broken because: Fails to package build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=xtla portname: editors/scribes broken because: Uses unknown GNOME component pygnomeextras build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=editors&portname=scribes portname: emulators/kqemu-kmod broken because: KPI changes in 10 and up, use bhyve or vbox build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=emulators&portname=kqemu-kmod portname: emulators/linux_base-gentoo-stage3 broken because: Fails to package build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=emulators&portname=linux_base-gentoo-stage3 portname: emulators/linux_dist-gentoo-stage3 broken because: Fails to package build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=emulators&portname=linux_dist-gentoo-stage3 portname: emulators/xzx broken because: Unfetchable build errors: http://beefy2.isc.freebsd.org/bulk/101amd64-quarterly/latest/logs/errors/xzx-4.6_4.log overview: http://portsmon.FreeBSD.org/portoverview.py?category=emulators&portname=xzx portname: games/freeciv-nox11 broken because: Fails to configure build errors: http://beefy2.isc.freebsd.org/bulk/101amd64-default/latest/logs/errors/freeciv-nox11-2.5.0.log overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=freeciv-nox11 portname: games/gtkradiant broken because: Does not support modern png build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=gtkradiant portname: games/linux-candycruncher-demo broken because: Does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=linux-candycruncher-demo portname: games/linux-coldwar-demo broken because: Does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=linux-coldwar-demo portname: games/linux-gorky17-demo broken because: Does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=linux-gorky17-demo portname: games/linux-hdb-demo broken because: Does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=linux-hdb-demo portname: games/linux-majesty-demo broken because: Does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=linux-majesty-demo portname: games/py-pychess broken because: Uses unknown GNOME component pygnomedesktop build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=py-pychess portname: games/spring broken because: Fails to build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=spring portname: games/wmfortune broken because: No public disfiles build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=wmfortune portname: graphics/gnash broken because: unable to link in libboost_system build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=gnash portname: graphics/kuickshow-kde4 broken because: depends on imlib build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=kuickshow-kde4 portname: graphics/opengtl broken because: Depends on deleted devel/llvm32 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=opengtl portname: graphics/sng broken because: Does not support modern png build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=sng portname: irc/ircd-hybrid broken because: Fails to package build errors: http://beefy2.isc.freebsd.org/bulk/101amd64-default/latest/logs/errors/ircd-hybrid-8.2.5.log overview: http://portsmon.FreeBSD.org/portoverview.py?category=irc&portname=ircd-hybrid portname: japanese/netype broken because: depends on imlib build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japanese&portname=netype portname: japanese/p5-Text-MeCab broken because: Does not build with Perl 5.18 or above build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japanese&portname=p5-Text-MeCab portname: lang/pure broken because: Depends on deleted devel/llvm32 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=lang&portname=pure portname: mail/mail-notification broken because: Run-time failure with Gnome 3 build errors: http://beefy1.isc.freebsd.org/bulk/93i386-RELENG_9_3/latest/logs/errors/mail-notification-5.4_11.log overview: http://portsmon.FreeBSD.org/portoverview.py?category=mail&portname=mail-notification portname: mail/maildirsync broken because: Does not build with Perl 5.18 or above build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=mail&portname=maildirsync portname: mail/p5-MIME-Fast broken because: Does not build with Perl 5.18 or above build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=mail&portname=p5-MIME-Fast portname: mail/qar-bufo broken because: Does not build with Perl 5.18 or above build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=mail&portname=qar-bufo portname: multimedia/arista broken because: Uses unknown GNOME component pygnomedesktop build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=multimedia&portname=arista portname: multimedia/bombono broken because: does not build on 10.x+ build errors: http://beefy2.isc.freebsd.org/bulk/101amd64-RELENG_10_1/latest/logs/errors/bombono-1.2.2_5.log overview: http://portsmon.FreeBSD.org/portoverview.py?category=multimedia&portname=bombono portname: multimedia/subtitleeditor broken because: Does not compile on FreeBSD 10.0 and later build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=multimedia&portname=subtitleeditor portname: net-im/skype4 broken because: Skype 4.3 is missing several Linux syscalls. build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-im&portname=skype4 portname: net-mgmt/netxms broken because: Fails to package build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-mgmt&portname=netxms portname: net-mgmt/tcptrack broken because: binary segfaults build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-mgmt&portname=tcptrack portname: net/cyphesis broken because: Does not compile on FreeBSD 10+ build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=cyphesis portname: net/gpxe broken because: does not build on FreeBSD 10.x and later build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=gpxe portname: net/nocatsplash broken because: Broken pkg-install script, should use USERS and UIDs build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=nocatsplash portname: net/ntopng broken because: Fails to link build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=ntopng portname: net/openospfd broken because: requires old CARP implementation (interface layer) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=openospfd portname: net/service-discovery-applet broken because: Uses unknown GNOME component pygnomedesktop build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=service-discovery-applet portname: ports-mgmt/gnome-packagekit broken because: Uses unknown GNOME component gnomemenus build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=ports-mgmt&portname=gnome-packagekit portname: print/gnome-specimen broken because: Uses unknown GNOME component pygnomedesktop build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=print&portname=gnome-specimen portname: print/sgf2tex broken because: Fails to build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=print&portname=sgf2tex portname: security/arirang broken because: Does not build with Ruby 2.0 or newer build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=arirang portname: security/p5-Crypt-GOST broken because: Does not build with Perl 5.18 or above build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=p5-Crypt-GOST portname: security/p5-Crypt-TEA broken because: Does not build with Perl 5.18 or above build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=p5-Crypt-TEA portname: sysutils/pesign broken because: This port requires ppoll(2) system call build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=sysutils&portname=pesign portname: sysutils/puppet27 broken because: Does not work with Ruby 2.0 or Ruby 2.1 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=sysutils&portname=puppet27 portname: sysutils/py-salt-api broken because: Conflicts with py27-salt-2014.7.0 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=sysutils&portname=py-salt-api portname: textproc/aiksaurus-gtk broken because: does not link against GTK2 on FreeBSD 10+ build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textproc&portname=aiksaurus-gtk portname: textproc/p5-Groonga-API broken because: Fails to build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textproc&portname=p5-Groonga-API portname: textproc/pecl-cld broken because: Missing headers with cld 20150113 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textproc&portname=pecl-cld portname: textproc/refdb broken because: Fails to link build errors: http://beefy2.isc.freebsd.org/bulk/101amd64-RELENG_10_1/latest/logs/errors/refdb-0.9.9_7.log overview: http://portsmon.FreeBSD.org/portoverview.py?category=textproc&portname=refdb portname: www/diamanda broken because: Does not work with current django build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=diamanda portname: x11-toolkits/py-kivy broken because: fails to build with cython-0.22 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-toolkits&portname=py-kivy portname: x11-wm/e-module-diskio broken because: Don't build with EFL 1.13.0 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-wm&portname=e-module-diskio portname: x11-wm/ede broken because: Fails to link, tries to use internal fltk symbols build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-wm&portname=ede From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 08:28:18 2015 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD66EB8D for ; Sat, 21 Mar 2015 08:28:17 +0000 (UTC) Received: from portsmon.freebsd.org (portsmon.freebsd.org [IPv6:2001:1900:2254:206a::50:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB9F2884 for ; Sat, 21 Mar 2015 08:28:17 +0000 (UTC) Received: from portsmon.freebsd.org ([127.0.1.104]) by portsmon.freebsd.org (8.14.9/8.14.9) with ESMTP id t2L8SHXL089347 for ; Sat, 21 Mar 2015 08:28:17 GMT (envelope-from linimon@FreeBSD.org) Date: Sat, 21 Mar 2015 08:28:17 GMT Message-Id: <201503210828.t2L8SHXL089347@portsmon.freebsd.org> From: linimon@FreeBSD.org To: ports@FreeBSD.org Reply-To: portmgr-feedback@FreeBSD.org Subject: FreeBSD ports which are currently scheduled for deletion X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 08:28:18 -0000 As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically schedule removal of ports that have been judged to have outlived their usefulness. Often, this is due to a better alternative having become available and/or the cessation of development on the existing port. In some cases, ports are marked for removal because they fail to build and install correctly from their sources, or otherwise fail in operation. The ports, and the reason and date that they have been scheduled for removal, are listed below. If no one has stepped forward before that time to propose a way to fix the problems (such as via a PR), the ports will be deleted. portname: archivers/ruby-lha description: Ruby extension to unpack LHA-compressed files maintainer: ruby@FreeBSD.org status: BROKEN deprecated because: Does not work with Ruby 2.x expiration date: 2015-03-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archivers&portname=ruby-lha portname: audio/raproxy description: Progressive Networks RealAudio Proxy Kit 3.0 beta 1 maintainer: ports@FreeBSD.org status: BROKEN deprecated because: Broken for more than 6 months expiration date: 2015-03-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=raproxy portname: converters/ruby-iconv description: iconv wrapper class for Ruby maintainer: ruby@FreeBSD.org status: IGNORE deprecated because: Not needed with Ruby 2.x expiration date: 2015-03-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=converters&portname=ruby-iconv portname: databases/db48 description: The Berkeley DB package, revision 4.8 maintainer: mandree@FreeBSD.org deprecated because: Please migrate to db5 or db6 expiration date: 2015-05-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=db48 portname: databases/postgresql84-client description: PostgreSQL database (client) maintainer: pgsql@FreeBSD.org deprecated because: EOL was reached in July 2014 expiration date: 2015-05-10 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=postgresql84-client portname: databases/postgresql84-contrib description: The contrib utilities from the PostgreSQL distribution maintainer: pgsql@FreeBSD.org deprecated because: EOL was reached in July 2014 expiration date: 2015-05-10 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=postgresql84-contrib portname: databases/postgresql84-docs description: The PostgreSQL documentation set maintainer: pgsql@FreeBSD.org deprecated because: EOL was reached in July 2014 expiration date: 2015-05-10 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=postgresql84-docs portname: databases/postgresql84-plperl description: Write SQL functions for PostgreSQL using Perl5 maintainer: pgsql@FreeBSD.org deprecated because: EOL was reached in July 2014 expiration date: 2015-05-10 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=postgresql84-plperl portname: databases/postgresql84-plpython description: Module for using Python to write SQL functions maintainer: pgsql@FreeBSD.org deprecated because: EOL was reached in July 2014 expiration date: 2015-05-10 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=postgresql84-plpython portname: databases/postgresql84-pltcl description: Module for using Tcl to write SQL functions maintainer: pgsql@FreeBSD.org deprecated because: EOL was reached in July 2014 expiration date: 2015-05-10 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=postgresql84-pltcl portname: databases/postgresql84-server description: The most advanced open-source database available anywhere maintainer: pgsql@FreeBSD.org deprecated because: EOL was reached in July 2014 expiration date: 2015-05-10 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=postgresql84-server portname: databases/pydbdesigner description: Graphical designer for relational databases maintainer: xride@FreeBSD.org status: BROKEN deprecated because: Broken for more than 6 months expiration date: 2015-03-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=pydbdesigner portname: devel/ocaml-equeue description: The Equeue library for OCaml maintainer: michipili@gmail.com deprecated because: Superseded by www/ocaml-net expiration date: 2015-08-20 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=ocaml-equeue portname: devel/rubygem-rcov description: Code coverage tool for Ruby maintainer: skreuzer@FreeBSD.org status: BROKEN deprecated because: Does not work with Ruby 2.x expiration date: 2015-03-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=rubygem-rcov portname: devel/subversion16 description: Version control system maintainer: lev@FreeBSD.org deprecated because: unsupported since 2013-06-18, missing CVE fixes expiration date: 2015-03-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=subversion16 portname: dns/bind10 description: Development version of ISC BIND 10 DNS Suite maintainer: mat@FreeBSD.org status: IGNORE deprecated because: Is not developed any more, use dns/bundy expiration date: 2015-12-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=dns&portname=bind10 portname: dns/maradns1 description: DNS server with focus on security and simplicity maintainer: mat@FreeBSD.org deprecated because: MaraDNS 1 end-of-life: June 21, 2015, use dns/maradns expiration date: 2015-06-21 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=dns&portname=maradns1 portname: lang/gcc47-aux description: Version of GCC 4.7 with full Ada support maintainer: marino@FreeBSD.org deprecated because: GCC 4.7 branch closed June 2014, move to lang/gcc-aux expiration date: 2015-05-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=lang&portname=gcc47-aux portname: lang/gnatdroid-armv5 description: C/Ada cross-compiler, target: Android ARMv5 maintainer: marino@FreeBSD.org status: IGNORE deprecated because: Nobody cares enough to fix sigtramp-android.c for ARMv5 expiration date: 2015-03-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=lang&portname=gnatdroid-armv5 portname: lang/perl5.16 description: Practical Extraction and Report Language maintainer: perl@FreeBSD.org deprecated because: Unsupported, please upgrade to a more recent version of Perl expiration date: 2015-07-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=lang&portname=perl5.16 portname: lang/pure description: Modern-style functional programming language maintainer: lichray@gmail.com status: BROKEN deprecated because: Old revision of software, depends on deleted version of llvm expiration date: 2015-05-14 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=lang&portname=pure portname: misc/kde4-l10n-si description: Sinhalese messages and documentation for KDE SC 4 maintainer: kde@FreeBSD.org status: IGNORE deprecated because: Upstream ceased maintainance of this translation expiration date: 2016-01-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=misc&portname=kde4-l10n-si portname: misc/kde4-l10n-tg description: Tajik messages and documentation for KDE SC 4 maintainer: kde@FreeBSD.org status: IGNORE deprecated because: Upstream ceased maintainance of this translation expiration date: 2016-01-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=misc&portname=kde4-l10n-tg portname: misc/kde4-l10n-th description: Thai messages and documentation for KDE SC 4 maintainer: kde@FreeBSD.org status: IGNORE deprecated because: Upstream ceased maintainance of this translation expiration date: 2016-01-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=misc&portname=kde4-l10n-th portname: net-mgmt/tcptrack description: Packet sniffer which displays TCP information like top(1) maintainer: squat@squat.no status: BROKEN deprecated because: Broken for more than 6 months expiration date: 2015-03-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-mgmt&portname=tcptrack portname: ports-mgmt/portbuilder description: Concurrent FreeBSD port builder maintainer: dbn@FreeBSD.org deprecated because: Unmaintained, please use ports-mgmt/poudriere. expiration date: 2015-03-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=ports-mgmt&portname=portbuilder portname: ports-mgmt/porteasy description: Tool for fetching and building ports maintainer: des@FreeBSD.org deprecated because: Does not support pkgng expiration date: 2015-03-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=ports-mgmt&portname=porteasy portname: print/sgf2tex description: Convert a Go game record in SGF format into TeX and provide fonts to make a dvi maintainer: spcoltri@omcl.org status: BROKEN deprecated because: Broken for more than 6 months expiration date: 2015-03-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=print&portname=sgf2tex portname: security/arirang description: Powerful webserver security scanner for network maintainer: ports@FreeBSD.org status: BROKEN deprecated because: Does not work with Ruby 2.x expiration date: 2015-03-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=arirang portname: security/krb5-111 description: Authentication system developed at MIT, successor to Kerberos IV maintainer: cy@FreeBSD.org deprecated because: EOLed by MIT in December 2014. expiration date: 2015-08-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=krb5-111 portname: sysutils/puppet27 description: Configuration management framework written in Ruby maintainer: swills@FreeBSD.org status: BROKEN deprecated because: Does not work with Ruby 2.x expiration date: 2015-03-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=sysutils&portname=puppet27 portname: www/moodle26 description: Course management system based on social constructionism maintainer: wen@FreeBSD.org deprecated because: Deprecated by upstream, use www/moodle2{7,8} instead expiration date: 2015-04-17 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=moodle26 portname: www/p5-Google-Code-Upload description: Uploading files to a Google Code project maintainer: sunpoet@FreeBSD.org deprecated because: Google Code will be shutting down (http://google-opensource.blogspot.tw/2015/03/farewell-to-google-code.html) expiration date: 2015-04-30 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=p5-Google-Code-Upload portname: www/rubygem-form_data description: Build form data request bodies maintainer: sunpoet@FreeBSD.org deprecated because: Use www/rubygem-http-form_data instead (renamed by upstream) expiration date: 2015-03-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=rubygem-form_data portname: www/trac-batchmodify description: Enables users to modify several tickets together at once maintainer: ports@FreeBSD.org deprecated because: This functionality was merged into Trac since version 1.0 expiration date: 2015-04-08 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=trac-batchmodify portname: www/typo345 description: The typo3 content management system maintainer: freebsd-ports@charlieroot.de deprecated because: Upgrade to www/typo3 or www/typo3-lts expiration date: 2015-03-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=typo345 From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 08:28:16 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A583B0E for ; Sat, 21 Mar 2015 08:28:16 +0000 (UTC) Received: from portsmon.freebsd.org (portsmon.freebsd.org [IPv6:2001:1900:2254:206a::50:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 57A7E87A for ; Sat, 21 Mar 2015 08:28:16 +0000 (UTC) Received: from portsmon.freebsd.org ([127.0.1.104]) by portsmon.freebsd.org (8.14.9/8.14.9) with ESMTP id t2L8SG01088955 for ; Sat, 21 Mar 2015 08:28:16 GMT (envelope-from linimon@FreeBSD.org) Date: Sat, 21 Mar 2015 08:28:16 GMT Message-Id: <201503210828.t2L8SG01088955@portsmon.freebsd.org> From: linimon@FreeBSD.org To: ports@freebsd.org Reply-To: portmgr-feedback@FreeBSD.org Subject: FreeBSD unmaintained ports which are currently scheduled for deletion X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 08:28:16 -0000 As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically schedule removal of ports that have been judged to have outlived their usefulness. Often, this is due to a better alternative having become available and/or the cessation of development on the existing port. In some cases, ports are marked for removal because they fail to build and install correctly from their sources, or otherwise fail in operation. The ports, and the reason and date that they have been scheduled for removal, are listed below. If no one has stepped forward before that time to propose a way to fix the problems (such as via a PR), the ports will be deleted. portname: audio/raproxy description: Progressive Networks RealAudio Proxy Kit 3.0 beta 1 maintainer: ports@FreeBSD.org status: BROKEN deprecated because: Broken for more than 6 months expiration date: 2015-03-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=raproxy portname: security/arirang description: Powerful webserver security scanner for network maintainer: ports@FreeBSD.org status: BROKEN deprecated because: Does not work with Ruby 2.x expiration date: 2015-03-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=arirang portname: www/trac-batchmodify description: Enables users to modify several tickets together at once maintainer: ports@FreeBSD.org deprecated because: This functionality was merged into Trac since version 1.0 expiration date: 2015-04-08 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=trac-batchmodify From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 08:28:20 2015 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00D33BB3 for ; Sat, 21 Mar 2015 08:28:19 +0000 (UTC) Received: from portsmon.freebsd.org (portsmon.freebsd.org [IPv6:2001:1900:2254:206a::50:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CCC37888 for ; Sat, 21 Mar 2015 08:28:19 +0000 (UTC) Received: from portsmon.freebsd.org ([127.0.1.104]) by portsmon.freebsd.org (8.14.9/8.14.9) with ESMTP id t2L8SJPG089373 for ; Sat, 21 Mar 2015 08:28:19 GMT (envelope-from linimon@FreeBSD.org) Date: Sat, 21 Mar 2015 08:28:19 GMT Message-Id: <201503210828.t2L8SJPG089373@portsmon.freebsd.org> From: linimon@FreeBSD.org To: ports@FreeBSD.org Reply-To: portmgr-feedback@FreeBSD.org Subject: FreeBSD ports which are currently marked forbidden X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 08:28:20 -0000 As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users about ports that are marked as "forbidden" in their Makefiles. Often, these ports are so marked due to security concerns, such as known exploits. An overview of each port, including errors seen on the build farm, is included below. portname: x11/nvidia-driver-173 forbidden because: vulnerable to denial of service or arbitrary code execution (CVE-2014-8298) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11&portname=nvidia-driver-173 From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 09:12:08 2015 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 068651A2 for ; Sat, 21 Mar 2015 09:12:08 +0000 (UTC) Received: from portsindexbuild.ysv.freebsd.org (portsindexbuild.ysv.freebsd.org [IPv6:2001:1900:2254:206a::16:6601]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CEE3BCB6 for ; Sat, 21 Mar 2015 09:12:07 +0000 (UTC) Received: from portsindexbuild.ysv.freebsd.org ([127.0.1.2]) by portsindexbuild.ysv.freebsd.org (8.14.9/8.14.9) with ESMTP id t2L9C7nZ002986 for ; Sat, 21 Mar 2015 09:12:07 GMT (envelope-from indexbuild@portsindexbuild.ysv.freebsd.org) Received: (from indexbuild@localhost) by portsindexbuild.ysv.freebsd.org (8.14.9/8.14.9/Submit) id t2L9C7j4002984 for ports@FreeBSD.org; Sat, 21 Mar 2015 09:12:07 GMT (envelope-from indexbuild) Date: Sat, 21 Mar 2015 09:12:07 GMT From: Ports Index build Message-Id: <201503210912.t2L9C7j4002984@portsindexbuild.ysv.freebsd.org> To: ports@FreeBSD.org Subject: INDEX now builds successfully on 8.x X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 09:12:08 -0000 From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 11:49:13 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A54FA6FA; Sat, 21 Mar 2015 11:49:13 +0000 (UTC) Received: from hades.sorbs.net (mail.sorbs.net [67.231.146.200]) by mx1.freebsd.org (Postfix) with ESMTP id 911CBC2D; Sat, 21 Mar 2015 11:49:13 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0NLK007AT6AJ7I00@hades.sorbs.net>; Sat, 21 Mar 2015 03:54:20 -0700 (PDT) Message-id: <550D4CA0.8000606@sorbs.net> Date: Sat, 21 Mar 2015 11:49:04 +0100 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: Jeremie Le Hen Subject: Re: net/unison240 depends on lang/ocaml-nox11 References: In-reply-to: Cc: madpilot@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 11:49:13 -0000 Jeremie Le Hen wrote: > Actually, I've just realized that I fixed net/unison232 in my local tree :o). > > Would you mind submitting it and applying the same for unison240? > > Here is the patch: > > Index: Makefile > =================================================================== > --- Makefile (revision 381259) > +++ Makefile (working copy) > @@ -34,20 +34,18 @@ > > .include > > +BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml > .if ${PORT_OPTIONS:MX11} > MAKE_ARGS+= UISTYLE=gtk2 > PLIST_SUB+= TEXT="" > -BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml \ > - lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 \ > +BUILD_DEPENDS+= lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 \ > icotool:${PORTSDIR}/graphics/icoutils > RUN_DEPENDS+= lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 > PATCH_DEPENDS+= ${BUILD_DEPENDS} > -CONFLICTS+= ocaml-nox11* > SUB_FILES+= ${PORTNAME}.desktop > .else > MAKE_ARGS+= UISTYLE=text > PLIST_SUB+= TEXT="@comment " > -BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml-nox11 > PATCH_DEPENDS+= ${BUILD_DEPENDS} > .endif > > This breaks -nox11 when building with pourdriere... =================================================== ===> Patching for unison-2.48.3_1 =========================================================================== =================================================== ===> unison-2.48.3_1 depends on executable: ocamlc - not found ===> Verifying install for ocamlc in /usr/ports/lang/ocaml ===> unison-2.48.3_1 depends on package: /packages/All/ocaml-4.01.0_4.tbz - not found ===> USE_PACKAGE_DEPENDS_ONLY set - not building missing dependency from source *** [build-depends] Error code 1 Stop in /usr/ports/net/unison. ===> Cleaning for unison-2.48.3_1 build of /usr/ports/net/unison ended at Sat Mar 21 12:32:36 CET 2015 -BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml-nox11 should be there in the 'else' section of OPTIONS:MX11 (perhaps as BUILD_DEPENDS= instead of BUILD_DEPENDS+=) Regards, -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 12:19:22 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0B9331E; Sat, 21 Mar 2015 12:19:22 +0000 (UTC) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4AB27EF8; Sat, 21 Mar 2015 12:19:21 +0000 (UTC) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3l8Lcd4MLszZs8; Sat, 21 Mar 2015 13:19:13 +0100 (CET) Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id zxTglU3Hxflr; Sat, 21 Mar 2015 13:19:11 +0100 (CET) Received: from tommy.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Sat, 21 Mar 2015 13:19:11 +0100 (CET) Message-ID: <550D61BF.3030403@FreeBSD.org> Date: Sat, 21 Mar 2015 13:19:11 +0100 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Michelle Sullivan , Jeremie Le Hen Subject: Re: net/unison240 depends on lang/ocaml-nox11 References: <550D4CA0.8000606@sorbs.net> In-Reply-To: <550D4CA0.8000606@sorbs.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 12:19:22 -0000 On 03/21/15 11:49, Michelle Sullivan wrote: > Jeremie Le Hen wrote: >> Actually, I've just realized that I fixed net/unison232 in my local tree :o). >> >> Would you mind submitting it and applying the same for unison240? >> >> Here is the patch: >> >> Index: Makefile >> =================================================================== >> --- Makefile (revision 381259) >> +++ Makefile (working copy) >> @@ -34,20 +34,18 @@ >> >> .include >> >> +BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml >> .if ${PORT_OPTIONS:MX11} >> MAKE_ARGS+= UISTYLE=gtk2 >> PLIST_SUB+= TEXT="" >> -BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml \ >> - lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 \ >> +BUILD_DEPENDS+= lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 \ >> icotool:${PORTSDIR}/graphics/icoutils >> RUN_DEPENDS+= lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 >> PATCH_DEPENDS+= ${BUILD_DEPENDS} >> -CONFLICTS+= ocaml-nox11* >> SUB_FILES+= ${PORTNAME}.desktop >> .else >> MAKE_ARGS+= UISTYLE=text >> PLIST_SUB+= TEXT="@comment " >> -BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml-nox11 >> PATCH_DEPENDS+= ${BUILD_DEPENDS} >> .endif >> >> > This breaks -nox11 when building with pourdriere... > > =================================================== > ===> Patching for unison-2.48.3_1 > =========================================================================== > =================================================== > ===> unison-2.48.3_1 depends on executable: ocamlc - not found > ===> Verifying install for ocamlc in /usr/ports/lang/ocaml > ===> unison-2.48.3_1 depends on package: > /packages/All/ocaml-4.01.0_4.tbz - not found > ===> USE_PACKAGE_DEPENDS_ONLY set - not building missing dependency > from source > *** [build-depends] Error code 1 > > Stop in /usr/ports/net/unison. > ===> Cleaning for unison-2.48.3_1 > build of /usr/ports/net/unison ended at Sat Mar 21 12:32:36 CET 2015 > > -BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml-nox11 > > should be there in the 'else' section of OPTIONS:MX11 (perhaps as > BUILD_DEPENDS= instead of BUILD_DEPENDS+=) Which is almost what the port did, and caused an error about multiple origins, as reported by jlh. I'm willing to find a solution to this, but at this point I need a way to reproduce the problem and really understand where the problem is/was. I do build regularly this port on poudriere in two jails, one with X11 set and one with it unset and never saw this happen. I suspect it happens when there is some misalignment with the X11 option between ports (some with, some wothout), which is perfectly legitimate but makes things difficult to cope with, since the ocaml package changes it's suffix depending on that option. can you send me the full log for the failed build? I'd like to ask the same from jlh if he still has it, so I can understand what is really going on. Thanks. -- Guido Falsi From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 12:26:23 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E11B549A; Sat, 21 Mar 2015 12:26:22 +0000 (UTC) Received: from hades.sorbs.net (mail.sorbs.net [67.231.146.200]) by mx1.freebsd.org (Postfix) with ESMTP id CBF80FB3; Sat, 21 Mar 2015 12:26:22 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0NLK00A05ASLTE00@hades.sorbs.net>; Sat, 21 Mar 2015 05:31:35 -0700 (PDT) Message-id: <550D636B.5020000@sorbs.net> Date: Sat, 21 Mar 2015 13:26:19 +0100 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: Guido Falsi Subject: Re: net/unison240 depends on lang/ocaml-nox11 References: <550D4CA0.8000606@sorbs.net> <550D61BF.3030403@FreeBSD.org> In-reply-to: <550D61BF.3030403@FreeBSD.org> Cc: Jeremie Le Hen , freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 12:26:23 -0000 Guido Falsi wrote: > On 03/21/15 11:49, Michelle Sullivan wrote: > >> Jeremie Le Hen wrote: >> >>> Actually, I've just realized that I fixed net/unison232 in my local tree :o). >>> >>> Would you mind submitting it and applying the same for unison240? >>> >>> Here is the patch: >>> >>> Index: Makefile >>> =================================================================== >>> --- Makefile (revision 381259) >>> +++ Makefile (working copy) >>> @@ -34,20 +34,18 @@ >>> >>> .include >>> >>> +BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml >>> .if ${PORT_OPTIONS:MX11} >>> MAKE_ARGS+= UISTYLE=gtk2 >>> PLIST_SUB+= TEXT="" >>> -BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml \ >>> - lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 \ >>> +BUILD_DEPENDS+= lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 \ >>> icotool:${PORTSDIR}/graphics/icoutils >>> RUN_DEPENDS+= lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 >>> PATCH_DEPENDS+= ${BUILD_DEPENDS} >>> -CONFLICTS+= ocaml-nox11* >>> SUB_FILES+= ${PORTNAME}.desktop >>> .else >>> MAKE_ARGS+= UISTYLE=text >>> PLIST_SUB+= TEXT="@comment " >>> -BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml-nox11 >>> PATCH_DEPENDS+= ${BUILD_DEPENDS} >>> .endif >>> >>> >>> >> This breaks -nox11 when building with pourdriere... >> >> =================================================== >> ===> Patching for unison-2.48.3_1 >> =========================================================================== >> =================================================== >> ===> unison-2.48.3_1 depends on executable: ocamlc - not found >> ===> Verifying install for ocamlc in /usr/ports/lang/ocaml >> ===> unison-2.48.3_1 depends on package: >> /packages/All/ocaml-4.01.0_4.tbz - not found >> ===> USE_PACKAGE_DEPENDS_ONLY set - not building missing dependency >> from source >> *** [build-depends] Error code 1 >> >> Stop in /usr/ports/net/unison. >> ===> Cleaning for unison-2.48.3_1 >> build of /usr/ports/net/unison ended at Sat Mar 21 12:32:36 CET 2015 >> >> -BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml-nox11 >> >> should be there in the 'else' section of OPTIONS:MX11 (perhaps as >> BUILD_DEPENDS= instead of BUILD_DEPENDS+=) >> > > Which is almost what the port did, and caused an error about multiple > origins, as reported by jlh. > > I'm willing to find a solution to this, but at this point I need a way > to reproduce the problem and really understand where the problem is/was. > > I do build regularly this port on poudriere in two jails, one with X11 > set and one with it unset and never saw this happen. > > I suspect it happens when there is some misalignment with the X11 option > between ports (some with, some wothout), which is perfectly legitimate > but makes things difficult to cope with, since the ocaml package changes > it's suffix depending on that option. > > can you send me the full log for the failed build? I'd like to ask the > same from jlh if he still has it, so I can understand what is really > going on. > I think the problem comes in when you build with poudriere because when you're building without the build will just select the correct options and build ocaml appropriately.. The build then continues as ocaml is installed. When building with poudriere the build_depends looks for the package but the package selection process doesn't look for the -nox11 suffix as this is set in the makefile of the port and not in the package selection process. (If I explained that correctly ;-) ) Your package build initially was correct. I believe pkgng is wrong - either that or the whole build system needs to be updated so that the package installation looks at the set options and makefiles when deciding which package to find and install. Personally I thing ocaml (and similar) should not have the -nox11 options in the package name and should just install as a dependency.... but I expect that will cause other issues even more weird and wonderful. Michelle -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 13:07:38 2015 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01BF89C0 for ; Sat, 21 Mar 2015 13:07:38 +0000 (UTC) Received: from h1883966.stratoserver.net (h1883966.stratoserver.net [85.214.210.55]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ADD8135F for ; Sat, 21 Mar 2015 13:07:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by h1883966.stratoserver.net (Postfix) with ESMTP id CCF4860C18A for ; Sat, 21 Mar 2015 13:59:21 +0100 (CET) Received: from h1883966.stratoserver.net ([127.0.0.1]) by localhost (h1883966.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmkE2NdzcAI0 for ; Sat, 21 Mar 2015 13:59:20 +0100 (CET) Received: from [192.168.44.51] (unknown [95.90.201.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: gerrit@macclub-os.de) by h1883966.stratoserver.net (Postfix) with ESMTPSA id EA1E960C0D0 for ; Sat, 21 Mar 2015 13:59:19 +0100 (CET) Message-ID: <550D6B18.2070706@macclub-os.de> Date: Sat, 21 Mar 2015 13:59:04 +0100 From: Gerrit User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: ports@FreeBSD.org Subject: x11/xscreensaver-gnome port question Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="953Pdjg1tXX7gchL47l1mtfGlqATwxq3G" X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 13:07:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --953Pdjg1tXX7gchL47l1mtfGlqATwxq3G Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi there, how can I lock the screen by keystroke or button? On my FreeBSD machine that can be achieved by pressing Win-l or by choosing a button in the shutdown menu on the top right. On this PC-BSD machine I can't find a method to achieve this :-) Best regards Gerrit -----------\nPBI Information:\nPort: x11/xscreensaver-gnome\nName: xscreensaver-gnome\nDate Installed: 3/17/15 10:50 PM\nVersion: 5.12_3\nArchitecture: 10-64bit --953Pdjg1tXX7gchL47l1mtfGlqATwxq3G Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVDWsnAAoJEL3J7dVQFFCAt1QP/1ZlpV0QpvhwQmgerV7FP94x cm69X/SaI7iCbDR5Wp4gOUVGGuoQmxui+HT2/Xy5wUWqXqbfovDUdP4zCfOrtFLN XympdjWMcNDqlgImTLfHiJqZeVNpX0pYVNkBoEa6miRBzt5vACUFtUU23At4tSjf 7cJl4OqFyT8r3ehttfVF6sKnFBcZegAY2iLz1FfhjTjKi13/rrJKBhNdDZ0epsR2 s9ZCXQXlMEIx/yi5uNRWJqZYR9AbMIx4+cPsXYXeeemW4xmgltocu1es7Xs/pYMB hseukmEvquLq7aADgxK6AHo+PCmCTE5Q2EMg1T96Hh4pfDgoyricMMnicQ6JXly2 9JyYx/21vAfjvinxU9Xbo61DahyxKNwNE1VaLV/lZChFt7QduQ0YFsU2U+0xxqW8 iGojj5Zxg+g7TRuoJXcAvSqXjYbww5SJf02UmHNik4SGPs0Lwv7adfo6Tl12yAAR 9hH4IyuAgmtBFWUkvAYU40B/oJbVXN8YVUm3ASD4PIBs3Uf/0WdmofIvieBB6vFO d6eYqSQba344QA3QZlAXkLcDjEtjaAdd6F5U3JBTTz5qt7PmbAAcRq3N/J+bXUf8 dKtmElvCubo0ItdrkZ80ZqU75otPpp39XVmEfqlFHGnELXb1N9/SBQObWJCw73TI 9wz8q/TjYm0WeduuxCxp =dNkZ -----END PGP SIGNATURE----- --953Pdjg1tXX7gchL47l1mtfGlqATwxq3G-- From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 13:07:38 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 982FA9C1; Sat, 21 Mar 2015 13:07:38 +0000 (UTC) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3C368360; Sat, 21 Mar 2015 13:07:38 +0000 (UTC) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3l8MhM2q9KzZs8; Sat, 21 Mar 2015 14:07:31 +0100 (CET) Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id OPRTuoH1uvRA; Sat, 21 Mar 2015 14:07:28 +0100 (CET) Received: from tommy.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Sat, 21 Mar 2015 14:07:28 +0100 (CET) Message-ID: <550D6D0F.7080401@FreeBSD.org> Date: Sat, 21 Mar 2015 14:07:27 +0100 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Michelle Sullivan Subject: Re: net/unison240 depends on lang/ocaml-nox11 References: <550D4CA0.8000606@sorbs.net> <550D61BF.3030403@FreeBSD.org> <550D636B.5020000@sorbs.net> In-Reply-To: <550D636B.5020000@sorbs.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Jeremie Le Hen , freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 13:07:38 -0000 On 03/21/15 13:26, Michelle Sullivan wrote: > Guido Falsi wrote: >> On 03/21/15 11:49, Michelle Sullivan wrote: >> >>> Jeremie Le Hen wrote: >>> >>>> Actually, I've just realized that I fixed net/unison232 in my local tree :o). >>>> >>>> Would you mind submitting it and applying the same for unison240? >>>> >>>> Here is the patch: >>>> >>>> Index: Makefile >>>> =================================================================== >>>> --- Makefile (revision 381259) >>>> +++ Makefile (working copy) >>>> @@ -34,20 +34,18 @@ >>>> >>>> .include >>>> >>>> +BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml >>>> .if ${PORT_OPTIONS:MX11} >>>> MAKE_ARGS+= UISTYLE=gtk2 >>>> PLIST_SUB+= TEXT="" >>>> -BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml \ >>>> - lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 \ >>>> +BUILD_DEPENDS+= lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 \ >>>> icotool:${PORTSDIR}/graphics/icoutils >>>> RUN_DEPENDS+= lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 >>>> PATCH_DEPENDS+= ${BUILD_DEPENDS} >>>> -CONFLICTS+= ocaml-nox11* >>>> SUB_FILES+= ${PORTNAME}.desktop >>>> .else >>>> MAKE_ARGS+= UISTYLE=text >>>> PLIST_SUB+= TEXT="@comment " >>>> -BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml-nox11 >>>> PATCH_DEPENDS+= ${BUILD_DEPENDS} >>>> .endif >>>> >>>> >>>> >>> This breaks -nox11 when building with pourdriere... >>> >>> =================================================== >>> ===> Patching for unison-2.48.3_1 >>> =========================================================================== >>> =================================================== >>> ===> unison-2.48.3_1 depends on executable: ocamlc - not found >>> ===> Verifying install for ocamlc in /usr/ports/lang/ocaml >>> ===> unison-2.48.3_1 depends on package: >>> /packages/All/ocaml-4.01.0_4.tbz - not found >>> ===> USE_PACKAGE_DEPENDS_ONLY set - not building missing dependency >>> from source >>> *** [build-depends] Error code 1 >>> >>> Stop in /usr/ports/net/unison. >>> ===> Cleaning for unison-2.48.3_1 >>> build of /usr/ports/net/unison ended at Sat Mar 21 12:32:36 CET 2015 >>> >>> -BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml-nox11 >>> >>> should be there in the 'else' section of OPTIONS:MX11 (perhaps as >>> BUILD_DEPENDS= instead of BUILD_DEPENDS+=) >>> >> >> Which is almost what the port did, and caused an error about multiple >> origins, as reported by jlh. >> >> I'm willing to find a solution to this, but at this point I need a way >> to reproduce the problem and really understand where the problem is/was. >> >> I do build regularly this port on poudriere in two jails, one with X11 >> set and one with it unset and never saw this happen. >> >> I suspect it happens when there is some misalignment with the X11 option >> between ports (some with, some wothout), which is perfectly legitimate >> but makes things difficult to cope with, since the ocaml package changes >> it's suffix depending on that option. >> >> can you send me the full log for the failed build? I'd like to ask the >> same from jlh if he still has it, so I can understand what is really >> going on. >> > > I think the problem comes in when you build with poudriere because when > you're building without the build will just select the correct options > and build ocaml appropriately.. The build then continues as ocaml is > installed. I have two poudriere jails I use to create package sets for some machines of mine, one builds packages with the X11 option, the other without (using OPTIONS_UNSET+=X11 among other options, which ensures all packages will get the same option, unless overridden per package, which I'm not doing in this case). I've just started those two from scratch for a verification, the one without X11 just completed successfully building ocaml with correct pkgname (with -nox11 suffix) and successfully build unison-nox11. I'll also test these packages at runtime later just to be sure, but I'm confident they are working correctly. But looking at the old logs I see no indication of these problems. I have an explanation for both cases, I'll check them, but it requires time for poudriere runs. > > When building with poudriere the build_depends looks for the package but > the package selection process doesn't look for the -nox11 suffix as this > is set in the makefile of the port and not in the package selection process. > > (If I explained that correctly ;-) ) Not exactly. Let's see (anyone correct me if I'm wrong in the explanation): with the port as it was, like this(trimmed): .if ${PORT_OPTIONS:MX11} BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml .else BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml-nox11 .endif poudriere will see the port with a variable origin, depending on the X11 option. If in the same poudriere run there is any other port which depends on ocaml, but with a different origin (which is quite possible, maybe some other port without an X11 option, which unconditionally depends on ${PORTSDIR}/lang/ocaml) poudriere will notice this and report conflicting origins. This is the problem jlh was seeing. I never noticed it since ocaml is the only port depending on ocaml I ever build. The only solution to this one is not having a variable origin. Changing that to a fixed DEPENDS as the port is now, poudriere will look into the ocaml port to discover it's pkg name, the x11 suffix for the pkg filename isn't derived from the depends, but from the depended port Makefile, so poudriere should in fact try to build the ocaml port with the required pkgname automatically, named depending on the X11 option. This leads me to think there is some misalignment of the X11 option in your setup, that's why I asked for the full log of the failed build, I need to check the environment. > > Your package build initially was correct. I believe pkgng is wrong - > either that or the whole build system needs to be updated so that the > package installation looks at the set options and makefiles when > deciding which package to find and install. Personally I thing ocaml > (and similar) should not have the -nox11 options in the package name and > should just install as a dependency.... but I expect that will cause > other issues even more weird and wonderful. -nox11 as a suffix is quite common and compiled in defaults are a documented use for PKGNAMESUFFIX, so I can't criticize that. Anyway poudriere uses the port build system to create dependency lists and it does look inside the port Makefiles. Again, I suspect you are building ocaml with X11 enabled and unison with X11 disabled. I'm not sure I know a correct way to make it work. It will anyway generate a conflicting package set, since ocaml and ocaml-nox11 conflict with each other. Having a variable origin for a port isn't a solution... The generated packages would anyway have conflicts between them, which is a consequence of the problem jlh reported. I'm doing some testing but if you could provide me the build log of the failed unison build it would help. -- Guido Falsi From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 13:33:21 2015 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44C78DCA for ; Sat, 21 Mar 2015 13:33:21 +0000 (UTC) Received: from biertje.skysmurf.nl (unknown [IPv6:2001:984:78b5:1:21b:78ff:fea8:3f22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D4CC07E7 for ; Sat, 21 Mar 2015 13:33:20 +0000 (UTC) Received: from biertje.skysmurf.nl (localhost [127.0.0.1]) by biertje.skysmurf.nl (8.14.9/8.14.9) with ESMTP id t2LDXHBP095151; Sat, 21 Mar 2015 14:33:17 +0100 (CET) (envelope-from fonz@biertje.skysmurf.nl) Received: (from fonz@localhost) by biertje.skysmurf.nl (8.14.9/8.14.9/Submit) id t2LDXHO2095150; Sat, 21 Mar 2015 14:33:17 +0100 (CET) (envelope-from fonz) Date: Sat, 21 Mar 2015 14:33:17 +0100 From: "A.J. \"Fonz\" van Werven" To: Gerrit Subject: Re: x11/xscreensaver-gnome port question Message-ID: <20150321133317.GA95123@biertje.skysmurf.nl> References: <550D6B18.2070706@macclub-os.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline In-Reply-To: <550D6B18.2070706@macclub-os.de> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: ports@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 13:33:21 -0000 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Gerrit wrote: > how can I lock the screen by keystroke or button? That has nothing to do with FreeBSD. Or even with PC-BSD, for that matter. It's part of the configuration of whatever window manager and/or desktop environment you're using. AvW --=20 I'm not completely useless, I can be used as a bad example. --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVDXMcAAoJEAfP7gJTaCe8y8gQAM58OhC9l8ivX7QitHULURws f4cG/+YWJZVPMRYNn0CYurgukToFFVTTCLZ9kD6EzIpJudkvJR32Fvhhn6v6FJtx Gq+v8193YT8NI9MVeNPYLXmY6/KxuOWPkc0QOvs9fA2l7vpj6+qAdv0+g6ZUUdpS kMWr8M6ik76w71Ti9ArQzLx24jEfQlGrzgJJunumOXePQlRu6z/bMXkZqEUdViH1 A71ADPzjst0cyPvNMCMBWwjuSSMAoEA9U/BClyRD5tFYkQdBehOhk+v9g0UWBUsG Mm6LVVYvk8RhMkohz1ww2XuS0y8cssea42NPDd83RQ/tKlnNnxjZxvLq2vlBbHus wixCt4SjrwkUMiJLo5Bt/TuV5BhYdggZJFRP3wEpRyTp0jmWMgwwtYAxiZPx5XFv Z7UzZMcv+eSyjTMRo5ID/3hm5T1tNYwq4qpjc5+tOIK+LLnvpy8+jIdCDbKf7QFB cYV7rfM02EI5w0NEuzHfZ/ubhXb2BXtIOXu4XmRzpVGS0Ml7hnL0UJDlzOqp+sgY W1+mowygTwnl5GuDJSvhJp/wL84DiSYxZ/IzeG/i6OPt3Y8UHMSZg3XoEqe4vNxn Mz2hVev61cFf6cgXeNv/bMmDxBE3faT1c5MPPCXhHH+Mnhda4PVXgltOUDj3NsIr IIgfUswZkvzPJdmX2C8I =9nLa -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW-- From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 13:50:34 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A4551AC; Sat, 21 Mar 2015 13:50:34 +0000 (UTC) Received: from hades.sorbs.net (mail.sorbs.net [67.231.146.200]) by mx1.freebsd.org (Postfix) with ESMTP id 64AB68E8; Sat, 21 Mar 2015 13:50:33 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0NLK00A15EOWTE00@hades.sorbs.net>; Sat, 21 Mar 2015 06:55:45 -0700 (PDT) Message-id: <550D7726.1060704@sorbs.net> Date: Sat, 21 Mar 2015 14:50:30 +0100 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: Guido Falsi Subject: Re: net/unison240 depends on lang/ocaml-nox11 References: <550D4CA0.8000606@sorbs.net> <550D61BF.3030403@FreeBSD.org> <550D636B.5020000@sorbs.net> <550D6D0F.7080401@FreeBSD.org> In-reply-to: <550D6D0F.7080401@FreeBSD.org> Cc: Jeremie Le Hen , freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 13:50:34 -0000 Guido Falsi wrote: > On 03/21/15 13:26, Michelle Sullivan wrote: > >> Guido Falsi wrote: >> >>> On 03/21/15 11:49, Michelle Sullivan wrote: >>> >>> >>>> Jeremie Le Hen wrote: >>>> >>>> >>>>> Actually, I've just realized that I fixed net/unison232 in my local tree :o). >>>>> >>>>> Would you mind submitting it and applying the same for unison240? >>>>> >>>>> Here is the patch: >>>>> >>>>> Index: Makefile >>>>> =================================================================== >>>>> --- Makefile (revision 381259) >>>>> +++ Makefile (working copy) >>>>> @@ -34,20 +34,18 @@ >>>>> >>>>> .include >>>>> >>>>> +BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml >>>>> .if ${PORT_OPTIONS:MX11} >>>>> MAKE_ARGS+= UISTYLE=gtk2 >>>>> PLIST_SUB+= TEXT="" >>>>> -BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml \ >>>>> - lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 \ >>>>> +BUILD_DEPENDS+= lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 \ >>>>> icotool:${PORTSDIR}/graphics/icoutils >>>>> RUN_DEPENDS+= lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 >>>>> PATCH_DEPENDS+= ${BUILD_DEPENDS} >>>>> -CONFLICTS+= ocaml-nox11* >>>>> SUB_FILES+= ${PORTNAME}.desktop >>>>> .else >>>>> MAKE_ARGS+= UISTYLE=text >>>>> PLIST_SUB+= TEXT="@comment " >>>>> -BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml-nox11 >>>>> PATCH_DEPENDS+= ${BUILD_DEPENDS} >>>>> .endif >>>>> >>>>> >>>>> >>>>> >>>> This breaks -nox11 when building with pourdriere... >>>> >>>> =================================================== >>>> ===> Patching for unison-2.48.3_1 >>>> =========================================================================== >>>> =================================================== >>>> ===> unison-2.48.3_1 depends on executable: ocamlc - not found >>>> ===> Verifying install for ocamlc in /usr/ports/lang/ocaml >>>> ===> unison-2.48.3_1 depends on package: >>>> /packages/All/ocaml-4.01.0_4.tbz - not found >>>> ===> USE_PACKAGE_DEPENDS_ONLY set - not building missing dependency >>>> from source >>>> *** [build-depends] Error code 1 >>>> >>>> Stop in /usr/ports/net/unison. >>>> ===> Cleaning for unison-2.48.3_1 >>>> build of /usr/ports/net/unison ended at Sat Mar 21 12:32:36 CET 2015 >>>> >>>> -BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml-nox11 >>>> >>>> should be there in the 'else' section of OPTIONS:MX11 (perhaps as >>>> BUILD_DEPENDS= instead of BUILD_DEPENDS+=) >>>> >>>> >>> Which is almost what the port did, and caused an error about multiple >>> origins, as reported by jlh. >>> >>> I'm willing to find a solution to this, but at this point I need a way >>> to reproduce the problem and really understand where the problem is/was. >>> >>> I do build regularly this port on poudriere in two jails, one with X11 >>> set and one with it unset and never saw this happen. >>> >>> I suspect it happens when there is some misalignment with the X11 option >>> between ports (some with, some wothout), which is perfectly legitimate >>> but makes things difficult to cope with, since the ocaml package changes >>> it's suffix depending on that option. >>> >>> can you send me the full log for the failed build? I'd like to ask the >>> same from jlh if he still has it, so I can understand what is really >>> going on. >>> >>> >> I think the problem comes in when you build with poudriere because when >> you're building without the build will just select the correct options >> and build ocaml appropriately.. The build then continues as ocaml is >> installed. >> > > I have two poudriere jails I use to create package sets for some > machines of mine, one builds packages with the X11 option, the other > without (using OPTIONS_UNSET+=X11 among other options, which ensures all > packages will get the same option, unless overridden per package, which > I'm not doing in this case). > > I've just started those two from scratch for a verification, the one > without X11 just completed successfully building ocaml with correct > pkgname (with -nox11 suffix) and successfully build unison-nox11. I'll > also test these packages at runtime later just to be sure, but I'm > confident they are working correctly. > > But looking at the old logs I see no indication of these problems. I > have an explanation for both cases, I'll check them, but it requires > time for poudriere runs. > > >> When building with poudriere the build_depends looks for the package but >> the package selection process doesn't look for the -nox11 suffix as this >> is set in the makefile of the port and not in the package selection process. >> >> (If I explained that correctly ;-) ) >> > > Not exactly. Let's see (anyone correct me if I'm wrong in the explanation): > > with the port as it was, like this(trimmed): > > .if ${PORT_OPTIONS:MX11} > BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml > .else > BUILD_DEPENDS+= ocamlc:${PORTSDIR}/lang/ocaml-nox11 > .endif > > poudriere will see the port with a variable origin, depending on the X11 > option. If in the same poudriere run there is any other port which > depends on ocaml, but with a different origin (which is quite possible, > maybe some other port without an X11 option, which unconditionally > depends on ${PORTSDIR}/lang/ocaml) poudriere will notice this and report > conflicting origins. > > This is the problem jlh was seeing. I never noticed it since ocaml is > the only port depending on ocaml I ever build. > > The only solution to this one is not having a variable origin. > > Changing that to a fixed DEPENDS as the port is now, poudriere will look > into the ocaml port to discover it's pkg name, the x11 suffix for the > pkg filename isn't derived from the depends, but from the depended port > Makefile, so poudriere should in fact try to build the ocaml port with > the required pkgname automatically, named depending on the X11 option. > > This leads me to think there is some misalignment of the X11 option in > your setup, that's why I asked for the full log of the failed build, I > need to check the environment. > > >> Your package build initially was correct. I believe pkgng is wrong - >> either that or the whole build system needs to be updated so that the >> package installation looks at the set options and makefiles when >> deciding which package to find and install. Personally I thing ocaml >> (and similar) should not have the -nox11 options in the package name and >> should just install as a dependency.... but I expect that will cause >> other issues even more weird and wonderful. >> > > -nox11 as a suffix is quite common and compiled in defaults are a > documented use for PKGNAMESUFFIX, so I can't criticize that. > > Anyway poudriere uses the port build system to create dependency lists > and it does look inside the port Makefiles. Again, I suspect you are > building ocaml with X11 enabled and unison with X11 disabled. I'm not > sure I know a correct way to make it work. > > It will anyway generate a conflicting package set, since ocaml and > ocaml-nox11 conflict with each other. > > Having a variable origin for a port isn't a solution... The generated > packages would anyway have conflicts between them, which is a > consequence of the problem jlh reported. > > I'm doing some testing but if you could provide me the build log of the > failed unison build it would help. > > You maybe right .. somehow I have a misaligned make.conf for 93amd64 vs 93i386 (everything built without error until 93i386) root@93i386:~ # more /usr/local/etc/poudriere.d/93amd64-make.conf NO_WARNING_PKG_INSTALL_EOL=yes WITH_MODPERL2=yes OPTIONS_UNSET=X11 NLS DEFAULT_VERSIONS+=apache=2.2 TEX_DEFAULT=tetex root@93i386:~ # more /usr/local/etc/poudriere.d/93i386-make.conf NO_WARNING_PKG_INSTALL_EOL=yes WITH_MODPERL2=yes OPTIONS_UNSET=NLS DEFAULT_VERSIONS+=apache=2.2 perl5=5.16 PERL5_DEFAULT=5.16 TEX_DEFAULT=tetex WITH_NEW_MESA=yes root@93i386:~ # more /usr/local/etc/poudriere.d/93i386-options/net_unison/options # This file is auto-generated by 'make config'. # Options for unison-2.40.102_3 _OPTIONS_READ=unison-2.40.102_3 _FILE_COMPLETE_OPTIONS_LIST=DOCS X11 OPTIONS_FILE_UNSET+=DOCS OPTIONS_FILE_UNSET+=X11 Which means that if unsetting X11 on in the port and not globally ocaml is built with X11 and unison without - which poudriere will fail on when it tries to find the dependencies... which means my thoughts were exactly the opposite ... poudriere scans the dependency tree on startup which picks up the -nox11 package as a dependency then builds with x11 when it builds ocaml... Michelle -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 14:22:36 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2097B8B9; Sat, 21 Mar 2015 14:22:36 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A6FB6C7A; Sat, 21 Mar 2015 14:22:35 +0000 (UTC) Received: by wixw10 with SMTP id w10so14691883wix.0; Sat, 21 Mar 2015 07:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=VvMTqnVsU6DnGGyorDo+e7McjUXoBPQH6tFtlnXRtG4=; b=oKI80i9ygxD8qHRYMfKpTVh+zwY5vWi2dsJQ/YnFEWkbhy3E5K6p7ZzAsKyCINlYwp lNPJ1A8GpQBaTnDEHkNfTdwyDciHVPvfcVR53N3Tax6hFZWMpXmM3742Uaiq9Cgtyu5W pyN7390YpvklqPgon413HlV68UJUne+K3sI/O/9HRNVk/a63yeO2I0oHwybgiSXzl+RE 1342YL9I4mBbigX8wDABIuFKDEm97sXlt0FEKFu/u8hKpDDa+eSLXGQdFaiA8XdFxF+6 08auaPgrNvbfljsyS/KhtVVslQa/yifXdbYf0Er2vuGbUcOfdSBeRxuHO5i0i5YhkEOz vLEw== X-Received: by 10.194.236.200 with SMTP id uw8mr165143714wjc.10.1426947754159; Sat, 21 Mar 2015 07:22:34 -0700 (PDT) Received: from [10.0.0.5] (46-167-228-18.kmenet.cz. [46.167.228.18]) by mx.google.com with ESMTPSA id jt8sm2623128wid.4.2015.03.21.07.22.33 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Mar 2015 07:22:33 -0700 (PDT) Message-ID: <550D7EA9.70306@gmail.com> Date: Sat, 21 Mar 2015 15:22:33 +0100 From: =?ISO-8859-2?Q?=22Ing=2E_B=F8etislav_Kubesa=22?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: bdrewery@FreeBSD.org Subject: FreeBSD Port: openssh-portable-6.7.p1_1,1 / problem with %%ETCSSH%% variable Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 14:22:36 -0000 Hi, on two different FreeBSD systems I'm getting build this port with %%ETCSSH%% variable. Isn't some kind of bug maybe ? Example from rc.d script - openssh : if [ -f %%ETCSSH%%/ssh_host_key -a \ -f %%ETCSSH%%/ssh_host_dsa_key -a \ -f %%ETCSSH%%/ssh_host_rsa_key -a \ -f %%ETCSSH%%/ssh_host_ecdsa_key -a \ -f %%ETCSSH%%/ssh_host_ed25519_key ]; then return 0 Thank you. Regards, Bretislav Kubesa From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 14:50:47 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7AF2D97; Sat, 21 Mar 2015 14:50:47 +0000 (UTC) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 34FD6EE7; Sat, 21 Mar 2015 14:50:46 +0000 (UTC) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3l8PzN1D0RzZs8; Sat, 21 Mar 2015 15:50:40 +0100 (CET) Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id EKx8qhiQN8Z2; Sat, 21 Mar 2015 15:50:37 +0100 (CET) Received: from tommy.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Sat, 21 Mar 2015 15:50:37 +0100 (CET) Message-ID: <550D853C.7070303@FreeBSD.org> Date: Sat, 21 Mar 2015 15:50:36 +0100 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Michelle Sullivan Subject: Re: net/unison240 depends on lang/ocaml-nox11 References: <550D4CA0.8000606@sorbs.net> <550D61BF.3030403@FreeBSD.org> <550D636B.5020000@sorbs.net> <550D6D0F.7080401@FreeBSD.org> <550D7726.1060704@sorbs.net> In-Reply-To: <550D7726.1060704@sorbs.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Jeremie Le Hen , freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 14:50:47 -0000 On 03/21/15 14:50, Michelle Sullivan wrote: > Guido Falsi wrote: >> On 03/21/15 13:26, Michelle Sullivan wrote: >> >> >> This leads me to think there is some misalignment of the X11 option in >> your setup, that's why I asked for the full log of the failed build, I >> need to check the environment. >> [...] >> >> I'm doing some testing but if you could provide me the build log of the >> failed unison build it would help. >> >> > You maybe right .. somehow I have a misaligned make.conf for 93amd64 vs > 93i386 (everything built without error until 93i386) > > > root@93i386:~ # more /usr/local/etc/poudriere.d/93amd64-make.conf > NO_WARNING_PKG_INSTALL_EOL=yes > WITH_MODPERL2=yes > OPTIONS_UNSET=X11 NLS > DEFAULT_VERSIONS+=apache=2.2 > TEX_DEFAULT=tetex > root@93i386:~ # more /usr/local/etc/poudriere.d/93i386-make.conf > NO_WARNING_PKG_INSTALL_EOL=yes > WITH_MODPERL2=yes > OPTIONS_UNSET=NLS > DEFAULT_VERSIONS+=apache=2.2 perl5=5.16 > PERL5_DEFAULT=5.16 > TEX_DEFAULT=tetex > WITH_NEW_MESA=yes > root@93i386:~ # more > /usr/local/etc/poudriere.d/93i386-options/net_unison/options > # This file is auto-generated by 'make config'. > # Options for unison-2.40.102_3 > _OPTIONS_READ=unison-2.40.102_3 > _FILE_COMPLETE_OPTIONS_LIST=DOCS X11 > OPTIONS_FILE_UNSET+=DOCS > OPTIONS_FILE_UNSET+=X11 > > Which means that if unsetting X11 on in the port and not globally ocaml > is built with X11 and unison without - which poudriere will fail on when > it tries to find the dependencies... which means my thoughts were > exactly the opposite ... poudriere scans the dependency tree on startup > which picks up the -nox11 package as a dependency then builds with x11 > when it builds ocaml... Exactly. There are four cases: one asks for both with or without X11, works fine, in both. one asks for ocaml without X11 and unison with X11, this is wrong and cannot obviously work. last case is asking for ocaml with X11 and unison without. This could work in theory, and will work on a live system, but will not work in poudriere at present, due to ocaml changing it's package name dynamically. I don't know how to make it work with the present ports system. This fourth case anyway makes little sense to me anyway, once you have pulled in the X11 dependency why not use it in all ports which can take advantage of it? -- Guido Falsi From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 16:55:41 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 391C272F for ; Sat, 21 Mar 2015 16:55:41 +0000 (UTC) Received: from mx1.enfer-du-nord.net (mx1.enfer-du-nord.net [IPv6:2001:41d0:8:67d4:1:1:0:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 000FACCD for ; Sat, 21 Mar 2015 16:55:40 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: net/unison240 depends on lang/ocaml-nox11 From: Michael Grimm In-Reply-To: <550D853C.7070303@FreeBSD.org> Date: Sat, 21 Mar 2015 17:55:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <550D4CA0.8000606@sorbs.net> <550D61BF.3030403@FreeBSD.org> <550D636B.5020000@sorbs.net> <550D6D0F.7080401@FreeBSD.org> <550D7726.1060704@sorbs.net> <550D853C.7070303@FreeBSD.org> To: freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.6 at mail.kaan-bock.invalid X-Virus-Status: Clean X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 16:55:41 -0000 > On 21.03.2015, at 15:50, Guido Falsi wrote: > On 03/21/15 14:50, Michelle Sullivan wrote: >> Which means that if unsetting X11 on in the port and not globally = ocaml >> is built with X11 and unison without - which poudriere will fail on = when >> it tries to find the dependencies... which means my thoughts were >> exactly the opposite ... poudriere scans the dependency tree on = startup >> which picks up the -nox11 package as a dependency then builds with = x11 >> when it builds ocaml... >=20 > Exactly. >=20 > There are four cases: >=20 > one asks for both with or without X11, works fine, in both. >=20 > one asks for ocaml without X11 and unison with X11, this is wrong and > cannot obviously work. >=20 > last case is asking for ocaml with X11 and unison without. This could > work in theory, and will work on a live system, but will not work in > poudriere at present, due to ocaml changing it's package name > dynamically. I don't know how to make it work with the present ports = system. >=20 > This fourth case anyway makes little sense to me anyway, once you have > pulled in the X11 dependency why not use it in all ports which can = take > advantage of it? I recently (after last upgrade of poudriere-devel, although I do not = know if that is the cause) ran into a comparable issue with unison = without X11 : | MWN> cat /usr/local/etc/poudriere.d/stable10-make.conf | WITHOUT_X11=3Dyes [...] | MWN> pkg info | grep unison | unison-nox11-2.48.3_1 User-level file synchronization = tool (without x11 stuff) poudriere's build failed with: | MWN> cat /.../logs/ocaml-nox11-4.01.0_4.log | ---Begin OPTIONS List--- | =3D=3D=3D> The following configuration options are available = for ocaml-nox11-4.01.0_4: | DOCS=3Don: Build and/or install documentation | EXAMPLES=3Don: Build and/or install examples | THREADS=3Don: Threading support ----> | TK=3Don: LablTk library (requires X11 support) | X11=3Doff: X11 (graphics) support | =3D=3D=3D> Use 'make config' to modify these settings | ---End OPTIONS List--- [...] | ---End make.conf--- | =3D=3D=3D=3D>> Ignoring lang/ocaml: requires X11 support to = build TK bindings | build of lang/ocaml ended at Sat Mar 21 17:08:37 CET 2015 That's weird, ocaml-nox11 defaults to "TK=3Don" which requires X11 = support. Bug or feature? I explicitly had to to unset "LablTk library (requires X11 support)" to = get this issue solved. Regards, Michael From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 17:09:48 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0EBA2BF1; Sat, 21 Mar 2015 17:09:48 +0000 (UTC) Received: from newton.apeiron.net (newton.apeiron.net [IPv6:2607:f2f8:ae14::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.apeiron.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DF7D8E1A; Sat, 21 Mar 2015 17:09:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at apeiron.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=apeiron.net; s=newton; t=1426810273; bh=BWYHtTPieNYu+uQF6SP/kn+Gp8GIo7Btj227XNguD/4=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=ooOfTJfnFJSEjzueiK9xBW0aquon4N8xDEHhZ1OGgjZXRUCenrBd3m2bBV4UxbZ4A mrOQcsoEAnvyy88CD+nX8a99m/2gsuiHPMhZWG4HaHNbxuE4zQMke+bh3YuRdCbk4g ludubcdHFT/1SJDIccROuVI6k9gFk9EOIhlqCm1Q= Received: from [10.207.0.16] (c-69-253-3-227.hsd1.pa.comcast.net [69.253.3.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mainland) by newton.apeiron.net (Postfix) with ESMTPSA id 01E869D47; Thu, 19 Mar 2015 17:11:12 -0700 (PDT) Message-ID: <550B65A1.9080402@apeiron.net> Date: Thu, 19 Mar 2015 20:11:13 -0400 From: Geoffrey Mainland User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 Newsgroups: gmane.os.freebsd.devel.ports To: Guido Falsi , Jeremie Le Hen Subject: Re: net/unison240 depends on lang/ocaml-nox11 References: <5507555C.7030508@FreeBSD.org> <5507F80F.70609@FreeBSD.org> <55080F30.9010104@FreeBSD.org> In-Reply-To: <55080F30.9010104@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 17:09:48 -0000 On 03/17/2015 07:25 AM, Guido Falsi wrote: > On 03/17/15 11:44, Jeremie Le Hen wrote: >> On Tue, Mar 17, 2015 at 10:46 AM, Guido Falsi wrote: >>> On 03/17/15 09:31, Jeremie Le Hen wrote: >>>> On Mon, Mar 16, 2015 at 11:12 PM, Guido Falsi wrote: >>>>> On 03/16/15 22:37, Jeremie Le Hen wrote: >>>>>> Actually, I've just realized that I fixed net/unison232 in my local tree :o). >>>>>> >>>>>> Would you mind submitting it and applying the same for unison240? >>>>>> >>>>> >>>>> I never noticed this since it never happened to me and nobody else >>>>> reported it. >>>>> >>>>> Anyway now that you draw my attention, yes, it needs fixing. >>>>> >>>>> Your patch looks correct, but please allow me a little time for some >>>>> testing. >>>> >>>> OK thanks! :) >>> >>> Just committed it. Thanks again for reporting the issue! >> >> Thanks! >> >> I don't want to abuse your time, but "make checksum" is broken on >> net/unison240 :). >> > > Looks like distfiles were rerolled. 2.48 has the same problem. > > Will commit updated checksums shortly! > > Thanks again. I still get the same error Jeremie was getting with poudriere. I think the BUILD_DEPENDS should not be set unconditionally. The below patch fixes the problem for me. Does this look correct to you? Thanks, Geoff diff --git a/net/unison/Makefile b/net/unison/Makefile index 7404beb..461ebab 100644 --- a/net/unison/Makefile +++ b/net/unison/Makefile @@ -15,7 +15,7 @@ COMMENT?= User-level file synchronization tool LICENSE= GPLv3 -BUILD_DEPENDS= ocamlc:${PORTSDIR}/lang/ocaml + PLIST_SUB= PORTVERSION=${PORTVERSION} USES= gmake @@ -38,11 +38,13 @@ OPTIONS_DEFAULT?= DOCS X11 .if ${PORT_OPTIONS:MX11} MAKE_ARGS+= UISTYLE=gtk2 PLIST_SUB+= TEXT="" +BUILD_DEPENDS= ocamlc:${PORTSDIR}/lang/ocaml BUILD_DEPENDS+= lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 \ icotool:${PORTSDIR}/graphics/icoutils RUN_DEPENDS+= lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 SUB_FILES+= ${PORTNAME}.desktop .else +BUILD_DEPENDS= ocamlc:${PORTSDIR}/lang/ocaml-nox11 MAKE_ARGS+= UISTYLE=text PLIST_SUB+= TEXT="@comment " PKGMESSAGE= ${PKGDIR}/pkg-message.nox11 From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 17:41:15 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD6E5EC7; Sat, 21 Mar 2015 17:41:15 +0000 (UTC) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 490FC16A; Sat, 21 Mar 2015 17:41:14 +0000 (UTC) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3l8Tm357WxzZs8; Sat, 21 Mar 2015 18:41:07 +0100 (CET) Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id z33pHZv37vzQ; Sat, 21 Mar 2015 18:41:04 +0100 (CET) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Sat, 21 Mar 2015 18:41:04 +0100 (CET) Message-ID: <550DAD30.4080905@FreeBSD.org> Date: Sat, 21 Mar 2015 18:41:04 +0100 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Geoffrey Mainland , Jeremie Le Hen Subject: Re: net/unison240 depends on lang/ocaml-nox11 References: <5507555C.7030508@FreeBSD.org> <5507F80F.70609@FreeBSD.org> <55080F30.9010104@FreeBSD.org> <550B65A1.9080402@apeiron.net> In-Reply-To: <550B65A1.9080402@apeiron.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 17:41:15 -0000 On 03/20/15 01:11, Geoffrey Mainland wrote: > On 03/17/2015 07:25 AM, Guido Falsi wrote: >> On 03/17/15 11:44, Jeremie Le Hen wrote: >>> On Tue, Mar 17, 2015 at 10:46 AM, Guido Falsi wrote: >>>> On 03/17/15 09:31, Jeremie Le Hen wrote: >>>>> On Mon, Mar 16, 2015 at 11:12 PM, Guido Falsi wrote: >>>>>> On 03/16/15 22:37, Jeremie Le Hen wrote: >>>>>>> Actually, I've just realized that I fixed net/unison232 in my local tree :o). >>>>>>> >>>>>>> Would you mind submitting it and applying the same for unison240? >>>>>>> >>>>>> >>>>>> I never noticed this since it never happened to me and nobody else >>>>>> reported it. >>>>>> >>>>>> Anyway now that you draw my attention, yes, it needs fixing. >>>>>> >>>>>> Your patch looks correct, but please allow me a little time for some >>>>>> testing. >>>>> >>>>> OK thanks! :) >>>> >>>> Just committed it. Thanks again for reporting the issue! >>> >>> Thanks! >>> >>> I don't want to abuse your time, but "make checksum" is broken on >>> net/unison240 :). >>> >> >> Looks like distfiles were rerolled. 2.48 has the same problem. >> >> Will commit updated checksums shortly! >> >> Thanks again. > > I still get the same error Jeremie was getting with poudriere. > > I think the BUILD_DEPENDS should not be set unconditionally. The below > patch fixes the problem for me. > > Does this look correct to you? > > Thanks, > Geoff > > diff --git a/net/unison/Makefile b/net/unison/Makefile > index 7404beb..461ebab 100644 > --- a/net/unison/Makefile > +++ b/net/unison/Makefile > @@ -15,7 +15,7 @@ COMMENT?= User-level file synchronization tool > > LICENSE= GPLv3 > > -BUILD_DEPENDS= ocamlc:${PORTSDIR}/lang/ocaml > + > > PLIST_SUB= PORTVERSION=${PORTVERSION} > USES= gmake > @@ -38,11 +38,13 @@ OPTIONS_DEFAULT?= DOCS X11 > .if ${PORT_OPTIONS:MX11} > MAKE_ARGS+= UISTYLE=gtk2 > PLIST_SUB+= TEXT="" > +BUILD_DEPENDS= ocamlc:${PORTSDIR}/lang/ocaml > BUILD_DEPENDS+= lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 \ > icotool:${PORTSDIR}/graphics/icoutils > RUN_DEPENDS+= lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 > SUB_FILES+= ${PORTNAME}.desktop > .else > +BUILD_DEPENDS= ocamlc:${PORTSDIR}/lang/ocaml-nox11 > MAKE_ARGS+= UISTYLE=text > PLIST_SUB+= TEXT="@comment " > PKGMESSAGE= ${PKGDIR}/pkg-message.nox11 > This is the same as the port was before the latest patch. (having BUILD_DEPENDS= followed by BUILD_DEPENDS+= is semantically the same as one unified BUILD_DEPENDS+=) Please send me your build log. I need to understand what is going on. Can you also tell me what other ports you are building in the same poudriere run together with unison? I'm interested in other ports which depend on ocaml. Maybe there is some other port in the tree with the same problem unison had, which are unmasked by my latest patch. BTW I'm going to investigate the option of modifying ocaml port behavior, I'm not sure it is really correct anymore. -- Guido Falsi From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 17:58:24 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8D13381; Sat, 21 Mar 2015 17:58:24 +0000 (UTC) Received: from newton.apeiron.net (newton.apeiron.net [208.79.95.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.apeiron.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B484C33D; Sat, 21 Mar 2015 17:58:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at apeiron.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=apeiron.net; s=newton; t=1426960703; bh=XtUfPY2z2gTEnfNU/TuZHfQ//39pLJ55ZdAE5gTDGrA=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=2Z2peMXCwKl7/5uhuwQRPa2FcvkdJOYQC8DYE0XoQFmt/onHzbO4fSFPO/n958mim IyLNasnMYSiroYMQhQ1oYUm/ez6gX1xbeNvkeE2WSn3Dimd9SYvebZ7aGGoexzDE+j uMhotK1aR3I6Wlp1kd5Gx3SLFXlWiV/OnBiyNtrI= Received: from [192.168.42.70] (70-36-146-244.dsl.dynamic.fusionbroadband.com [70.36.146.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mainland) by newton.apeiron.net (Postfix) with ESMTPSA id C6C1893DD; Sat, 21 Mar 2015 10:58:22 -0700 (PDT) Message-ID: <550DB13D.7020005@apeiron.net> Date: Sat, 21 Mar 2015 10:58:21 -0700 From: Geoffrey Mainland User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Guido Falsi , Jeremie Le Hen Subject: Re: net/unison240 depends on lang/ocaml-nox11 References: <5507555C.7030508@FreeBSD.org> <5507F80F.70609@FreeBSD.org> <55080F30.9010104@FreeBSD.org> <550B65A1.9080402@apeiron.net> <550DAD30.4080905@FreeBSD.org> In-Reply-To: <550DAD30.4080905@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 17:58:25 -0000 On 3/21/15 10:41 AM, Guido Falsi wrote: > On 03/20/15 01:11, Geoffrey Mainland wrote: >> On 03/17/2015 07:25 AM, Guido Falsi wrote: >>> On 03/17/15 11:44, Jeremie Le Hen wrote: >>>> On Tue, Mar 17, 2015 at 10:46 AM, Guido Falsi wrote: >>>>> On 03/17/15 09:31, Jeremie Le Hen wrote: >>>>>> On Mon, Mar 16, 2015 at 11:12 PM, Guido Falsi wrote: >>>>>>> On 03/16/15 22:37, Jeremie Le Hen wrote: >>>>>>>> Actually, I've just realized that I fixed net/unison232 in my local tree :o). >>>>>>>> >>>>>>>> Would you mind submitting it and applying the same for unison240? >>>>>>>> >>>>>>> I never noticed this since it never happened to me and nobody else >>>>>>> reported it. >>>>>>> >>>>>>> Anyway now that you draw my attention, yes, it needs fixing. >>>>>>> >>>>>>> Your patch looks correct, but please allow me a little time for some >>>>>>> testing. >>>>>> OK thanks! :) >>>>> Just committed it. Thanks again for reporting the issue! >>>> Thanks! >>>> >>>> I don't want to abuse your time, but "make checksum" is broken on >>>> net/unison240 :). >>>> >>> Looks like distfiles were rerolled. 2.48 has the same problem. >>> >>> Will commit updated checksums shortly! >>> >>> Thanks again. >> I still get the same error Jeremie was getting with poudriere. >> >> I think the BUILD_DEPENDS should not be set unconditionally. The below >> patch fixes the problem for me. >> >> Does this look correct to you? >> >> Thanks, >> Geoff >> >> diff --git a/net/unison/Makefile b/net/unison/Makefile >> index 7404beb..461ebab 100644 >> --- a/net/unison/Makefile >> +++ b/net/unison/Makefile >> @@ -15,7 +15,7 @@ COMMENT?= User-level file synchronization tool >> >> LICENSE= GPLv3 >> >> -BUILD_DEPENDS= ocamlc:${PORTSDIR}/lang/ocaml >> + >> >> PLIST_SUB= PORTVERSION=${PORTVERSION} >> USES= gmake >> @@ -38,11 +38,13 @@ OPTIONS_DEFAULT?= DOCS X11 >> .if ${PORT_OPTIONS:MX11} >> MAKE_ARGS+= UISTYLE=gtk2 >> PLIST_SUB+= TEXT="" >> +BUILD_DEPENDS= ocamlc:${PORTSDIR}/lang/ocaml >> BUILD_DEPENDS+= lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 \ >> icotool:${PORTSDIR}/graphics/icoutils >> RUN_DEPENDS+= lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 >> SUB_FILES+= ${PORTNAME}.desktop >> .else >> +BUILD_DEPENDS= ocamlc:${PORTSDIR}/lang/ocaml-nox11 >> MAKE_ARGS+= UISTYLE=text >> PLIST_SUB+= TEXT="@comment " >> PKGMESSAGE= ${PKGDIR}/pkg-message.nox11 >> > This is the same as the port was before the latest patch. > > (having BUILD_DEPENDS= followed by BUILD_DEPENDS+= is semantically the > same as one unified BUILD_DEPENDS+=) > > Please send me your build log. I need to understand what is going on. > Can you also tell me what other ports you are building in the same > poudriere run together with unison? I'm interested in other ports which > depend on ocaml. Maybe there is some other port in the tree with the > same problem unison had, which are unmasked by my latest patch. > > BTW I'm going to investigate the option of modifying ocaml port > behavior, I'm not sure it is really correct anymore. > I can send you the build logs, but no, it's not the same as before the patch. Note the dependency is changed to lang/ocaml-nox11 instead of lang/ocaml. That is, we depend on lang/ocaml when the X11 option is enabled, and lang/ocaml-nox11 when the X11 option is not enabled. If you still think there is no difference, I will send you full build logs both with and without the patch. Thanks, Geoff From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 18:03:03 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 943AA464; Sat, 21 Mar 2015 18:03:03 +0000 (UTC) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 38F385EC; Sat, 21 Mar 2015 18:03:02 +0000 (UTC) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3l8VF62K1kzZs9; Sat, 21 Mar 2015 19:02:50 +0100 (CET) Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id nFa2PO4yxvPI; Sat, 21 Mar 2015 19:02:48 +0100 (CET) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Sat, 21 Mar 2015 19:02:48 +0100 (CET) Message-ID: <550DB247.2050800@FreeBSD.org> Date: Sat, 21 Mar 2015 19:02:47 +0100 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Geoffrey Mainland , Jeremie Le Hen Subject: Re: net/unison240 depends on lang/ocaml-nox11 References: <5507555C.7030508@FreeBSD.org> <5507F80F.70609@FreeBSD.org> <55080F30.9010104@FreeBSD.org> <550B65A1.9080402@apeiron.net> <550DAD30.4080905@FreeBSD.org> <550DB13D.7020005@apeiron.net> In-Reply-To: <550DB13D.7020005@apeiron.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 18:03:03 -0000 On 03/21/15 18:58, Geoffrey Mainland wrote: > On 3/21/15 10:41 AM, Guido Falsi wrote: >> On 03/20/15 01:11, Geoffrey Mainland wrote: >>> On 03/17/2015 07:25 AM, Guido Falsi wrote: >>>> On 03/17/15 11:44, Jeremie Le Hen wrote: >>>>> On Tue, Mar 17, 2015 at 10:46 AM, Guido Falsi wrote: >>>>>> On 03/17/15 09:31, Jeremie Le Hen wrote: >>>>>>> On Mon, Mar 16, 2015 at 11:12 PM, Guido Falsi wrote: >>>>>>>> On 03/16/15 22:37, Jeremie Le Hen wrote: >>>>>>>>> Actually, I've just realized that I fixed net/unison232 in my local tree :o). >>>>>>>>> >>>>>>>>> Would you mind submitting it and applying the same for unison240? >>>>>>>>> >>>>>>>> I never noticed this since it never happened to me and nobody else >>>>>>>> reported it. >>>>>>>> >>>>>>>> Anyway now that you draw my attention, yes, it needs fixing. >>>>>>>> >>>>>>>> Your patch looks correct, but please allow me a little time for some >>>>>>>> testing. >>>>>>> OK thanks! :) >>>>>> Just committed it. Thanks again for reporting the issue! >>>>> Thanks! >>>>> >>>>> I don't want to abuse your time, but "make checksum" is broken on >>>>> net/unison240 :). >>>>> >>>> Looks like distfiles were rerolled. 2.48 has the same problem. >>>> >>>> Will commit updated checksums shortly! >>>> >>>> Thanks again. >>> I still get the same error Jeremie was getting with poudriere. >>> >>> I think the BUILD_DEPENDS should not be set unconditionally. The below >>> patch fixes the problem for me. >>> >>> Does this look correct to you? >>> >>> Thanks, >>> Geoff >>> >>> diff --git a/net/unison/Makefile b/net/unison/Makefile >>> index 7404beb..461ebab 100644 >>> --- a/net/unison/Makefile >>> +++ b/net/unison/Makefile >>> @@ -15,7 +15,7 @@ COMMENT?= User-level file synchronization tool >>> >>> LICENSE= GPLv3 >>> >>> -BUILD_DEPENDS= ocamlc:${PORTSDIR}/lang/ocaml >>> + >>> >>> PLIST_SUB= PORTVERSION=${PORTVERSION} >>> USES= gmake >>> @@ -38,11 +38,13 @@ OPTIONS_DEFAULT?= DOCS X11 >>> .if ${PORT_OPTIONS:MX11} >>> MAKE_ARGS+= UISTYLE=gtk2 >>> PLIST_SUB+= TEXT="" >>> +BUILD_DEPENDS= ocamlc:${PORTSDIR}/lang/ocaml >>> BUILD_DEPENDS+= lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 \ >>> icotool:${PORTSDIR}/graphics/icoutils >>> RUN_DEPENDS+= lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 >>> SUB_FILES+= ${PORTNAME}.desktop >>> .else >>> +BUILD_DEPENDS= ocamlc:${PORTSDIR}/lang/ocaml-nox11 >>> MAKE_ARGS+= UISTYLE=text >>> PLIST_SUB+= TEXT="@comment " >>> PKGMESSAGE= ${PKGDIR}/pkg-message.nox11 >>> >> This is the same as the port was before the latest patch. >> >> (having BUILD_DEPENDS= followed by BUILD_DEPENDS+= is semantically the >> same as one unified BUILD_DEPENDS+=) >> >> Please send me your build log. I need to understand what is going on. >> Can you also tell me what other ports you are building in the same >> poudriere run together with unison? I'm interested in other ports which >> depend on ocaml. Maybe there is some other port in the tree with the >> same problem unison had, which are unmasked by my latest patch. >> >> BTW I'm going to investigate the option of modifying ocaml port >> behavior, I'm not sure it is really correct anymore. >> > > I can send you the build logs, but no, it's not the same as before the > patch. > > Note the dependency is changed to lang/ocaml-nox11 instead of > lang/ocaml. That is, we depend on lang/ocaml when the X11 option is > enabled, and lang/ocaml-nox11 when the X11 option is not enabled. It is not the same as teh port is now, but it is the same as the port was before r381478, you can check this diff: https://svnweb.freebsd.org/ports/head/net/unison240/Makefile?r1=381478&r2=381477 (other changes are there too, but irrelevant for the depends matter) > > If you still think there is no difference, I will send you full build > logs both with and without the patch. I'd need the logs anyway, since I don't know what the cause of the error you are seeing is. I also need to know if in the same poudriere run you were building any other port depending on ocaml. -- Guido Falsi From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 18:10:10 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF35457F for ; Sat, 21 Mar 2015 18:10:09 +0000 (UTC) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7A85F634 for ; Sat, 21 Mar 2015 18:10:08 +0000 (UTC) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3l8VPW2bPtzZrj; Sat, 21 Mar 2015 19:10:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:subject:subject:mime-version:user-agent:from:from :date:date:message-id:received:received; s=mail; t=1426961405; x=1428775806; bh=UtXHZehNUAcYoHlrweZhSroh3CdniIVVsB+KaL5886A=; b= CPJ3BY99IDNzx6z7E/EUQCOF5gsVVqpj/yPWJnxzY00a1R0bCVwPiqCyrKeUNHys QLUzk7yWRkqkiomjfJ4ifZqYJByz3MsiiWBa0uRABD/c3qLq7eoXoRPihBmlx5tt BRr+0OLzxG1hUmTiqvihQYRQtJo5v6XTWdzbfVqtuZU= Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id U41Zn4czDdEu; Sat, 21 Mar 2015 19:10:05 +0100 (CET) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Sat, 21 Mar 2015 19:10:05 +0100 (CET) Message-ID: <550DB3FD.7070006@madpilot.net> Date: Sat, 21 Mar 2015 19:10:05 +0100 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Michael Grimm , freebsd-ports@freebsd.org Subject: Re: net/unison240 depends on lang/ocaml-nox11 References: <550D4CA0.8000606@sorbs.net> <550D61BF.3030403@FreeBSD.org> <550D636B.5020000@sorbs.net> <550D6D0F.7080401@FreeBSD.org> <550D7726.1060704@sorbs.net> <550D853C.7070303@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 18:10:10 -0000 On 03/21/15 17:55, Michael Grimm wrote: > >> On 21.03.2015, at 15:50, Guido Falsi wrote: >> On 03/21/15 14:50, Michelle Sullivan wrote: > > >>> Which means that if unsetting X11 on in the port and not globally ocaml >>> is built with X11 and unison without - which poudriere will fail on when >>> it tries to find the dependencies... which means my thoughts were >>> exactly the opposite ... poudriere scans the dependency tree on startup >>> which picks up the -nox11 package as a dependency then builds with x11 >>> when it builds ocaml... >> >> Exactly. >> >> There are four cases: >> >> one asks for both with or without X11, works fine, in both. >> >> one asks for ocaml without X11 and unison with X11, this is wrong and >> cannot obviously work. >> >> last case is asking for ocaml with X11 and unison without. This could >> work in theory, and will work on a live system, but will not work in >> poudriere at present, due to ocaml changing it's package name >> dynamically. I don't know how to make it work with the present ports system. >> >> This fourth case anyway makes little sense to me anyway, once you have >> pulled in the X11 dependency why not use it in all ports which can take >> advantage of it? > > > I recently (after last upgrade of poudriere-devel, although I do not know if that is the cause) ran into a comparable issue with unison without X11 : > > | MWN> cat /usr/local/etc/poudriere.d/stable10-make.conf > | WITHOUT_X11=yes > [...] I don't think old style WITH_/WITHOUT_ flags are supported anymore. Looking at the code you should in fact get a warning about this. You really should move to the new style OPTIONS_UNSET/OPTIONS_SET. You can find some documentation in /usr/ports/Mk/bsd.options.mk > > | MWN> pkg info | grep unison > | unison-nox11-2.48.3_1 User-level file synchronization tool (without x11 stuff) > > poudriere's build failed with: > > | MWN> cat /.../logs/ocaml-nox11-4.01.0_4.log > | ---Begin OPTIONS List--- > | ===> The following configuration options are available for ocaml-nox11-4.01.0_4: > | DOCS=on: Build and/or install documentation > | EXAMPLES=on: Build and/or install examples > | THREADS=on: Threading support > ----> | TK=on: LablTk library (requires X11 support) > | X11=off: X11 (graphics) support > | ===> Use 'make config' to modify these settings > | ---End OPTIONS List--- > [...] > | ---End make.conf--- > | ====>> Ignoring lang/ocaml: requires X11 support to build TK bindings > | build of lang/ocaml ended at Sat Mar 21 17:08:37 CET 2015 > > That's weird, ocaml-nox11 defaults to "TK=on" which requires X11 support. Bug or feature? You sure you have no option directory with per port options enabling TK? Options activate per port do override WITH_/WITHOUT_ and OPTIONS_UNSET/OPTIONS_SET. -- Guido Falsi From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 19:28:53 2015 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0A0FF9F for ; Sat, 21 Mar 2015 19:28:53 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E3DF5E2D for ; Sat, 21 Mar 2015 19:28:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id t2LJSqjW055769 for ; Sat, 21 Mar 2015 19:28:52 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id t2LJSqGE055767 for ports@FreeBSD.org; Sat, 21 Mar 2015 19:28:52 GMT (envelope-from bdrewery) Received: (qmail 79467 invoked from network); 21 Mar 2015 14:28:50 -0500 Received: from unknown (HELO blah) (freebsd@shatow.net@10.10.1.90) by sweb.xzibition.com with ESMTPA; 21 Mar 2015 14:28:50 -0500 Message-ID: <550DC672.5040107@FreeBSD.org> Date: Sat, 21 Mar 2015 14:28:50 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: =?ISO-8859-2?Q?=22Ing=2E_B=F8etislav_Kubesa=22?= Subject: Re: FreeBSD Port: openssh-portable-6.7.p1_1, 1 / problem with %%ETCSSH%% variable References: <550D7EA9.70306@gmail.com> In-Reply-To: <550D7EA9.70306@gmail.com> Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: ports@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 19:28:53 -0000 On 3/21/15 9:22 AM, "Ing. Bøetislav Kubesa" wrote: > Hi, > > on two different FreeBSD systems I'm getting build this port with > %%ETCSSH%% variable. > Isn't some kind of bug maybe ? > > Example from rc.d script - openssh : > > if [ -f %%ETCSSH%%/ssh_host_key -a \ > -f %%ETCSSH%%/ssh_host_dsa_key -a \ > -f %%ETCSSH%%/ssh_host_rsa_key -a \ > -f %%ETCSSH%%/ssh_host_ecdsa_key -a \ > -f %%ETCSSH%%/ssh_host_ed25519_key ]; then > return 0 > > Thank you. > > Regards, > Bretislav Kubesa Sorry about this. It should be fixed now. -- Regards, Bryan Drewery From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 19:30:03 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4AC53238; Sat, 21 Mar 2015 19:30:03 +0000 (UTC) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C1455E44; Sat, 21 Mar 2015 19:30:02 +0000 (UTC) Received: by labto5 with SMTP id to5so994702lab.0; Sat, 21 Mar 2015 12:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=zmnkTem4JhvHxha8MNyhSo2aD2S6cbAFoPhULw+EDH0=; b=HtAvxpJPMqpbQ3wYKRnKjj1ioN1jYaHPEr5FYZ6IdYQiEpen3glIxXXszl7ChQaEOh lPWMD5Besh4iiJ6zxNJfF02t7XVRL38eM5DbZ+WCaCEyedX2LUcy3B4Up89QT20jOrCx gkWFNpCGwLzmavGdAlK3ZPwz+olR3fGDSnebF01tC3WLlfXuCUMuc6AmRjjY/QCW+71D o73pk9p/t+DJdEKDb9JAjEvArOkMFDmyO8oNnMk03QrLqs4tFI5jXAtcS/0MKGQui6eO PiZGwDL8/l/R8cmT2PrxxtCG795/hFYKPrzaIEX8WAh2xFMZsowjggWzrm8m+jATcGmS E2GQ== X-Received: by 10.112.50.38 with SMTP id z6mr56783816lbn.122.1426966200816; Sat, 21 Mar 2015 12:30:00 -0700 (PDT) MIME-Version: 1.0 References: <550D7EA9.70306@gmail.com> <550DC672.5040107@FreeBSD.org> In-Reply-To: <550DC672.5040107@FreeBSD.org> From: "Ing. Bretislav Kubesa" Date: Sat, 21 Mar 2015 19:30:00 +0000 Message-ID: Subject: Re: FreeBSD Port: openssh-portable-6.7.p1_1,1 / problem with %%ETCSSH%% variable To: Bryan Drewery Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 19:30:03 -0000 No problem at all, thank you :-) Dne so 21. 3. 2015 20:28 u=C5=BEivatel Bryan Drewery napsal: > On 3/21/15 9:22 AM, "Ing. B=C5=99etislav Kubesa" wrote: > > Hi, > > > > on two different FreeBSD systems I'm getting build this port with > > %%ETCSSH%% variable. > > Isn't some kind of bug maybe ? > > > > Example from rc.d script - openssh : > > > > if [ -f %%ETCSSH%%/ssh_host_key -a \ > > -f %%ETCSSH%%/ssh_host_dsa_key -a \ > > -f %%ETCSSH%%/ssh_host_rsa_key -a \ > > -f %%ETCSSH%%/ssh_host_ecdsa_key -a \ > > -f %%ETCSSH%%/ssh_host_ed25519_key ]; then > > return 0 > > > > Thank you. > > > > Regards, > > Bretislav Kubesa > > Sorry about this. It should be fixed now. > > -- > Regards, > Bryan Drewery > From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 20:53:36 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FCE9305 for ; Sat, 21 Mar 2015 20:53:36 +0000 (UTC) Received: from mx2.enfer-du-nord.net (mx2.enfer-du-nord.net [IPv6:2001:41d0:8:6a29:1:1:0:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 55F78A24 for ; Sat, 21 Mar 2015 20:53:36 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: net/unison240 depends on lang/ocaml-nox11 From: Michael Grimm In-Reply-To: <550DB3FD.7070006@madpilot.net> Date: Sat, 21 Mar 2015 21:53:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <550D4CA0.8000606@sorbs.net> <550D61BF.3030403@FreeBSD.org> <550D636B.5020000@sorbs.net> <550D6D0F.7080401@FreeBSD.org> <550D7726.1060704@sorbs.net> <550D853C.7070303@FreeBSD.org> <550DB3FD.7070006@madpilot.net> To: freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.6 at mail.mer-waases.invalid X-Virus-Status: Clean X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 20:53:36 -0000 On 21.03.2015, at 19:10, Guido Falsi wrote: > On 03/21/15 17:55, Michael Grimm wrote: >> I recently (after last upgrade of poudriere-devel, although I do not = know if that is the cause) ran into a comparable issue with unison = without X11 : >>=20 >> | MWN> cat /usr/local/etc/poudriere.d/stable10-make.conf >> | WITHOUT_X11=3Dyes >> [...] >=20 > I don't think old style WITH_/WITHOUT_ flags are supported anymore. > Looking at the code you should in fact get a warning about this. Hmm, not that I am aware of. But I will have a closer look. But! = Commenting that "WITHOUT_X11=3Dyes" has been recognized by poudriere: = the unison-nox11 port could be compiled successfully with default ocaml = settings. > You really should move to the new style OPTIONS_UNSET/OPTIONS_SET. > You can find some documentation in /usr/ports/Mk/bsd.options.mk Thanks for that pointer. >> | MWN> pkg info | grep unison >> | unison-nox11-2.48.3_1 User-level file synchronization = tool (without x11 stuff) >>=20 >> poudriere's build failed with: >>=20 >> | MWN> cat /.../logs/ocaml-nox11-4.01.0_4.log >> | ---Begin OPTIONS List--- >> | =3D=3D=3D> The following configuration options are available = for ocaml-nox11-4.01.0_4: >> | DOCS=3Don: Build and/or install documentation >> | EXAMPLES=3Don: Build and/or install examples >> | THREADS=3Don: Threading support >> ----> | TK=3Don: LablTk library (requires X11 support) >> | X11=3Doff: X11 (graphics) support >> | =3D=3D=3D> Use 'make config' to modify these settings >> | ---End OPTIONS List--- >> [...] >> | ---End make.conf--- >> | =3D=3D=3D=3D>> Ignoring lang/ocaml: requires X11 support to = build TK bindings >> | build of lang/ocaml ended at Sat Mar 21 17:08:37 CET 2015 >>=20 >> That's weird, ocaml-nox11 defaults to "TK=3Don" which requires X11 = support. Bug or feature? >=20 > You sure you have no option directory with per port options enabling = TK? Yes, I'm sure that I haven't had an option directory with per port = options en/disabling TK set. > Options activate per port do override WITH_/WITHOUT_ and > OPTIONS_UNSET/OPTIONS_SET. Only, *after* setting "OPTIONS_FILE_UNSET+=3DTK" in lang_ocaml/options, = I was able to get unison-nox11 port compiled by poudriere successfully. = *Before* I haven't had any lang_ocaml/options settings at all. And = because the default setting of ocaml-nox11 is "OPTIONS_FILE_SET+=3DTK" = -which requires X11 support (!)- poudriere fails compiling ocaml-nox11 = port. (If I am not mistaken miserably.) Regards, Michael From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 23:08:07 2015 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BE3BB40; Sat, 21 Mar 2015 23:08:07 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B4FC85F; Sat, 21 Mar 2015 23:08:07 +0000 (UTC) Received: by wgs2 with SMTP id 2so10382915wgs.1; Sat, 21 Mar 2015 16:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=GV9fyOamMgVnzrFAFv6J0gkxDmW5BnRC94Uurokl3m0=; b=yH4kq7+4miWrdLQaa+J4A39zuXjo12UZE5c8o/brEFvQHcgeLAbaxFFUoWVaLekhib 8e/w7oK497icrPZWm4zhkxouR9vkQBlAdf/Sd1szNm10GaJwbGw1F/UcRCNE/F2AYJXW Z52wZfe8pyO8nOHZGzlL3arTSXOM8xPFNa+TEIahE5OmNtS1o/VuqDB2RZ7ey5PN2vUQ +WfYaEnxnxK3fjZDOLuGwM1O1k6AItdfjFKhfyk17XHKafy3SjkrmKbn2qa7576p1CHG To2fwZciyP5c2tVfBPUq0lWH2pcJWAO8GsDHiv4bDZYBo7DxUDkaPPrLF6r/yQvsMt+W wmrA== X-Received: by 10.180.74.47 with SMTP id q15mr7413292wiv.90.1426979285649; Sat, 21 Mar 2015 16:08:05 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id ub1sm12472244wjc.43.2015.03.21.16.08.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Mar 2015 16:08:04 -0700 (PDT) Sender: Baptiste Daroussin Date: Sun, 22 Mar 2015 00:08:02 +0100 From: Baptiste Daroussin To: x11@FreeBSD.org, ports@FreeBSD.org Subject: Re: [HEADSUP] WIP on fonts Message-ID: <20150321230802.GG87678@ivaldir.etoilebsd.net> References: <20150320153711.GB87678@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hcut4fGOf7Kh6EdG" Content-Disposition: inline In-Reply-To: <20150320153711.GB87678@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 23:08:07 -0000 --hcut4fGOf7Kh6EdG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 20, 2015 at 04:37:13PM +0100, Baptiste Daroussin wrote: > Hi all, >=20 > Some of you may have notice some work on the font area. >=20 > The goal of this work is to prevent every single font package to act diff= erently > and most of the time not correctly. >=20 > The change will be done in multiple steps: > 1/ Convert every ports to USES=3Dfonts > 2/ Remove @fc and @fontsdir keywords to only keep @fcfontsdir > 3/ Move all fonts from ${LOCALBASE}/lib/X11/fonts to ${LOCALBASE}/share/f= onts in > order to make the fonts following XDG as well as making them working for = non-x11 > world (wayland for example) >=20 > Best regards, > Bapt Done in r381876 please report me all possible issue, I have done quite a lo= t of testing but I cannot test everything. Best regards, Bapt --hcut4fGOf7Kh6EdG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUN+dIACgkQ8kTtMUmk6EwhxACeIrXicjMOUrU8nnbUXM9S8tOV 4n4An1fHmwkKx9acyiE+/6Vxy/y+JVcd =j26y -----END PGP SIGNATURE----- --hcut4fGOf7Kh6EdG-- From owner-freebsd-ports@FreeBSD.ORG Sat Mar 21 23:26:08 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1561FA4 for ; Sat, 21 Mar 2015 23:26:08 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BDE4EA11 for ; Sat, 21 Mar 2015 23:26:06 +0000 (UTC) Received: (qmail 7380 invoked from network); 21 Mar 2015 23:25:59 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 21 Mar 2015 23:25:59 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sat, 21 Mar 2015 19:25:59 -0400 (EDT) Received: (qmail 8914 invoked from network); 21 Mar 2015 23:25:59 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Mar 2015 23:25:59 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id E174E1C439E; Sat, 21 Mar 2015 16:25:53 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc64 context for clang36 use: /usr/bin/ld too old(?) but is used by clang36 Date: Sat, 21 Mar 2015 16:25:56 -0700 Message-Id: <64205C7D-7DF3-44F0-85C2-3C49B4EE0A4C@dsl-only.net> To: freebsd-ports@freebsd.org, Brooks Davis Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 23:26:08 -0000 Basic context: [I'm using an example taken from buildworld activity just for = illustration. Yes, I know that powerpc64 buildworld via clang is not yet supported. = buildworld is not the actual point here but does illustrate a = pre-existing build environment having the issue in question.] > # freebsd-version -ku; uname -apKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed = Mar 18 20:11:15 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100062 1100062 > # which ld > /usr/bin/ld > # ld --version > GNU ld 2.17.50 [FreeBSD] 2007-07-03 > Copyright 2007 Free Software Foundation, Inc. > This program is free software; you may redistribute it under the terms = of > the GNU General Public License. This program has absolutely no = warranty. > export PATH=3D"/usr/local/powerpc64-freebsd/bin:$PATH" > make -j 8 \ > WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D \ > WITH_LLDB=3D \ > WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITHOUT_GNUCXX=3D \ > WITH_BOOT=3D WITH_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 > # more /etc/src.conf > NO_WERROR=3D > WITH_LIBCPLUSPLUS=3D > # > # For trying clang36... > # (I'm trying to use binutils from the powerpc64-xtoolchain-gcc = install.) > # > CC=3D/usr/local/bin/clang36 > CXX=3D/usr/local/bin/clang++36 > CPP=3D/usr/local/bin/clang-cpp36 > #CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > AS=3D/usr/local/powerpc64-freebsd/bin/as > AR=3D/usr/local/powerpc64-freebsd/bin/ar > LD=3D/usr/local/powerpc64-freebsd/bin/ld > NM=3D/usr/local/powerpc64-freebsd/bin/nm > OBJCOPY=3D/usr/local/powerpc64-freebsd/bin/objcopy > OBJDUMP=3D/usr/local/powerpc64-freebsd/bin/objdump > RANLIB=3D/usr/local/powerpc64-freebsd/bin/ranlib > SIZE=3D/usr/local/powerpc64-freebsd/bin/size > STRINGS=3D/usr/local/powerpc64-freebsd/bin/strings > XAS=3D${AS} > XAR=3D${AR} > XLD=3D${LD} > XNM=3D${NM} > XOBJCOPY=3D${OBJCOPY} > XOBJDUMP=3D${OBJDUMP} > XRANLIB=3D${RANLIB} > XSIZE=3D${SIZE} > XSTRINGS=3D${STRINGS} ... The problem: When the clang36 driver program is used to (for example) link programs = it apparently automatically and always uses /usr/bin/ld. But for = powerpc64 /usr/bin/ld is BFD 2.17.50 vintage and reports an internal = error (see below). It seems likely that clang36 simply requires more recent binutils = programs, such as from binutils-2.25 currently. > /usr/local/bin/clang36 -O2 -pipe -DHAVE_CONFIG_H = -I/usr/srcC/kerberos5/tools/make-roken/../../include -DHAVE_CONFIG_H = -I/usr/srcC/kerberos5/tools/make-roken/../../include -std=3Dgnu99 = -Qunused-argumen > ts -I/usr/obj/usr/srcC/tmp/legacy/usr/include -static = -L/usr/obj/usr/srcC/tmp/legacy/usr/lib -o make-roken make-roken.o = -legacy > /usr/bin/ld: BFD 2.17.50 [FreeBSD] 2007-07-03 internal error, aborting = at = /usr/srcC/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf= 64-ppc.c line 11029 in ppc64_elf_relocate_section > /usr/bin/ld: Please report this bug. If the clang36 port allowed binding to binutils (currently = binutils-2.25) instead of /usr/bin/ tools it could then work in more = contexts. For all I know more than ld could also have vintage issues. I do not know if powerpc64 and powerpc have the only such = vintage-oddities around. Context details: # svnlite info /usr/ports/lang/clang36 Path: /usr/ports/lang/clang36 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 Relative URL: ^/head/lang/clang36 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: brooks Last Changed Rev: 380295 Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) # more /etc/make.conf=20 WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net