Re: [OE-core] [RFC PATCH 1/2] cross-localedef-native: Add hardlink resolver from util-linux
I think it’s ok to have it in Glibc/localedef not all distros have this version of util Linux yet and perhaps we should start creating a buildtools tarballs which is a prerequisite for building OE and collect these dependencies in there instead Of sticking them in unusual places On Fri, Aug 16, 2019 at 7:59 PM Jason Wessel wrote: > On 8/16/19 4:50 PM, richard.pur...@linuxfoundation.org wrote: > > On Fri, 2019-08-16 at 14:29 -0700, Khem Raj wrote: > >> On Fri, Aug 16, 2019 at 2:25 PM Richard Purdie > >> wrote: > >>> This was discussed on IRC. We really really want to avoid that as a > >>> dependency if we care about build performance. Its really easy to > >>> just > >>> add that in but the implications are significant :( > >>> > >> A captured version of this utility would also mean that we have to > >> keep this in sync for bug fixes and security fixes etc. which could > >> also be considered as expense, so how much do we lose if util-linux- > >> native is brought early into dependency chain? > > The tool is being used for a specific purpose at build time. Its not > > exposed on target and its use is extremely constrained to a specific > > set of files where its behaviour should be deterministic. > > > > As such, yes there are questions about bug fixes and about security but > > I don't think its going to be a serious burden. We'd need to carry this > > until such times as the host systems we support have hardlink which is > > probably a few years out but will arrive. > > > > The impact of having util-linux-native in the dependency graph at this > > point is significant. I say that as someone who has done a lot of work > > in trimming down the times of our bootstrap process. This is exactly > > the kind of dependency I've removed and avoided. > > > > glibc is special in that its the worst choke point on the dependency > > graph. Nothing to do with target binaries happens until it is ready and > > then gcc-runtime can build. Whilst the locales are split from glibc, > > they are still connected in the task graph for packaging purposes so > > this is important. > > > > Its been pointed out there are other places where util-linux-native has > > crept in, in particular python3-native. My preference would be to > > minimise these dependencies rather than use them as a way to justify > > adding it here too. > > > So what is the consensus here? Can we require the host system to have > hardlink? It is available as a stand alone binary on Ubuntu 14.04 and up > and on Fedora systems, but isn't installed by default, and we'd have to > check the version because the arguments sadly are slightly different. We > could certainly make util-linux a dependency, but that is why this patch > existed, in order to avoid the dependency. > > I did find a python version at > https://raw.githubusercontent.com/akaihola/hardlinkpy/master/hardlink.py. > I made a one line modification to it and it works, but it isn't nearly as > efficient. The proof is below, using the same locale-tree each time. It > is important to look at both the real and user time. The difference gets > more significant when you run it under pseudo, where we expect it to run > 100% of the time. It is roughly 10x slower to do this in python. > > > time recipe-sysroot-native/usr/bin/cross-localedef-hardlink -c -v > locale-tree > Directories: 982 > Objects:7441 > Regular files: 6441 > Comparisons:3331 > Linked: 3109 > Saved: 754675712 > > real0m0.641s > user0m0.120s > sys 0m0.518s > > time python3 hardlink.py -v 0 -c locale-tree > > > Hard linking Statistics: > Directories : 982 > Regular files : 6441 > Comparisons : 31884 > Hardlinked this run : 3109 > Total hardlinks : 3109 > Bytes saved this run : 744089843 (709.619 mebibytes) > Total bytes saved : 744089843 (709.619 mebibytes) > Total run time: 2.124422073364258 seconds > > real0m2.180s > user0m1.220s > sys 0m0.953s > > > Now lets run it under pseudo > > time recipe-sysroot-native/usr/bin/cross-localedef-hardlink -c -v > locale-tree > Directories: 982 > Objects:7441 > Regular files: 6441 > Comparisons:3331 > Linked: 3109 > Saved: 754675712 > > real0m2.505s > user0m0.373s > sys 0m1.286s > > time python3 hardlink.py -v 0 -c locale-tree > > > Hard linking Statistics: > Directories : 982 > Regular files : 6441 > Comparisons : 31884 > Hardlinked this run : 3109 > Total hardlinks : 3109 > Bytes saved this run : 744089843 (709.619 mebibytes) > Total bytes saved : 744089843 (709.619 mebibytes) > Total run time: 12.971824884414673 seconds > > real0m13.046s > user0m3.633s > sys 0m5.192s > > > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org
Re: [OE-core] [RFC PATCH 1/2] cross-localedef-native: Add hardlink resolver from util-linux
On 8/16/19 4:50 PM, richard.pur...@linuxfoundation.org wrote: On Fri, 2019-08-16 at 14:29 -0700, Khem Raj wrote: On Fri, Aug 16, 2019 at 2:25 PM Richard Purdie wrote: This was discussed on IRC. We really really want to avoid that as a dependency if we care about build performance. Its really easy to just add that in but the implications are significant :( A captured version of this utility would also mean that we have to keep this in sync for bug fixes and security fixes etc. which could also be considered as expense, so how much do we lose if util-linux- native is brought early into dependency chain? The tool is being used for a specific purpose at build time. Its not exposed on target and its use is extremely constrained to a specific set of files where its behaviour should be deterministic. As such, yes there are questions about bug fixes and about security but I don't think its going to be a serious burden. We'd need to carry this until such times as the host systems we support have hardlink which is probably a few years out but will arrive. The impact of having util-linux-native in the dependency graph at this point is significant. I say that as someone who has done a lot of work in trimming down the times of our bootstrap process. This is exactly the kind of dependency I've removed and avoided. glibc is special in that its the worst choke point on the dependency graph. Nothing to do with target binaries happens until it is ready and then gcc-runtime can build. Whilst the locales are split from glibc, they are still connected in the task graph for packaging purposes so this is important. Its been pointed out there are other places where util-linux-native has crept in, in particular python3-native. My preference would be to minimise these dependencies rather than use them as a way to justify adding it here too. So what is the consensus here? Can we require the host system to have hardlink? It is available as a stand alone binary on Ubuntu 14.04 and up and on Fedora systems, but isn't installed by default, and we'd have to check the version because the arguments sadly are slightly different. We could certainly make util-linux a dependency, but that is why this patch existed, in order to avoid the dependency. I did find a python version at https://raw.githubusercontent.com/akaihola/hardlinkpy/master/hardlink.py. I made a one line modification to it and it works, but it isn't nearly as efficient. The proof is below, using the same locale-tree each time. It is important to look at both the real and user time. The difference gets more significant when you run it under pseudo, where we expect it to run 100% of the time. It is roughly 10x slower to do this in python. time recipe-sysroot-native/usr/bin/cross-localedef-hardlink -c -v locale-tree Directories: 982 Objects: 7441 Regular files: 6441 Comparisons: 3331 Linked: 3109 Saved: 754675712 real 0m0.641s user 0m0.120s sys 0m0.518s time python3 hardlink.py -v 0 -c locale-tree Hard linking Statistics: Directories : 982 Regular files : 6441 Comparisons : 31884 Hardlinked this run : 3109 Total hardlinks : 3109 Bytes saved this run : 744089843 (709.619 mebibytes) Total bytes saved : 744089843 (709.619 mebibytes) Total run time : 2.124422073364258 seconds real 0m2.180s user 0m1.220s sys 0m0.953s Now lets run it under pseudo time recipe-sysroot-native/usr/bin/cross-localedef-hardlink -c -v locale-tree Directories: 982 Objects: 7441 Regular files: 6441 Comparisons: 3331 Linked: 3109 Saved: 754675712 real 0m2.505s user 0m0.373s sys 0m1.286s time python3 hardlink.py -v 0 -c locale-tree Hard linking Statistics: Directories : 982 Regular files : 6441 Comparisons : 31884 Hardlinked this run : 3109 Total hardlinks : 3109 Bytes saved this run : 744089843 (709.619 mebibytes) Total bytes saved : 744089843 (709.619 mebibytes) Total run time : 12.971824884414673 seconds real 0m13.046s user 0m3.633s sys 0m5.192s -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/2] cross-localedef-native: Add hardlink resolver from util-linux
On Fri, 2019-08-16 at 14:29 -0700, Khem Raj wrote: > On Fri, Aug 16, 2019 at 2:25 PM Richard Purdie > wrote: > > This was discussed on IRC. We really really want to avoid that as a > > dependency if we care about build performance. Its really easy to > > just > > add that in but the implications are significant :( > > > > A captured version of this utility would also mean that we have to > keep this in sync for bug fixes and security fixes etc. which could > also be considered as expense, so how much do we lose if util-linux- > native is brought early into dependency chain? The tool is being used for a specific purpose at build time. Its not exposed on target and its use is extremely constrained to a specific set of files where its behaviour should be deterministic. As such, yes there are questions about bug fixes and about security but I don't think its going to be a serious burden. We'd need to carry this until such times as the host systems we support have hardlink which is probably a few years out but will arrive. The impact of having util-linux-native in the dependency graph at this point is significant. I say that as someone who has done a lot of work in trimming down the times of our bootstrap process. This is exactly the kind of dependency I've removed and avoided. glibc is special in that its the worst choke point on the dependency graph. Nothing to do with target binaries happens until it is ready and then gcc-runtime can build. Whilst the locales are split from glibc, they are still connected in the task graph for packaging purposes so this is important. Its been pointed out there are other places where util-linux-native has crept in, in particular python3-native. My preference would be to minimise these dependencies rather than use them as a way to justify adding it here too. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/2] cross-localedef-native: Add hardlink resolver from util-linux
On 8/16/19 4:29 PM, Khem Raj wrote: > On Fri, Aug 16, 2019 at 2:25 PM Richard Purdie > wrote: >> >> On Fri, 2019-08-16 at 14:22 -0700, Khem Raj wrote: >>> On Fri, Aug 16, 2019 at 2:06 PM Jason Wessel < >>> jason.wes...@windriver.com> wrote: The hard link resolver that is built into localedef cannot be run in parallel. It will search sibling directories (which are be processed in parallel) and perform a creation of a .tmp file and remove the original and move the .tmp file in. The problem is that if a probe occurs a hard link can be requested to the file that is being removed. This will lead to a stray copy or potentially, on a loaded system cause race condition which pseudo cannot deal with, where it is left with a hard link request to a file that no longer exists. In this situation psuedo will inherit the permissions of what ever the target inode had to offer. In short, there are two problems: 1) You will be left with stray copies when using the hard link resolution that is built in while running in parallel with localedef. 2) When running under pseudo the possibility exists for uid/gid leakage when the source file is removed before the hard link can be completed. The solution is to call localedef with --no-hard-links and separately process the hardlinks at a later point. To do this requires the inclusion of the hardlink utility found in modern versions of util-linux. Most host systems do not have this, so it will be included with the cross-localedef binary. >>> >>> can we depend on util-linux-native for this ? >> >> This was discussed on IRC. We really really want to avoid that as a >> dependency if we care about build performance. Its really easy to just >> add that in but the implications are significant :( >> > > A captured version of this utility would also mean that we have to > keep this in sync > for bug fixes and security fixes etc. which could also be considered > as expense, so > how much do we lose if util-linux-native is brought early into dependency > chain? security should not be a significant concern here as the utility is only local (and used by) the localdef build (consider it an internal to the recipe) tool. So I'm not concerned about that. As for the bug fixes, this utility is quite stable and the last changes were simply to move it from a standalone utility into util-linux. So again, I find it unlikely but again since it's an internal tool unless it impacted the cross localedef functionality it's unlikely to be a problem. Longer term, as hardlink becomes standard on distributions then the need for the local tool should go away, and it can be removed at that time. But currently it's only common on Red Hat lineage machines, while Debian and Ubuntu either have their own versions, or it's "optional" and not part of the regular distribution (even though it comes from util-linux). --Mark >> Cheers, >> >> Richard >> >> >> -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/2] cross-localedef-native: Add hardlink resolver from util-linux
On Fri, Aug 16, 2019 at 2:25 PM Richard Purdie wrote: > > On Fri, 2019-08-16 at 14:22 -0700, Khem Raj wrote: > > On Fri, Aug 16, 2019 at 2:06 PM Jason Wessel < > > jason.wes...@windriver.com> wrote: > > > The hard link resolver that is built into localedef cannot be run > > > in > > > parallel. It will search sibling directories (which are be > > > processed > > > in parallel) and perform a creation of a .tmp file and remove the > > > original and move the .tmp file in. The problem is that if a probe > > > occurs a hard link can be requested to the file that is being > > > removed. > > > This will lead to a stray copy or potentially, on a loaded system > > > cause race condition which pseudo cannot deal with, where it is > > > left > > > with a hard link request to a file that no longer exists. In this > > > situation psuedo will inherit the permissions of what ever the > > > target > > > inode had to offer. > > > > > > In short, there are two problems: > > > > > > 1) You will be left with stray copies when using the hard link > > > resolution that is built in while running in parallel with > > > localedef. > > > > > > 2) When running under pseudo the possibility exists for uid/gid > > > leakage when the source file is removed before the hard link > > > can > > > be completed. > > > > > > The solution is to call localedef with --no-hard-links and > > > separately > > > process the hardlinks at a later point. To do this requires the > > > inclusion of the hardlink utility found in modern versions of > > > util-linux. Most host systems do not have this, so it will be > > > included with the cross-localedef binary. > > > > > > > can we depend on util-linux-native for this ? > > This was discussed on IRC. We really really want to avoid that as a > dependency if we care about build performance. Its really easy to just > add that in but the implications are significant :( > A captured version of this utility would also mean that we have to keep this in sync for bug fixes and security fixes etc. which could also be considered as expense, so how much do we lose if util-linux-native is brought early into dependency chain? > Cheers, > > Richard > > > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/2] cross-localedef-native: Add hardlink resolver from util-linux
On Fri, 2019-08-16 at 14:22 -0700, Khem Raj wrote: > On Fri, Aug 16, 2019 at 2:06 PM Jason Wessel < > jason.wes...@windriver.com> wrote: > > The hard link resolver that is built into localedef cannot be run > > in > > parallel. It will search sibling directories (which are be > > processed > > in parallel) and perform a creation of a .tmp file and remove the > > original and move the .tmp file in. The problem is that if a probe > > occurs a hard link can be requested to the file that is being > > removed. > > This will lead to a stray copy or potentially, on a loaded system > > cause race condition which pseudo cannot deal with, where it is > > left > > with a hard link request to a file that no longer exists. In this > > situation psuedo will inherit the permissions of what ever the > > target > > inode had to offer. > > > > In short, there are two problems: > > > > 1) You will be left with stray copies when using the hard link > > resolution that is built in while running in parallel with > > localedef. > > > > 2) When running under pseudo the possibility exists for uid/gid > > leakage when the source file is removed before the hard link > > can > > be completed. > > > > The solution is to call localedef with --no-hard-links and > > separately > > process the hardlinks at a later point. To do this requires the > > inclusion of the hardlink utility found in modern versions of > > util-linux. Most host systems do not have this, so it will be > > included with the cross-localedef binary. > > > > can we depend on util-linux-native for this ? This was discussed on IRC. We really really want to avoid that as a dependency if we care about build performance. Its really easy to just add that in but the implications are significant :( Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/2] cross-localedef-native: Add hardlink resolver from util-linux
On Fri, Aug 16, 2019 at 2:06 PM Jason Wessel wrote:
>
> The hard link resolver that is built into localedef cannot be run in
> parallel. It will search sibling directories (which are be processed
> in parallel) and perform a creation of a .tmp file and remove the
> original and move the .tmp file in. The problem is that if a probe
> occurs a hard link can be requested to the file that is being removed.
> This will lead to a stray copy or potentially, on a loaded system
> cause race condition which pseudo cannot deal with, where it is left
> with a hard link request to a file that no longer exists. In this
> situation psuedo will inherit the permissions of what ever the target
> inode had to offer.
>
> In short, there are two problems:
>
> 1) You will be left with stray copies when using the hard link
> resolution that is built in while running in parallel with
> localedef.
>
> 2) When running under pseudo the possibility exists for uid/gid
> leakage when the source file is removed before the hard link can
> be completed.
>
> The solution is to call localedef with --no-hard-links and separately
> process the hardlinks at a later point. To do this requires the
> inclusion of the hardlink utility found in modern versions of
> util-linux. Most host systems do not have this, so it will be
> included with the cross-localedef binary.
>
can we depend on util-linux-native for this ?
> There are two patches here. The first imports the raw version of
> hardlink.c and a couple of header files directly from util-linux. The
> second patch applies the fix-ups to make it compile, along with a
> change to recipe to package the new binary.
>
> [YOCTO #11299]
> [YOCTO #12434]
>
> Signed-off-by: Jason Wessel
> ---
> .../glibc/cross-localedef-native_2.30.bb |3 +
> .../glibc/add-cross-localedef-hardlink.patch | 1115 +
> ...le-separate-from-util-linux-hardlink.patch | 226
> 3 files changed, 1344 insertions(+)
> create mode 100644
> meta/recipes-core/glibc/glibc/add-cross-localedef-hardlink.patch
> create mode 100644
> meta/recipes-core/glibc/glibc/allow-compile-separate-from-util-linux-hardlink.patch
>
> diff --git a/meta/recipes-core/glibc/cross-localedef-native_2.30.bb
> b/meta/recipes-core/glibc/cross-localedef-native_2.30.bb
> index e4923c73d5..29cd43e89a 100644
> --- a/meta/recipes-core/glibc/cross-localedef-native_2.30.bb
> +++ b/meta/recipes-core/glibc/cross-localedef-native_2.30.bb
> @@ -30,6 +30,8 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \
>
> file://0022-eglibc-Forward-port-cross-locale-generation-support.patch \
> file://0023-Define-DUMMY_LOCALE_T-if-not-defined.patch \
>
> file://0024-localedef-add-to-archive-uses-a-hard-coded-locale-pa.patch \
> + file://add-cross-localedef-hardlink.patch \
> + file://allow-compile-separate-from-util-linux-hardlink.patch \
> "
> # Makes for a rather long rev (22 characters), but...
> #
> @@ -43,4 +45,5 @@ CFLAGS += "-fgnu89-inline -std=gnu99 -DIS_IN\(x\)='0'"
> do_install() {
> install -d ${D}${bindir}
> install -m 0755 ${B}/localedef ${D}${bindir}/cross-localedef
> + install -m 0755 ${B}/cross-localedef-hardlink
> ${D}${bindir}/cross-localedef-hardlink
> }
> diff --git a/meta/recipes-core/glibc/glibc/add-cross-localedef-hardlink.patch
> b/meta/recipes-core/glibc/glibc/add-cross-localedef-hardlink.patch
> new file mode 100644
> index 00..8471121949
> --- /dev/null
> +++ b/meta/recipes-core/glibc/glibc/add-cross-localedef-hardlink.patch
> @@ -0,0 +1,1115 @@
> +---
> + locale/programs/c.h| 407 ++
> + locale/programs/cross-localedef-hardlink.c | 528
> +
> + locale/programs/xalloc.h | 129 +++
> + localedef/Makefile.in |8
> + 4 files changed, 1071 insertions(+), 1 deletion(-)
> +
> +--- /dev/null
> b/locale/programs/cross-localedef-hardlink.c
> +@@ -0,0 +1,528 @@
> ++/*
> ++ * hardlink - consolidate duplicate files via hardlinks
> ++ *
> ++ * Copyright (C) 2018 Red Hat, Inc. All rights reserved.
> ++ * Written by Jakub Jelinek
> ++ *
> ++ * Copyright (C) 2019 Karel Zak
> ++ *
> ++ * This program is free software; you can redistribute it and/or modify
> ++ * it under the terms of the GNU General Public License as published by
> ++ * the Free Software Foundation; either version 2 of the License, or
> ++ * (at your option) any later version.
> ++ *
> ++ * This program is distributed in the hope that it would be useful,
> ++ * but WITHOUT ANY WARRANTY; without even the implied warranty of
> ++ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> ++ * GNU General Public License for more details.
> ++ *
> ++ * You should have received a copy of the GNU General Public License along
> ++ * with this program; if not, write to the Free Software Foundation, Inc.,
> ++ *
[OE-core] [RFC PATCH 1/2] cross-localedef-native: Add hardlink resolver from util-linux
The hard link resolver that is built into localedef cannot be run in
parallel. It will search sibling directories (which are be processed
in parallel) and perform a creation of a .tmp file and remove the
original and move the .tmp file in. The problem is that if a probe
occurs a hard link can be requested to the file that is being removed.
This will lead to a stray copy or potentially, on a loaded system
cause race condition which pseudo cannot deal with, where it is left
with a hard link request to a file that no longer exists. In this
situation psuedo will inherit the permissions of what ever the target
inode had to offer.
In short, there are two problems:
1) You will be left with stray copies when using the hard link
resolution that is built in while running in parallel with
localedef.
2) When running under pseudo the possibility exists for uid/gid
leakage when the source file is removed before the hard link can
be completed.
The solution is to call localedef with --no-hard-links and separately
process the hardlinks at a later point. To do this requires the
inclusion of the hardlink utility found in modern versions of
util-linux. Most host systems do not have this, so it will be
included with the cross-localedef binary.
There are two patches here. The first imports the raw version of
hardlink.c and a couple of header files directly from util-linux. The
second patch applies the fix-ups to make it compile, along with a
change to recipe to package the new binary.
[YOCTO #11299]
[YOCTO #12434]
Signed-off-by: Jason Wessel
---
.../glibc/cross-localedef-native_2.30.bb |3 +
.../glibc/add-cross-localedef-hardlink.patch | 1115 +
...le-separate-from-util-linux-hardlink.patch | 226
3 files changed, 1344 insertions(+)
create mode 100644
meta/recipes-core/glibc/glibc/add-cross-localedef-hardlink.patch
create mode 100644
meta/recipes-core/glibc/glibc/allow-compile-separate-from-util-linux-hardlink.patch
diff --git a/meta/recipes-core/glibc/cross-localedef-native_2.30.bb
b/meta/recipes-core/glibc/cross-localedef-native_2.30.bb
index e4923c73d5..29cd43e89a 100644
--- a/meta/recipes-core/glibc/cross-localedef-native_2.30.bb
+++ b/meta/recipes-core/glibc/cross-localedef-native_2.30.bb
@@ -30,6 +30,8 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \
file://0022-eglibc-Forward-port-cross-locale-generation-support.patch \
file://0023-Define-DUMMY_LOCALE_T-if-not-defined.patch \
file://0024-localedef-add-to-archive-uses-a-hard-coded-locale-pa.patch \
+ file://add-cross-localedef-hardlink.patch \
+ file://allow-compile-separate-from-util-linux-hardlink.patch \
"
# Makes for a rather long rev (22 characters), but...
#
@@ -43,4 +45,5 @@ CFLAGS += "-fgnu89-inline -std=gnu99 -DIS_IN\(x\)='0'"
do_install() {
install -d ${D}${bindir}
install -m 0755 ${B}/localedef ${D}${bindir}/cross-localedef
+ install -m 0755 ${B}/cross-localedef-hardlink
${D}${bindir}/cross-localedef-hardlink
}
diff --git a/meta/recipes-core/glibc/glibc/add-cross-localedef-hardlink.patch
b/meta/recipes-core/glibc/glibc/add-cross-localedef-hardlink.patch
new file mode 100644
index 00..8471121949
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc/add-cross-localedef-hardlink.patch
@@ -0,0 +1,1115 @@
+---
+ locale/programs/c.h| 407 ++
+ locale/programs/cross-localedef-hardlink.c | 528
+
+ locale/programs/xalloc.h | 129 +++
+ localedef/Makefile.in |8
+ 4 files changed, 1071 insertions(+), 1 deletion(-)
+
+--- /dev/null
b/locale/programs/cross-localedef-hardlink.c
+@@ -0,0 +1,528 @@
++/*
++ * hardlink - consolidate duplicate files via hardlinks
++ *
++ * Copyright (C) 2018 Red Hat, Inc. All rights reserved.
++ * Written by Jakub Jelinek
++ *
++ * Copyright (C) 2019 Karel Zak
++ *
++ * This program is free software; you can redistribute it and/or modify
++ * it under the terms of the GNU General Public License as published by
++ * the Free Software Foundation; either version 2 of the License, or
++ * (at your option) any later version.
++ *
++ * This program is distributed in the hope that it would be useful,
++ * but WITHOUT ANY WARRANTY; without even the implied warranty of
++ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
++ * GNU General Public License for more details.
++ *
++ * You should have received a copy of the GNU General Public License along
++ * with this program; if not, write to the Free Software Foundation, Inc.,
++ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
++ */
++#include
++#include
++#include
++#include
++#include
++#include
++#include
++#include
++#include
++#include
++#include
++#ifdef HAVE_PCRE
++# define PCRE2_CODE_UNIT_WIDTH 8
++# include
++#endif
++
++#include "c.h"
++#include
