From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115818 invoked by alias); 8 Jan 2020 20:46:40 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 115810 invoked by uid 89); 8 Jan 2020 20:46:40 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,KAM_ASCII_DIVIDERS,KAM_LOTSOFHASH,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS,T_FILL_THIS_FORM_SHORT,UNSUBSCRIBE_BODY autolearn=ham version=3.3.1 spammy=lived, mistakes, berlin, Berlin X-HELO: mail-lf1-f54.google.com Received: from mail-lf1-f54.google.com (HELO mail-lf1-f54.google.com) (209.85.167.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 08 Jan 2020 20:46:36 +0000 Received: by mail-lf1-f54.google.com with SMTP id y19so3476802lfl.9 for ; Wed, 08 Jan 2020 12:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bIgkZTrVG5fKRe4/1iLSBkxj/RVUKBKDEa8zQmO3rdQ=; b=sNHibDih2HRr7wxWBNz2BUYzSte2b9VLQ1JNIu3Sd/Fx/O+UaBeY3b3B1WEobk01ko 1XgAhGnhNiQhIAXiwtChe8FDXPSc0bzVPa2V2dc2phlFVTUGZiDoK3rsEqq4cvhjmHln 3oL1IpRfPWM8Tb/igvd2W89ezabFCk/vmGdSkjPTNnoEx/LP/7hlHd6U2YDumLdQ2cuN sE23p0wCrT8LsK736xV9khyHAdL/qCK+mXvpd0SJ4H1Ka9Y1ln/sWYN5uboUY6318w7R cVxtOJjynNLgehrEIX6K13rfJD4y28ZGxWe4AW74rNvIJGXVlVwlQOOnkdeWZ7gKAY3J nE3w== Return-Path: Received: from [192.168.1.65] (46-138-59-132.dynamic.spd-mgts.ru. [46.138.59.132]) by smtp.gmail.com with ESMTPSA id s23sm1803275lji.70.2020.01.08.12.46.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jan 2020 12:46:32 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Proposal for the transition timetable for the move to GIT From: Maxim Kuvyrkov In-Reply-To: Date: Wed, 08 Jan 2020 20:46:00 -0000 Cc: GCC Development , Joseph Myers , Alexandre Oliva , "Eric S. Raymond" , Jeff Law , Segher Boessenkool , Mark Wielaard , Jakub Jelinek Content-Transfer-Encoding: quoted-printable Message-Id: <88B4DAF3-33C1-445F-8F5A-809D5463D0F9@linaro.org> References: <20191216133632.GC3152@gate.crashing.org> <20191216135451.GA3142@thyrsus.com> <20191216140514.GD3152@gate.crashing.org> <20191216153649.GE3152@gate.crashing.org> <20191225120747.GA96669@thyrsus.com> <20191226111633.GJ10088@tucnak> <5DCEA32B-3E36-4400-B931-9F4E2A8F3FA5@linaro.org> <155B5BFD-6ECF-4EBF-A38C-D6DD178FB497@linaro.org> <2b6330f2-1a00-ac89-fd3c-4b70e5454f4b@arm.com> <9B71A0F7-CD93-4636-BFC7-1D1DBC040F07@linaro.org> <6EE7BD53-6677-49D2-BCDD-56CD7DA855E9@linaro.org> To: "Richard Earnshaw (lists)" X-SW-Source: 2020-01/txt/msg00071.txt.bz2 > On Dec 30, 2019, at 7:08 PM, Richard Earnshaw (lists) wrote: >=20 > On 30/12/2019 15:49, Maxim Kuvyrkov wrote: >>> On Dec 30, 2019, at 6:31 PM, Richard Earnshaw (lists) wrote: >>>=20 >>> On 30/12/2019 13:00, Maxim Kuvyrkov wrote: >>>>> On Dec 30, 2019, at 1:24 AM, Richard Earnshaw (lists) wrote: >>>>>=20 >>>>> On 29/12/2019 18:30, Maxim Kuvyrkov wrote: >>>>>> Below are several more issues I found in reposurgeon-6a conversion c= omparing it against gcc-reparent conversion. >>>>>>=20 >>>>>> I am sure, these and whatever other problems I may find in the repos= urgeon conversion can be fixed in time. However, I don't see why should bo= ther. My conversion has been available since summer 2019, I made it ready = in time for GCC Cauldron 2019, and it didn't change in any significant way = since then. >>>>>>=20 >>>>>> With the "Missed merges" problem (see below) I don't see how reposur= geon conversion can be considered "ready". Also, I expected a diligent dev= eloper to compare new conversion (aka reposurgeon's) against existing conve= rsion (aka gcc-pretty / gcc-reparent) before declaring the new conversion "= better" or even "ready". The data I'm seeing in differences between my and= reposurgeon conversions shows that gcc-reparent conversion is /better/. >>>>>>=20 >>>>>> I suggest that GCC community adopts either gcc-pretty or gcc-reparen= t conversion. I welcome Richard E. to modify his summary scripts to work w= ith svn-git scripts, which should be straightforward, and I'm ready to help. >>>>>>=20 >>>>>=20 >>>>> I don't think either of these conversions are any more ready to use t= han >>>>> the reposurgeon one, possibly less so. In fact, there are still some >>>>> major issues to resolve first before they can be considered. >>>>>=20 >>>>> gcc-pretty has completely wrong parent information for the gcc-3 era >>>>> release tags, showing the tags as being made directly from trunk with >>>>> massive deltas representing the roll-up of all the commits that were >>>>> made on the gcc-3 release branch. >>>>=20 >>>> I will clarify the above statement, and please correct me where you th= ink I'm wrong. Gcc-pretty conversion has the exact right parent informatio= n for the gcc-3 era >>>> release tags as recorded in SVN version history. Gcc-pretty conversio= n aims to produce an exact copy of SVN history in git. IMO, it manages to = do so just fine. >>>>=20 >>>> It is a different thing that SVN history has a screwed up record of gc= c-3 era tags. >>>=20 >>> It's not screwed up in svn. Svn shows the correct history information = for the gcc-3 era release tags, but the git-svn conversion in gcc-pretty do= es not. >>>=20 >>> For example, looking at gcc_3_0_release in expr.c with git blame and sv= n blame shows >>=20 >> In SVN history tags/gcc_3_0_release has been copied off /trunk:39596 and= in the same commit bunch of files were replaced from /branches/gcc-3_0-bra= nch/ (and from different revisions of this branch!). >>=20 >> $ svn log -qv --stop-on-copy file://$(pwd)/tags/gcc_3_0_release | grep "= /tags/gcc_3_0_release \|/tags/gcc_3_0_release/gcc/expr.c \|/tags/gcc_3_0_re= lease/gcc/reload.c " >> A /tags/gcc_3_0_release (from /trunk:39596) >> R /tags/gcc_3_0_release/gcc/expr.c (from /branches/gcc-3_0-branch/gcc/= expr.c:43255) >> R /tags/gcc_3_0_release/gcc/reload.c (from /branches/gcc-3_0-branch/gc= c/reload.c:42007) >>=20 >=20 > Right, (and wrong). You have to understand how the release branches and > tags are represented in CVS to understand why the SVN conversion is done > this way. When a branch was created in CVS a tag was added to each > commit which would then be used in any future revisions along that > branch. But until a commit is made on that branch, the release branch > is just a placeholder. >=20 > When a CVS release tag is created, the tag labels the relevant commit > that is to be used. If that commit is unchanged from the trunk revision > (no commit on the branch), then that is what gets labelled, and it > *appears* to still come from trunk - but that does not matter, since it > is the same as the version on trunk. >=20 > The svn copy operations are formed from this set of information by > copying the SVN revision of trunk that applied at the point the branch > was made, and then overriding the copy information for each file that > was then modified on the branch with information about that copy. This > is sufficient for svn to fully understand the history information for > each and every file in the tag. >=20 > Unfortunately, git-svn mis-interprets this when building its graph of > what happened and while it copies the right *content* into the release > branch, it does not copy the right *history*. The SVN R operation > copies the history from named revision, not just the content. That's > the significant difference between the two. >=20 > R >> IMO, from such history (absent external knowledge about better reparenti= ng options) the best choice for parent branch is /trunk@39596, not /branche= s/gcc-3_0-branch at a random revision from the replaced files. >>=20 >> Still, I see your point, and I will fix reparenting support. Whether GC= C community opts to reparent or not reparent is a different topic. I've added proper reparenting support to svn-git scripts, and gcc-reparent = will be updated in a day or so. I've also added a few minor improvements a= nd fixed things that Joseph pointed out in my conversion. Once gcc-reparent conversion is regenerated, I'll do another round of compa= risons between it and whatever the latest reposurgeon version is. -- Maxim Kuvyrkov https://www.linaro.org >> -- >> Maxim Kuvyrkov >> https://www.linaro.org >>=20 >>=20 >>> git blame expr.c: >>>=20 >>> ba0a9cb85431 (Richard Kenner 1992-03-03 23:34:57 +0000 396) = return temp; >>> ba0a9cb85431 (Richard Kenner 1992-03-03 23:34:57 +0000 397) = } >>> 5fbf0b0d5828 (no-author 2001-06-17 19:44:25 +0000 398) = /* Copy the address into a pseudo, so that the returned value >>> 5fbf0b0d5828 (no-author 2001-06-17 19:44:25 +0000 399) = remains correct across calls to emit_queue. */ >>> 5fbf0b0d5828 (no-author 2001-06-17 19:44:25 +0000 400) = XEXP (new, 0) =3D copy_to_reg (XEXP (new, 0)); >>> 59f26b7caad9 (Richard Kenner 1994-01-11 00:23:47 +0000 401) = return new; >>>=20 >>> git log 5fbf0b0d5828 >>> commit 5fbf0b0d5828687914c1c18a83ff12c8627d5a70 (HEAD, tag: gcc_3_0_rel= ease) >>> Author: no-author >>> Date: Sun Jun 17 19:44:25 2001 +0000 >>>=20 >>> This commit was manufactured by cvs2svn to create tag >>> 'gcc_3_0_release'. >>>=20 >>> while svn blame expr.c correctly shows: >>>=20 >>> 386 kenner return temp; >>> 386 kenner } >>> 42209 bernds /* Copy the address into a pseudo, so that the= returned value >>> 42209 bernds remains correct across calls to emit_queue.= */ >>> 42209 bernds XEXP (new, 0) =3D copy_to_reg (XEXP (new, 0)); >>> 6375 kenner return new; >>>=20 >>> svn log -r42209 ^/ >>> ------------------------------------------------------------------------ >>> r42209 | bernds | 2001-05-17 18:07:08 +0100 (Thu, 17 May 2001) | 2 lines >>>=20 >>> Fix queueing-related bugs >>>=20 >>> In other words, svn can correctly track the files that were modified on= the release branch, while the git conversion looses that information, roll= ing up all the diffs on the release branch into a single unattributed commi= t. >>>=20 >>> As I said, gcc-reparent is better in this regard, but there are still a= rtefacts from conversion, such as incorrect merge records, that show up. >>>=20 >>> R. >>>=20 >>>>=20 >>>>>=20 >>>>> gcc-reparent is better, but many (most?) of the release tags are shown >>>>> as merge commits with a fake parent back to the gcc-3 branch point, >>>>> which is certainly not what happened when the tagging was done at that >>>>> time. >>>>=20 >>>> I agree with you here. >>>>=20 >>>>>=20 >>>>> Both of these factually misrepresent the history at the time of the >>>>> release tag being made. >>>>=20 >>>> Yes and no. Gcc-pretty repository mirrors SVN history. And regarding= the need for reparenting -- we lived with current history for gcc-3 releas= e tags for a long time. I would argue their continued brokenness is not a = show-stopper. >>>>=20 >>>> Looking at this from a different perspective, when I posted the initia= l svn-git scripts back in Summer, the community roughly agreed on a plan to >>>> 1. Convert entire SVN history to git. >>>> 2. Use the stock git history rewrite tools (git filter-branch) to fixu= p what we want, e.g., reparent tags and branches or set better author/commi= tter entries. >>>>=20 >>>> Gcc-pretty does (1) in entirety. >>>>=20 >>>> For reparenting, I tried a 15min fix to my scripts to enable reparenti= ng, which worked, but with artifacts like the merge commit from old and new= parents. I will drop this and instead use tried-and-true "git filter-bran= ch" to reparent those tags and branches, thus producing gcc-reparent from g= cc-pretty. >>>>=20 >>>>>=20 >>>>> As for converting my script to work with your tools, I'm afraid I don= 't >>>>> have time to work on that right now. I'm still bogged down validating >>>>> the incorrect bug ids that the script has identified for some commits. >>>>> I'm making good progress (we're down to 160 unreviewed commits now), = but >>>>> it is still going to take what time I have over the next week to >>>>> complete that task. >>>>>=20 >>>>> Furthermore, there is no documentation on how your conversion scripts >>>>> work, so it is not possible for me to test any work I might do in ord= er >>>>> to validate such changes. Not being able to run the script locally to >>>>> test change would be a non-starter. >>>>>=20 >>>>> You are welcome, of course, to clone the script I have and attempt to >>>>> modify it yourself, it's reasonably well documented. The sources can= be >>>>> found in esr's gcc-conversion repository here: >>>>> https://gitlab.com/esr/gcc-conversion.git >>>>=20 >>>> -- >>>> Maxim Kuvyrkov >>>> https://www.linaro.org >>>>=20 >>>>>=20 >>>>>=20 >>>>>> Meanwhile, I'm going to add additional root commits to my gcc-repare= nt conversion to bring in "missing" branches (the ones, which don't share h= istory with trunk@1) and restart daily updates of gcc-reparent conversion. >>>>>>=20 >>>>>> Finally, with the comparison data I have, I consider statements abou= t git-svn's poor quality to be very misleading. Git-svn may have had serio= us bugs years ago when Eric R. evaluated it and started his work on reposur= geon. But a lot of development has happened and many problems have been fi= xed since them. At the moment it is reposurgeon that is producing conversi= ons with obscure mistakes in repository metadata. >>>>>>=20 >>>>>>=20 >>>>>> =3D=3D=3D Missed merges =3D=3D=3D >>>>>>=20 >>>>>> Reposurgeon misses merges from trunk on 130+ branches. I've spot-ch= ecked ARM/hard_vfp_branch and redhat/gcc-9-branch and, indeed, rather munda= ne merges were omitted. Below is analysis for ARM/hard_vfp_branch. >>>>>>=20 >>>>>> $ git log --stat refs/remotes/gcc-reposurgeon-6a/ARM/hard_vfp_branch= ~4 >>>>>> ---- >>>>>> commit ef92c24b042965dfef982349cd5994a2e0ff5fde >>>>>> Author: Richard Earnshaw >>>>>> Date: Mon Jul 20 08:15:51 2009 +0000 >>>>>>=20 >>>>>> Merge trunk through to r149768 >>>>>>=20 >>>>>> Legacy-ID: 149804 >>>>>>=20 >>>>>> COPYING.RUNTIME | 73 + >>>>>> ChangeLog | 270 +- >>>>>> MAINTAINERS | 19 +- >>>>>> >>>>>> ---- >>>>>>=20 >>>>>> at the same time for svn-git scripts we have: >>>>>>=20 >>>>>> $ git log --stat refs/remotes/gcc-reparent/ARM/hard_vfp_branch~4 >>>>>> ---- >>>>>> commit ce7d5c8df673a7a561c29f095869f20567a7c598 >>>>>> Merge: 4970119c20da 3a69b1e566a7 >>>>>> Author: Richard Earnshaw >>>>>> Date: Mon Jul 20 08:15:51 2009 +0000 >>>>>>=20 >>>>>> Merge trunk through to r149768 >>>>>>=20 >>>>>> git-svn-id: https://gcc.gnu.org/svn/gcc/branches/ARM/hard_vfp_branc= h@149804 138bc75d-0d04-0410-961f-82ee72b054a4 >>>>>> ---- >>>>>>=20 >>>>>> ... which agrees with >>>>>> $ svn propget svn:mergeinfo file:///home/maxim.kuvyrkov/tmpfs-stuff/= svnrepo/branches/ARM/hard_vfp_branch@149804 >>>>>> /trunk:142588-149768 >>>>>>=20 >>>>>> =3D=3D=3D Bad author entries =3D=3D=3D >>>>>>=20 >>>>>> Reposurgeon-6a conversion has authors "12:46:56 1998 Jim Wilson" and= "2005-03-18 Kazu Hirata". It is rather obvious that person's name is unli= kely to start with a digit. >>>>>>=20 >>>>>> =3D=3D=3D Missed authors =3D=3D=3D >>>>>>=20 >>>>>> Reposurgeon-6a conversion misses many authors, below is a list of pe= ople with names starting with "A". >>>>>>=20 >>>>>> Akos Kiss >>>>>> Anders Bertelrud >>>>>> Andrew Pochinsky >>>>>> Anton Hartl >>>>>> Arthur Norman >>>>>> Aymeric Vincent >>>>>>=20 >>>>>> =3D=3D=3D Conservative author entries =3D=3D=3D >>>>>>=20 >>>>>> Reposurgeon-6a conversion uses default "@gcc.gnu.org" emails for man= y commits where svn-git conversion manages to extract valid email from comm= it data. This happens for hundreds of author entries. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> -- >>>>>> Maxim Kuvyrkov >>>>>> https://www.linaro.org >>>>>>=20 >>>>>>=20 >>>>>>> On Dec 26, 2019, at 7:11 PM, Maxim Kuvyrkov wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Dec 26, 2019, at 2:16 PM, Jakub Jelinek wrot= e: >>>>>>>>=20 >>>>>>>> On Thu, Dec 26, 2019 at 11:04:29AM +0000, Joseph Myers wrote: >>>>>>>> Is there some easy way (e.g. file in the conversion scripts) to co= rrect >>>>>>>> spelling and other mistakes in the commit authors? >>>>>>>> E.g. there are misspelled surnames, etc. (e.g. looking at my name,= I see >>>>>>>> Jakub Jakub Jelinek (1): >>>>>>>> Jakub Jeilnek (1): >>>>>>>> Jelinek (1): >>>>>>>> entries next to the expected one with most of the commits. >>>>>>>> For the misspellings, wonder if e.g. we couldn't compute edit dist= ances from >>>>>>>> other names and if we have one with many commits and then one with= very few >>>>>>>> with small edit distance from those, flag it for human review. >>>>>>>=20 >>>>>>> This is close to what svn-git-author.sh script is doing in gcc-pret= ty and gcc-reparent conversions. It ignores 1-3 character differences in a= uthor/committer names and email addresses. I've audited results for all br= anches and didn't spot any mistakes. >>>>>>>=20 >>>>>>> In other news, I'm working on comparison of gcc-pretty, gcc-reparen= t and gcc-reposurgeon-5a repos among themselves. Below are current notes f= or comparison of gcc-pretty/trunk and gcc-reposurgeon-5a/trunk. >>>>>>>=20 >>>>>>> =3D=3D Merges on trunk =3D=3D >>>>>>>=20 >>>>>>> Reposurgeon creates merge entries on trunk when changes from a bran= ch are merged into trunk. This brings entire development history from the = branch to trunk, which is both good and bad. The good part is that we get = more visibility into how the code evolved. The bad part is that we get man= y "noisy" commits from merged branch (e.g., "Merge in trunk" every few revi= sions) and that our SVN branches are work-in-progress quality, not ready fo= r review/commit quality. It's common for files to be re-written in large c= hunks on branches. >>>>>>>=20 >>>>>>> Also, reposurgeon's commit logs don't have information on SVN path = from which the change came, so there is no easy way to determine that a giv= en commit is from a merged branch, not an original trunk commit. Git-svn, = on the other hand, provides "git-svn-id: @" tags in its com= mit logs. >>>>>>>=20 >>>>>>> My conversion follows current GCC development policy that trunk his= tory should be linear. Branch merges to trunk are squashed. Merges betwee= n non-trunk branches are handled as specified by svn:mergeinfo SVN properti= es. >>>>>>>=20 >>>>>>> =3D=3D Differences in trees =3D=3D >>>>>>>=20 >>>>>>> Git trees (aka filesystem content) match between pretty/trunk and r= eposurgeon-5a/trunk from current tip and up tosvn's r130805. >>>>>>> Here is SVN log of that revision (restoration of deleted trunk): >>>>>>> -------------------------------------------------------------------= ----- >>>>>>> r130805 | dberlin | 2007-12-13 01:53:37 +0000 (Thu, 13 Dec 2007) >>>>>>> Changed paths: >>>>>>> A /trunk (from /trunk:130802) >>>>>>> -------------------------------------------------------------------= ----- >>>>>>>=20 >>>>>>> Reposurgeon conversion has: >>>>>>> ------------- >>>>>>> commit 7e6f2a96e89d96c2418482788f94155d87791f0a >>>>>>> Author: Daniel Berlin >>>>>>> Date: Thu Dec 13 01:53:37 2007 +0000 >>>>>>>=20 >>>>>>> Readd trunk >>>>>>>=20 >>>>>>> Legacy-ID: 130805 >>>>>>>=20 >>>>>>> .gitignore | 17 ----------------- >>>>>>> 1 file changed, 17 deletions(-) >>>>>>> ------------- >>>>>>> and my conversion has: >>>>>>> ------------- >>>>>>> commit fb128f3970789ce094c798945b4fa20eceb84cc7 >>>>>>> Author: Daniel Berlin >>>>>>> Date: Thu Dec 13 01:53:37 2007 +0000 >>>>>>>=20 >>>>>>> Readd trunk >>>>>>>=20 >>>>>>>=20 >>>>>>> git-svn-id: https://gcc.gnu.org/svn/gcc/trunk@130805 138bc75d-0d04-= 0410-961f-82ee72b054a4 >>>>>>> ------------- >>>>>>>=20 >>>>>>> It appears that .gitignore has been added in r1 by reposurgeon and = then deleted at r130805. In SVN repository .gitignore was added in r195087= . I speculate that addition of .gitignore at r1 is expected, but it's dele= tion at r130805 is highly suspicious. >>>>>>>=20 >>>>>>> =3D=3D Committer entries =3D=3D >>>>>>>=20 >>>>>>> Reposurgeon uses $user@gcc.gnu.org for committer email addresses ev= en when it correctly detects author name from ChangeLog. >>>>>>>=20 >>>>>>> reposurgeon-5a: >>>>>>> r278995 Martin Liska Martin Liska >>>>>>> r278994 Jozef Lawrynowicz Jozef Lawrynow= icz >>>>>>> r278993 Frederik Harwath Frederik Harwa= th >>>>>>> r278992 Georg-Johann Lay Georg-Johann Lay >>>>>>> r278991 Richard Biener Richard Biener >>>>>>>=20 >>>>>>> pretty: >>>>>>> r278995 Martin Liska Martin Liska >>>>>>> r278994 Jozef Lawrynowicz Jozef Lawrynow= icz >>>>>>> r278993 Frederik Harwath Frederik Harwa= th >>>>>>> r278992 Georg-Johann Lay Georg-Johann Lay >>>>>>> r278991 Richard Biener Richard Biener >>>>>>>=20 >>>>>>> =3D=3D Bad summary line =3D=3D >>>>>>>=20 >>>>>>> While looking around r138087, below caught my eye. Is the contents= of summary line as expected? >>>>>>>=20 >>>>>>> commit cc2726884d56995c514d8171cc4a03657851657e >>>>>>> Author: Chris Fairles >>>>>>> Date: Wed Jul 23 14:49:00 2008 +0000 >>>>>>>=20 >>>>>>> acinclude.m4 ([GLIBCXX_CHECK_CLOCK_GETTIME]): Define GLIBCXX_LIBS. >>>>>>>=20 >>>>>>> 2008-07-23 Chris Fairles >>>>>>>=20 >>>>>>> * acinclude.m4 ([GLIBCXX_CHECK_CLOCK_GETTIME]): Define GLIB= CXX_LIBS. >>>>>>> Holds the lib that defines clock_gettime (-lrt or -lposix4). >>>>>>> * src/Makefile.am: Use it. >>>>>>> * configure: Regenerate. >>>>>>> * configure.in: Likewise. >>>>>>> * Makefile.in: Likewise. >>>>>>> * src/Makefile.in: Likewise. >>>>>>> * libsup++/Makefile.in: Likewise. >>>>>>> * po/Makefile.in: Likewise. >>>>>>> * doc/Makefile.in: Likewise. >>>>>>>=20 >>>>>>> Legacy-ID: 138087 >>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> Maxim Kuvyrkov >>>>>>> https://www.linaro.org >>=20 >=20