From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by mx.groups.io with SMTP id smtpd.web10.11261.1672370701722383946 for ; Thu, 29 Dec 2022 19:25:01 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@bsdio.com header.s=fm3 header.b=UZIUsdKB; spf=pass (domain: bsdio.com, ip: 64.147.123.24, mailfrom: rebecca@bsdio.com) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 3A62B3200909; Thu, 29 Dec 2022 22:25:00 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 29 Dec 2022 22:25:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdio.com; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1672370699; x=1672457099; bh=95xcCBJjYz agVFxwE3pLnn0mAZZMdeLWcbBNQ2td0TI=; b=UZIUsdKBHGQf1kZp2Wj4AFQiD2 iMGQcSMejVYUHRBTCxzvLjCokT/YKfyWWh5zOgbzSvExqPgTS9zd/lw8Q92hwMrP uoe0seaAThqAtPz21lwlIWUEvIOhe3FjY6Nw+lJbVerYaVe8qMJq2O0yEBYNBhhN nqhuR/PVQTcFw3jZbnMa3berQ1Nz/dyFRExa7FtyYgP3rFq5ShUHrg5NqR1DliBr /Fn3UQVJ9oVL6jPFeVo3OlMw4mhNSHJx4eTZQnfc/cVj9sN1LR374E7tZ6Triygw hqOLIIm/230gkEDHFXSFlFJgypM0xivKJjwFZrDI/YeZPl4s+29OwSKsGzyg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1672370699; x=1672457099; bh=95xcCBJjYzagVFxwE3pLnn0mAZZM deLWcbBNQ2td0TI=; b=fudclkvPNtws5DXb1sATfphXj/n9TIsaFi/wm34/MxSi cTq4eo8kUOEn03x1j6fQyYIrwu+xa3eVtRI6UEgEig2kuYnmuzo9FZEmxpeMQ7jc chERilh/YeIrH7wW630Y1W+2IpHRw5lxLK5942Ld3ihORVyMip2YmJHvyYbuIsTa EhS/qww6FhOugBJjpsKcv9cg3rKp+bql3tKa0+ekbt1BZDmXAQIP4uzOL5ftKb9T HhdiSynMhhaDIKv34KNDBKBAfp0HRyMxf0L/Yi55ioEyet7bGP3sbnb96xMzERv/ 6XKwvDdyg0Jdq5vW88Bg7vvLz+Ky9Dh8tn5Jqr8Oog== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrieehgdehkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtkfffgggfuffvvehfhfgjsegrtderredtfeejnecuhfhrohhmpeftvggsvggt tggrucevrhgrnhcuoehrvggsvggttggrsegsshguihhordgtohhmqeenucggtffrrghtth gvrhhnpeekffehhfethffgtdfhudejgefgudejkeegtdfhjeeuuddugeffveefffekudfh hfenucffohhmrghinhepghhrohhuphhsrdhiohenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehrvggsvggttggrsegsshguihhordgtohhm X-ME-Proxy: Feedback-ID: i5b994698:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 29 Dec 2022 22:24:57 -0500 (EST) Message-ID: Date: Thu, 29 Dec 2022 20:24:56 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: =?UTF-8?B?UmU6IOWbnuWkjTogW2VkazItZGV2ZWxdIFJlZHVjaW5nIHRoZSBzaXplIG9mIHRoZSBsb29uZ2FyY2g2NCB0b29sY2hhaW4gZG93bmxvYWQ=?= To: gaoliming , devel@edk2.groups.io, 'Chao Li' , 'Baoqi Zhang' , 'Dongyan Qian' Cc: 'Michael D Kinney' References: <5f88e31c-444e-f7c4-668e-c1221d012f40@bsdio.com> <01a501d91bf4$025d7630$07186290$@byosoft.com.cn> From: "Rebecca Cran" In-Reply-To: <01a501d91bf4$025d7630$07186290$@byosoft.com.cn> Content-Type: multipart/alternative; boundary="------------4M4Uc0b5RiuKUyJmauhwsG8P" Content-Language: en-US --------------4M4Uc0b5RiuKUyJmauhwsG8P Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit The directory exists, that's not the problem. The issue is that it's far larger than it needs to be: we could save bandwidth and time. (.venv) bcran@cube:~/src/uefi/tmp/edk2/BaseTools/Bin/gcc_loongarch64_unknown_linux_extdep$ ldd bin/loongarch64-unknown-linux-gnu-* ... bin/loongarch64-unknown-linux-gnu-gcc: not a dynamic executable ... (.venv) bcran@cube:~/src/uefi/tmp/edk2/BaseTools/Bin/gcc_loongarch64_unknown_linux_extdep$ du -h --max-depth=3 4.0K ./include 66M ./bin 134M ./libexec/gcc/loongarch64-unknown-linux-gnu 134M ./libexec/gcc 134M ./libexec ... 40M ./share 23M ./lib/gcc/loongarch64-unknown-linux-gnu 23M ./lib/gcc 12K ./lib/bfd-plugins 23M ./lib ... 37M ./loongarch64-unknown-linux-gnu 396M ./target/usr/include 2.6G ./target/usr/lib64 4.0K ./target/usr/lib 3.0G ./target/usr 3.0G ./target 3.2G . -- Rebecca Cran On 12/29/22 19:11, gaoliming wrote: > Rebecca: > BaseTools/Bin/gcc_loongarch64_unknown_linux_extdep directory should be created after Stuart build. Please confirm it. > > Thanks > Liming >> -----邮件原件----- >> 发件人:devel@edk2.groups.io 代表 Rebecca Cran >> 发送时间: 2022年12月28日 16:15 >> 收件人: Chao Li; Baoqi Zhang >> ; Dongyan Qian >> 抄送:devel@edk2.groups.io; Michael D Kinney >> 主题: [edk2-devel] Reducing the size of the loongarch64 toolchain download >> >> I noticed the BaseTools/Bin/gcc_loongarch64_unknown_linux_extdep >> directory is 3.2GB. However, 2.6GB of that is from target/usr/lib64 >> (which includes X and Qt libraries). >> >> Since it appears the gcc binaries are statically linked, I was wondering >> if the lib and lib64 directories could be excluded from future uploads? >> >> >> -- >> Rebecca Cran >> >> >> >> >> > > --------------4M4Uc0b5RiuKUyJmauhwsG8P Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 
The directory exists, that's not the problem.
The issue is that it's far larger than it needs to be: we could save bandwidth and time.


