From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14341 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Revisiting 64-bit time_t Date: Mon, 1 Jul 2019 18:07:45 -0400 Message-ID: <20190701220745.GY1506@brightrain.aerifal.cx> References: <20190628150659.GD1506@brightrain.aerifal.cx> <20190701153108.GR1506@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="208804"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14357-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jul 02 00:08:01 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hi4Su-000sAn-4R for gllmg-musl@m.gmane.org; Tue, 02 Jul 2019 00:08:00 +0200 Original-Received: (qmail 1699 invoked by uid 550); 1 Jul 2019 22:07:57 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1679 invoked from network); 1 Jul 2019 22:07:57 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14341 Archived-At: On Mon, Jul 01, 2019 at 11:12:20PM +0200, Arnd Bergmann wrote: > > > > Aside from community feedback, what's needed to make this possible, if > > > > it's going to happen, is some good analysis of the scope of breakage. > > > > Such analysis would also benefit glibc -- it would help determine how > > > > safe their _TIME_BITS=64 option will be and whether it can be turned > > > > on safely by default in the presence of old libraries built without > > > > it. I've already discussed this casually with a few people and it > > > > looks like the right starting point would be getting a Debian system > > > > (Debian because their repo is utterly huge) with ALL library packages > > > > installed and grepping /usr/include for all headers that involve > > > > time_t or any of the derived types. Then, manual analysis would need > > > > to be done to determine whether the usage actually has an impact. > > > > > > Yes, this is also one of the things we eventually plan to do in Linaro, > > > but have not actually started. > > > > Would it be possible to prioritize starting this? It would be a big > > help to deciding what direction we should take in musl and make this > > move forward a lot quicker, I think. I was thinking we'd have to do it > > ourselves or find someone else to convince to do it, but if Linaro > > already plans to do this anyway, we could perhaps accelerate things > > with no overall increase in effort to be spent. > > I've had a first look here now, with a scripted search in /usr/include > for all packages in debian testing/main: > > apt-file search /usr/include | cut -f 1 -d: | uniq | > while read i ; do > mkdir -p ${i} > cd ${i} > if [ ! -e "${i}_.*.deb" ] ; then > apt-get download ${i} > fi > FILE=${i}_*.deb > dpkg-deb --fsys-tarfile ${FILE} | tar xf - ./usr/include > cd .. > ctags -f - -R ${i}/ | grep > '\' > > ${i}.tags > grep -r '\' > ${i}/ > ${i}.files > rm -rf ./${i} > done > > There are 4288 packages that provide a file in /usr/include, and out of those, > 973 match the regular expression above, see the list at > > https://pastebin.com/Yu22pLqQ > > This took a few hours to run and could be done faster by running bits > in parallel. > I can send you the full output, but it's at 300kb compressed, it's a bit large > for the mailing list. The regex also wasn't great, so I'm sure there > are lots of false positives and negatives, but its' a start. OK. That sounds like a lot, but upon looking, a lot of them look like "libraries" whose main/sole consumer is a single application. So maybe it's not so bad. Rich