Hello,

LilyPond failed to build on GNU Hurd because Hurd does not have PATH_MAX.
Fortunately, a workaround is available thanks to the combined effort of
Debian developers Don Armstrong (Debian package maintainer for LilyPond)
and Petter Reinholdtsen (Debian Hurd guru).

Petter expressed his wish to send this patch upstream to be included in
future releases of LilyPond, hence this bug report with the attached patch!
 :-)

A little bit of history:

2013-05-13, Don Armstrong <don AT debian.org>:

  Changelog for LilyPond Debian package version 2.16.2-2:

  * Patch around using PATH_MAX in flower/file-name.cc to have builds work
    on hurd (hopefully).

2014-09-10, Petter Reinholdtsen <pere AT hungry.com>, <pere AT debian.org>:

  https://bugs.debian.org/761036

  Hi.  The lilypond package do not build on hurd, even with a hurd patch
  in place.  The cause seem to be a typo in the file
  debian/patches/hurd_file_name_support, checking for _GNU_SOURCE_
  instead of _GNU_SOURCE (at least that is what the getcwd() manual page
  claim to look for).

  Attached is an updated patch, fixing that bug, a memory leak
  forgetting to release the memory allocated by get_current_dir_name(),
  and adding the same code in the test code.

  Please replace the patch in the current source with this new one, and
  consider sending it upstream. :)

2016-07-18, Dr. Tobias Quathamer <toddy AT debian.org>:

  Reviewed and committed the patch to the debian-experimental branch
  (intended for an experiment with LilyPond 2.19.x and Guile-2.x)
  in the LilyPond deb packaging git repository:


https://anonscm.debian.org/git/collab-maint/lilypond.git/commit/?h=debian-experimental&id=e56df084666dbf9905d90c062b1f462aeb6f5f4a

2017-01-27, me:

  Discovered the above, and cherry-picked Dr. Tobias's commit onto the
  "debian" (stable) branch with 2.18.2.

Many thanks!

Anthony
foka AT debian.org
Description: Hurd build without PATH_MAX; currently broken
Forwarded: no
Origin: vendor, https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=761036;filename=hurd_file_name_support;msg=5
Bug-Debian: https://bugs.debian.org/761036
Author: Don Armstrong <d...@debian.org>
Author: Petter Reinholdtsen <p...@hungry.com>
Reviewed-by: Dr. Tobias Quathamer <to...@debian.org>
Reviewed-by: Anthony Fok <f...@debian.org>
Last-Update: 2017-01-27
--- a/flower/file-name.cc
+++ b/flower/file-name.cc
@@ -96,9 +96,16 @@
 string
 get_working_directory ()
 {
+#ifdef _GNU_SOURCE
+  char *cwd = get_current_dir_name();
+  string scwd(cwd);
+  free(cwd);
+  return scwd;
+#else
   char cwd[PATH_MAX];
   // getcwd returns NULL upon a failure, contents of cwd would be undefined!
   return string (getcwd (cwd, PATH_MAX));
+#endif
 }
 
 /* Join components to full file_name. */
--- a/flower/test-file-path.cc
+++ b/flower/test-file-path.cc
@@ -6,12 +6,26 @@
 #include "yaffut.hh"
 #include "config.hh"
 
+string
+get_working_directory ()
+{
+#ifdef _GNU_SOURCE
+  char *cwd = get_current_dir_name();
+  string scwd(cwd);
+  free(cwd);
+  return scwd;
+#else
+  char cwd[PATH_MAX];
+  // getcwd returns NULL upon a failure, contents of cwd would be undefined!
+  return string (getcwd (cwd, PATH_MAX));
+#endif
+}
+
 TEST (File_path, Find)
 {
   char const *extensions[] = {"ly", "", 0};
   string file = "init";
-  char cwd[PATH_MAX];
-  if (!getcwd (cwd, PATH_MAX))
+  if (get_working_directory().empty())
     {
       cerr << "Could not get current work directory\n";
       exit (1);
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Reply via email to