(.venv) bcran@cube:~/src/uefi/tmp/edk2/BaseTools/Bin/gcc_loongarch64_unknown_linux_extdep$ ldd bin/loongarch64-unknown-linux-gnu-*
...
bin/loongarch64-unknown-linux-gnu-gcc:
	not a dynamic executable
...
(.venv) bcran@cube:~/src/uefi/tmp/edk2/BaseTools/Bin/gcc_loongarch64_unknown_linux_extdep$ du -h --max-depth=3
4.0K	./include
66M	./bin
134M	./libexec/gcc/loongarch64-unknown-linux-gnu
134M	./libexec/gcc
134M	./libexec
...
40M	./share
23M	./lib/gcc/loongarch64-unknown-linux-gnu
23M	./lib/gcc
12K	./lib/bfd-plugins
23M	./lib
...
37M	./loongarch64-unknown-linux-gnu
396M	./target/usr/include
2.6G	./target/usr/lib64
4.0K	./target/usr/lib
3.0G	./target/usr
3.0G	./target
3.2G	.

-- 
Rebecca Cran
On 12/29/22 19:11, gaoliming wrote:
Rebecca:
 BaseTools/Bin/gcc_loongarch64_unknown_linux_extdep directory should be created after Stuart build. Please confirm it. 

Thanks
Liming

-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Rebecca Cran
发送时间: 2022年12月28日 16:15
收件人: Chao Li <lichao@loongson.cn>; Baoqi Zhang
<zhangbaoqi@loongson.cn>; Dongyan Qian <qiandongyan@loongson.cn>
抄送: devel@edk2.groups.io; Michael D Kinney <michael.d.kinney@intel.com>
主题: [edk2-devel] Reducing the size of the loongarch64 toolchain download

I noticed the BaseTools/Bin/gcc_loongarch64_unknown_linux_extdep
directory is 3.2GB. However, 2.6GB of that is from target/usr/lib64
(which includes X and Qt libraries).

Since it appears the gcc binaries are statically linked, I was wondering
if the lib and lib64 directories could be excluded from future uploads?


--
Rebecca Cran
--------------4M4Uc0b5RiuKUyJmauhwsG8P--