Re: full-source bootstrap and Python
Bruno Haible writes: Hi! > Janneke Nieuwenhuizen wrote: >> Are are we creating a problem for >> bootstrapping (or even a dependency cycle) when introducing this new >> dependency into a certain package. > > I think you answered this question with "no", when writing in [1]: > > "Even more recently (2018), the GNU C Library glibc-2.28 adds Python >as a build requirement" How so? In 2013, the GCC folks decided that their gcc-4.8 would no longer be a directly bootstrappable compiler by introducing a (casual?) dependency on c++. That's pretty bad for bootstrapping, and it would be amazing if someone could revet that mistake. With glibc-2.28, a similar bootstrappable mistake was made. Making an essential GNU package such as GCC or Glibc non-bootstrappable has severe consequences. As an example, we have been working on the RISC-V bootstrap for about a year with three people. One of the problems here is that RISC-V was only added to a non-bootstrappable version of GCC: 7.5.0, while the GCC team failed to maintain their last bootstrappable version: 4.7.4. In other words, the RISC-V backend needed to backported and someone else now needs to maintain a bootstrappable version of GCC. When something else like this changes in the future, that isn't as "easily" backported, what do we do? Terrible! > So, how do you avoid Python when building glibc? Do you use musl libc as > a first stage, and only build glibc once a python built with musl exists? Currently we aren't directly hit by this because we build glibc-2.2.5 and glibc-2.16 first. We added these earlier Glibc's because we allowed ourcelves to cut some corners and there earlier versions were more easy to bootstrap. On the roadmap is to remove as many ancient versions as we can, as they are potential time-bombs. In fact, glibc-2.2.5 is problematic for the ARM and the RISC-V bootstrap, so we'll get rid of that. We won't be able to get rid of advancing beyond glibc-2.27 without adding a yet another non-GNU package such as musl libc. Possibly a nice hack for now, but what to do when we want to port the bootstrap to the Hurd? Again, terrible! > Also, from the diagrams in [1][2][3] it looks like the full-source bootstrap > uses tarballs frozen in time (make-3.80, gcc-2.95.3, gcc 4.7.3, etc.). So, > even if newer versions of 'make' or 'gcc' will use a Python-based gnulib-tool, > there won't be a problem, because the bootstrap of these old tarballs will > be unaffected. indeed. For the current situtation (that's less than great and are working on to resolve), making essential GNU packages less bootstrappable is of no consequence. Cleaning-up the full-source bootstrap and making it more or less future-proof, might be challenged by such a new dependency. Greetings, Janneke -- Janneke Nieuwenhuizen | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
Re: beta-tester call draft
Bernhard Voelker writes: > On 4/21/24 01:14, Bruno Haible wrote: >>- install Python on their development machines, > > I'd guess most hosts have python installed nowadays ... the question is > rather which version of it, and how compatible it is: What a host has installed (or could install) is of no consequence. A much more interesting question is: Are are we creating a problem for bootstrapping (or even a dependency cycle) when introducing this new dependency into a certain package. Greetings, Janneke -- Janneke Nieuwenhuizen | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
[PATCH] canonicalize-lgpl: Canonicalize casing too for MinGW.
* lib/canonicalize-lgpl.c (filesystem_name)[__MINGW32__]: New static
function.
(realpath_stk)[__MINGW32__]: Use it to return correct canonicalized
casing.
* tests/test-canonicalize-lgpl.c (main)[__MINGW32__]: Test it.
---
lib/canonicalize-lgpl.c| 37 ++
tests/test-canonicalize-lgpl.c | 12 +++
2 files changed, 49 insertions(+)
diff --git a/lib/canonicalize-lgpl.c b/lib/canonicalize-lgpl.c
index 92e9639720..baabcbdc25 100644
--- a/lib/canonicalize-lgpl.c
+++ b/lib/canonicalize-lgpl.c
@@ -41,6 +41,11 @@
#include
#include
+#if __MINGW32__
+#include
+#include
+#endif
+
#ifdef _LIBC
# include
# define GCC_LINT 1
@@ -180,6 +185,33 @@ get_path_max (void)
return path_max < 0 ? 1024 : path_max <= IDX_MAX ? path_max : IDX_MAX;
}
+#if __MINGW32__
+/* Return the basename of NAME as found on the filesystem, which may
+ or may not canonicalize the casing, or NULL if not found. */
+static char *
+filesystem_name (char const *name)
+{
+ char base_buf[PATH_MAX];
+ strcpy (base_buf, name);
+ char *base = basename (base_buf);
+
+ int select_base (struct dirent const* entry)
+ {
+return strcasecmp (entry->d_name, base) == 0;
+ }
+
+ char dir_buf[PATH_MAX];
+ strcpy (dir_buf, name);
+ char *dir = dirname (dir_buf);
+
+ struct dirent **name_list;
+ int i = scandir (dir, _list, select_base, NULL);
+ if (i == 1)
+return name_list[0]->d_name;
+ return NULL;
+}
+#endif
+
/* Act like __realpath (see below), with an additional argument
rname_buf that can be used as temporary storage.
@@ -322,6 +354,11 @@ realpath_stk (const char *name, char *resolved,
{
buf = link_buffer.data;
idx_t bufsize = link_buffer.length;
+#if __MINGW32__
+ char *fname = filesystem_name (rname);
+ if (fname)
+strcpy (rname + strlen (rname) - strlen (fname), fname);
+#endif
n = __readlink (rname, buf, bufsize - 1);
if (n < bufsize - 1)
break;
diff --git a/tests/test-canonicalize-lgpl.c b/tests/test-canonicalize-lgpl.c
index c0a5a55150..cf41a2a628 100644
--- a/tests/test-canonicalize-lgpl.c
+++ b/tests/test-canonicalize-lgpl.c
@@ -279,6 +279,18 @@ main (void)
free (result2);
}
+#if __MINGW32__
+ /* Check that \\ are changed into / and casing is canonicalized. */
+ {
+int fd = creat (BASE "/MinGW", 0600);
+ASSERT (0 <= fd);
+ASSERT (close (fd) == 0);
+
+char *result = canonicalize_file_name (BASE "\\mingw");
+ASSERT (strcmp (result, BASE "/MinGW");
+free (result);
+ }
+#endif
/* Cleanup. */
ASSERT (remove (BASE "/droot") == 0);
