Re: macOS 64-bit
On Thu, Jan 9, 2020 at 10:11 PM Marnen Laibow-Koser wrote: > On Thu, Jan 9, 2020 at 1:44 PM Marnen Laibow-Koser > wrote: > >> On Thu, Jan 9, 2020 at 12:15 PM Jonas Hahnfeld wrote: >> >>> Am Donnerstag, den 09.01.2020, 11:14 -0500 schrieb Marnen Laibow-Koser: >>> > >>> > >>> > On Thu, Jan 9, 2020 at 10:47 AM Jonas Hahnfeld >>> wrote: >>> > [...] >>> > > Running >>> > > $ diff -ur root/usr/ installer/LilyPond.app/Contents/Resources/ >>> > > in target/darwin-x86 reveals many files that I cannot attribute to >>> the >>> > > mentioned blacklist. Hence there must be additional mechanism that >>> > > determine which files go in and which do not. >>> > >>> > Hmm, interesting. I can't easily run that diff (because of not having >>> a GUB environment available); would you be willing to post the contents so >>> I can do research on that? >>> >>> Sure, here it is. >>> >> >> Thanks! I might add it to that Gist so everything is in one place. >> > > I think I am very close to having a working 64-bit Mac .app bundle, > probably about a day’s worth of work or less. Then I have to come up with > a good way of automating the process (my research notes and shell commands > I’m using are also in that Gist I posted a link to). > And SUCCESS! I have a working 64-bit Mac .app bundle build of LilyPond 2.19.83, and I just used it to typeset a chamber work of mine without problems. Build info (such as it is) is at the Gist at https://gist.github.com/marnen/137b056d95b1c8400af8f823dced54f0 ; I'll be putting this into a proper repo and automating it for CI (probably either GitLab CI or Buildkite) soon. I'd really appreciate fellow Mac users testing the build and reporting any issues you find. (Karlin? Carl?) You can download it at https://drive.google.com/open?id=18b1nX5nJsBrzDBGqga9T753oCL8ilwqs ; it should work on any recent version of Mac OS. I'm particularly interested in reports from Catalina users, but really, at this point, any information is useful. If it seems like it works, I'd recommend putting it on the website's download page so that Mac users have something to work with... Best, -- Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org
Re: macOS 64-bit
On Fri, Jan 10, 2020 at 7:57 PM Marnen Laibow-Koser wrote: > On Fri, Jan 10, 2020 at 10:45 AM Marnen Laibow-Koser > wrote: > >> >> >> On Fri, Jan 10, 2020 at 10:19 AM Jonas Hahnfeld wrote: >> >>> Am Freitag, den 10.01.2020, 09:04 -0500 schrieb Marnen Laibow-Koser: >>> > On Fri, Jan 10, 2020 at 2:29 AM Jonas Hahnfeld >>> wrote: >> >> [...] >> >>> > > From my experiments, this is where LilyPond's relocation kicks in. I >>> > > think you have to provide .reloc files in etc/relocation, that's also >>> > > what GUB does. >>> > >>> > Yup, I copied those over from the GUB-built bundle. I'm not quite >>> sure how they work, but it looks like the LilyPond executable looks for >>> them on startup, right? >>> >>> Yes, I think that's in lily/relocate.cc. >> >> >> Right. I’ve been trying to understand what goes on in there. >> >> >>> >>> > Unfortunately, I don't quite see how to set the right path in those: >>> an .app bundle is movable, and while the Mac OS path resolver has a special >>> notation (@executable_path) for the path of the executable within that >>> bundle, it doesn't seem to put it into an environment variable in any >>> useful way. I tried @executable_path in those pathnames, but it didn't >>> *seem* to work; OTOH, it changed enough behavior that further research may >>> be worth while. >>> >>> LilyPond sets INSTALLER_PREFIX to the directory where bin/, lib/, >>> share/ etc are. This worked quite well in my experiments, with the >>> files I provided. >> >> >> Oh, that variable is set by LilyPond? Awesome; that will make my life >> easier. >> >> I’m not sure it’s all working properly, though. It seems like relocate >> is setting the Guile library path correctly, and I’ve also set >> LTDL_LIBRARY_PATH, but it’s still not finding ice-9/boot.scm, even though >> it’s in the appropriate directory. >> > > I was wrong about ice-9 being the issue; that seems to have been fixed > with GUILE_LOAD_PATH and/or LDTL_LIBRARY_PATH. However, while the load > path is being set properly, load-extension in Guile is looking for dylibs > in the wrong place (specifically, in LilyPond.app/Contents/Resources/var, > as well as a couple of related paths and some /usr/lib-type directories). > I can't figure out how to change that setting, and Guile's docs are not > very clear on how to set the extensiondir. Any ideas before I just give up > and put the libraries in var? > Please disregard. I had misspelled LTDL as LDTL. Grr. > > Best, > -- > Marnen Laibow-Koser > mar...@marnen.org > http://www.marnen.org > -- Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org
Re: macOS 64-bit
On Fri, Jan 10, 2020 at 10:45 AM Marnen Laibow-Koser wrote: > > > On Fri, Jan 10, 2020 at 10:19 AM Jonas Hahnfeld wrote: > >> Am Freitag, den 10.01.2020, 09:04 -0500 schrieb Marnen Laibow-Koser: >> > On Fri, Jan 10, 2020 at 2:29 AM Jonas Hahnfeld >> wrote: > > [...] > >> > > From my experiments, this is where LilyPond's relocation kicks in. I >> > > think you have to provide .reloc files in etc/relocation, that's also >> > > what GUB does. >> > >> > Yup, I copied those over from the GUB-built bundle. I'm not quite sure >> how they work, but it looks like the LilyPond executable looks for them on >> startup, right? >> >> Yes, I think that's in lily/relocate.cc. > > > Right. I’ve been trying to understand what goes on in there. > > >> >> > Unfortunately, I don't quite see how to set the right path in those: an >> .app bundle is movable, and while the Mac OS path resolver has a special >> notation (@executable_path) for the path of the executable within that >> bundle, it doesn't seem to put it into an environment variable in any >> useful way. I tried @executable_path in those pathnames, but it didn't >> *seem* to work; OTOH, it changed enough behavior that further research may >> be worth while. >> >> LilyPond sets INSTALLER_PREFIX to the directory where bin/, lib/, >> share/ etc are. This worked quite well in my experiments, with the >> files I provided. > > > Oh, that variable is set by LilyPond? Awesome; that will make my life > easier. > > I’m not sure it’s all working properly, though. It seems like relocate is > setting the Guile library path correctly, and I’ve also set > LTDL_LIBRARY_PATH, but it’s still not finding ice-9/boot.scm, even though > it’s in the appropriate directory. > I was wrong about ice-9 being the issue; that seems to have been fixed with GUILE_LOAD_PATH and/or LDTL_LIBRARY_PATH. However, while the load path is being set properly, load-extension in Guile is looking for dylibs in the wrong place (specifically, in LilyPond.app/Contents/Resources/var, as well as a couple of related paths and some /usr/lib-type directories). I can't figure out how to change that setting, and Guile's docs are not very clear on how to set the extensiondir. Any ideas before I just give up and put the libraries in var? Best, -- Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org
Re: GUB build error
On Jan 10, 2020, at 16:21, Dan Eble wrote: > > It seems that this implementation of the standard library declares ::isinf > when is included. The three solutions I can think of are (a) > finish issue 4550, (b) require a version of the library that does not do > this, or (c) investigate whether it is possible to avoid including > or any other header that triggers the same problem. > > I've been working on issue 4550. During a much-needed dinner, the most obvious solution occurred to me, which is to qualify the calls to std::isinf, std::isnan, etc. everywhere. This is a subset of issue 4550, but I'll try to add it to the patch for issue 5658 in time for you to test tomorrow. — Dan https://sourceforge.net/p/testlilyissues/issues/5658/
Re: GUB build error
On Jan 10, 2020, at 15:52, Michael Käppler wrote: > > Hi Dan, > GUB still fails to build lilypond in offset.cc. See attached log. > Anyone out here using LilyDev1, who can build current master through GUB? > Now testing, if I can build release/unstable. > > What I would like to understand is why this issue does arise only within > GUB and > not for a normal build. > Could you give me a hint? /home/dev/gub/target/linux-64/src/lilypond-localhost--lilypond.git-issue5658/flower/offset.cc:41:25: note: candidates are: In file included from /home/dev/gub/target/linux-64/root/usr/cross/lib/gcc/x86_64-linux/4.9.4/include-fixed/features.h:317:0, from /home/dev/gub/target/linux-64/root/usr/include/assert.h:36, from /home/dev/gub/target/linux-64/root/usr/cross/x86_64-linux/include/c++/4.9.4/cassert:43, from /home/dev/gub/target/linux-64/src/lilypond-localhost--lilypond.git-issue5658/flower/include/axis.hh:23, from /home/dev/gub/target/linux-64/src/lilypond-localhost--lilypond.git-issue5658/flower/include/offset.hh:23, from /home/dev/gub/target/linux-64/src/lilypond-localhost--lilypond.git-issue5658/flower/offset.cc:20: /home/dev/gub/target/linux-64/root/usr/include/bits/mathcalls.h:202:1: note: int isinf(double) It seems that this implementation of the standard library declares ::isinf when is included. The three solutions I can think of are (a) finish issue 4550, (b) require a version of the library that does not do this, or (c) investigate whether it is possible to avoid including or any other header that triggers the same problem. I've been working on issue 4550. — Dan
Re: GUB build error
Hi Dan,
GUB still fails to build lilypond in offset.cc. See attached log.
Anyone out here using LilyDev1, who can build current master through GUB?
Now testing, if I can build release/unstable.
What I would like to understand is why this issue does arise only within
GUB and
not for a normal build.
Could you give me a hint?
Cheers,
Michael
Am 09.01.2020 um 22:49 schrieb Dan Eble:
On Jan 9, 2020, at 10:09, Dan Eble wrote:
On Jan 9, 2020, at 07:32, Michael Käppler wrote:
/home/dev/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-master/flower/offset.cc:132:23:
error: call of overloaded 'isinf(Real&)' is ambiguous
if (isinf (d[X_AXIS]))
Maybe it's time to take another shot at issue 4550, "Avoid 'using' directives in
included files." I can't say I relish the thought, but I will try to motivate
myself.
https://sourceforge.net/p/testlilyissues/issues/4550/
If you're up to testing it, I'd like to know if this patch solves your problem.
https://codereview.appspot.com/569220043/
Thanks,
—
Dan
* Starting build: Fri Jan 10 21:05:23 2020
must rebuild: linux-64::lilypond
*** Checksum mismatch: diff (lilypond, linux-64)
---
/home/dev/gub/target/linux-64/packages/lilypond-localhost--lilypond.git-issue5658.checksum
+++ THIS BUILD Fri Jan 10 21:05:20 2020
@@ -1 +1,330 @@
-
+UpdateSourceDir(tracking)
*** Checksum mismatch: diff (lilypond, linux-64)
---
/home/dev/gub/target/linux-64/packages/lilypond-localhost--lilypond.git-issue5658.checksum
+++ THIS BUILD Fri Jan 10 21:05:20 2020
@@ -1 +1,330 @@
-
+UpdateSourceDir(tracking)
+Dump
+/home/dev/gub/target/linux-64/status/lilypond-2.21.0-a8b88f894988d37f3721b6b917936a922fd4d2f1
+untar
+Dump
+/home/dev/gub/target/linux-64/status/lilypond-2.21.0-a8b88f894988d37f3721b6b917936a922fd4d2f1
+patch
+cd
/home/dev/gub/target/linux-64/src/lilypond-localhost--lilypond.git-issue5658 &&
./smart-autogen.sh --noconfigure
+Dump
+/home/dev/gub/target/linux-64/status/lilypond-2.21.0-a8b88f894988d37f3721b6b917936a922fd4d2f1
+autoupdate
+mkdir -p
/home/dev/gub/target/linux-64/build/lilypond-localhost--lilypond.git-issue5658
|| true
+Dump
+/home/dev/gub/target/linux-64/build/lilypond-localhost--lilypond.git-issue5658/config.cache
+
+ac_cv_c_stack_direction=${ac_cv_c_stack_direction=-1}
+ac_cv_func_getpgrp_void=${ac_cv_func_getpgrp_void=yes}
+ac_cv_func_select=${ac_cv_func_select=yes} # but in mingw only if winsock2.h
+ac_cv_func_setvbuf_reversed=${ac_cv_func_setvbuf_reversed=no}
+ac_cv_lib_dld_shl_load=${ac_cv_lib_dld_shl_load=no}
+ac_cv_spinlocks=${ac_cv_spinlocks=no}
+ac_cv_sprintf_count=${ac_cv_sprintf_count=yes}
+ac_cv_sys_restartable_syscalls=${ac_cv_sys_restartable_syscalls=yes}
+libltdl_cv_sys_search_path=${libltdl_cv_sys_search_path="'"/home/dev/gub/target/linux-64/root/usr/lib
/home/dev/gub/target/linux-64/root/lib"'"}
+lt_cv_dlopen=${lt_cv_dlopen="dlopen"}
+
+ac_cv_file__dev_ptc=${ac_cv_file__dev_ptc=no}
+ac_cv_file__dev_ptmx=${ac_cv_file__dev_ptmx=yes}
+ac_cv_func_posix_getgrgid_r=${ac_cv_func_posix_getgrgid_r=yes}
+ac_cv_func_posix_getpwuid_r=${ac_cv_func_posix_getpwuid_r=yes}
+ac_cv_lib_dl_dlopen=${ac_cv_lib_dl_dlopen=yes}
+ac_cv_search_dlopen=${ac_cv_search_dlopen="-ldl"}
+glib_cv_uscore=${glib_cv_uscore=no}
+libltdl_cv_sys_search_path=${libltdl_cv_sys_search_path="'"/home/dev/gub/target/linux-64/root/usr/lib
/home/dev/gub/target/linux-64/root/lib"'"}
+lt_cv_dlopen_libs=${lt_cv_dlopen_libs="-ldl"}
+lt_cv_sys_max_cmd_len=${lt_cv_sys_max_cmd_len=32768}
+
+ac_16bit_type=${ac_16bit_type=short}
+ac_32bit_type=${ac_32bit_type=int}
+ac_64bit_type=${ac_64bit_type=long}
+ac_cv_c_long_size_t=${ac_cv_c_long_size_t=yes}
+ac_cv_c_long_time_t=${ac_cv_c_long_time_t=yes}
+ac_cv_sizeof___int64=${ac_cv_sizeof___int64=0}
+ac_cv_sizeof_char=${ac_cv_sizeof_char=1}
+ac_cv_sizeof_char_p=${ac_cv_sizeof_char_p=8}
+ac_cv_sizeof_double=${ac_cv_sizeof_double=8}
+ac_cv_sizeof_float=${ac_cv_sizeof_float=4}
+ac_cv_sizeof_int=${ac_cv_sizeof_int=4}
+ac_cv_sizeof_intmax_t=${ac_cv_sizeof_intmax_t=8}
+ac_cv_sizeof_intptr_t=${ac_cv_sizeof_intptr_t=8}
+ac_cv_sizeof_long=${ac_cv_sizeof_long=8}
+ac_cv_sizeof_long_double=${ac_cv_sizeof_long_double=16}
+ac_cv_sizeof_long_long=${ac_cv_sizeof_long_long=8}
+ac_cv_sizeof_ptrdiff_t=${ac_cv_sizeof_ptrdiff_t=8}
+ac_cv_sizeof_short=${ac_cv_sizeof_short=2}
+ac_cv_sizeof_size_t=${ac_cv_sizeof_size_t=8}
+ac_cv_sizeof_uintptr_t=${ac_cv_sizeof_uintptr_t=8}
+ac_cv_sizeof_unsigned___int64=${ac_cv_sizeof_unsigned___int64=0}
+ac_cv_sizeof_unsigned_char=${ac_cv_sizeof_unsigned_char=1}
+ac_cv_sizeof_unsigned_int=${ac_cv_sizeof_unsigned_int=4}
+ac_cv_sizeof_unsigned_long=${ac_cv_sizeof_unsigned_long=8}
+ac_cv_sizeof_unsigned_long_long=${ac_cv_sizeof_unsigned_long_long=8}
+ac_cv_sizeof_unsigned_short=${ac_cv_sizeof_unsigned_short=2}
+ac_cv_sizeof_void_p=${ac_cv_sizeof_void_p=8}
+
+mkdir -p
/home/dev/gub/target/linux-64/build/lilypond-localhost--lilypond.git-issue5658
|| true
+cd
Re: macOS 64-bit
On Fri, Jan 10, 2020 at 10:19 AM Jonas Hahnfeld wrote: > Am Freitag, den 10.01.2020, 09:04 -0500 schrieb Marnen Laibow-Koser: > > On Fri, Jan 10, 2020 at 2:29 AM Jonas Hahnfeld wrote: [...] > > > From my experiments, this is where LilyPond's relocation kicks in. I > > > think you have to provide .reloc files in etc/relocation, that's also > > > what GUB does. > > > > Yup, I copied those over from the GUB-built bundle. I'm not quite sure > how they work, but it looks like the LilyPond executable looks for them on > startup, right? > > Yes, I think that's in lily/relocate.cc. Right. I’ve been trying to understand what goes on in there. > > > Unfortunately, I don't quite see how to set the right path in those: an > .app bundle is movable, and while the Mac OS path resolver has a special > notation (@executable_path) for the path of the executable within that > bundle, it doesn't seem to put it into an environment variable in any > useful way. I tried @executable_path in those pathnames, but it didn't > *seem* to work; OTOH, it changed enough behavior that further research may > be worth while. > > LilyPond sets INSTALLER_PREFIX to the directory where bin/, lib/, > share/ etc are. This worked quite well in my experiments, with the > files I provided. Oh, that variable is set by LilyPond? Awesome; that will make my life easier. I’m not sure it’s all working properly, though. It seems like relocate is setting the Guile library path correctly, and I’ve also set LTDL_LIBRARY_PATH, but it’s still not finding ice-9/boot.scm, even though it’s in the appropriate directory. > > Jonas Best, -- Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail Mobile
Re: macOS 64-bit
Am Freitag, den 10.01.2020, 09:04 -0500 schrieb Marnen Laibow-Koser: > On Fri, Jan 10, 2020 at 2:29 AM Jonas Hahnfeld wrote: > > Am Freitag, den 10.01.2020, 01:07 -0500 schrieb Marnen Laibow-Koser: > > > > > > > > > On Fri, Jan 10, 2020 at 1:03 AM Werner LEMBERG wrote: > > > > > There is one lingering problem: when LilyPond calls Guile, Guile is > > > > > not finding the library files specified in load-extension > > > > > expressions, even though they *should* be in the right place. > > > > > Before I go too crazy searching, does anyone know what controls this > > > > > path choice? I'm assuming it may be a compilation option for the > > > > > LilyPond binary, but I really don't know. > > > > > > > > Here's a link to the script MacPorts is using to call lilypond. > > > > > > > > > > > > https://github.com/macports/macports-ports/blob/master/textproc/lilypond-devel/files/lilypond.in > > > > > > > > It seems you have to set LDTL_LIBRARY_PATH. > > > > > > I saw that, of course, but I’m not sure what that variable even is. In > > > particular, I have no reason to believe that it affects Guile’s load > > > path...but I’ll try it and see. Thanks for the reminder. > > > > > > I *think* that the Guile load path is the last issue standing between me > > > and a self-contained 64-bit Mac .app bundle. Everything else appears to > > > be working. > > > > From my experiments, this is where LilyPond's relocation kicks in. I > > think you have to provide .reloc files in etc/relocation, that's also > > what GUB does. > > Yup, I copied those over from the GUB-built bundle. I'm not quite sure how > they work, but it looks like the LilyPond executable looks for them on > startup, right? Yes, I think that's in lily/relocate.cc. > Unfortunately, I don't quite see how to set the right path in those: an .app > bundle is movable, and while the Mac OS path resolver has a special notation > (@executable_path) for the path of the executable within that bundle, it > doesn't seem to put it into an environment variable in any useful way. I > tried @executable_path in those pathnames, but it didn't *seem* to work; > OTOH, it changed enough behavior that further research may be worth while. LilyPond sets INSTALLER_PREFIX to the directory where bin/, lib/, share/ etc are. This worked quite well in my experiments, with the files I provided. Jonas signature.asc Description: This is a digitally signed message part
Re: macOS 64-bit
On Fri, Jan 10, 2020 at 2:29 AM Jonas Hahnfeld wrote: > Am Freitag, den 10.01.2020, 01:07 -0500 schrieb Marnen Laibow-Koser: > > > > > > On Fri, Jan 10, 2020 at 1:03 AM Werner LEMBERG wrote: > > > > There is one lingering problem: when LilyPond calls Guile, Guile is > > > > not finding the library files specified in load-extension > > > > expressions, even though they *should* be in the right place. > > > > Before I go too crazy searching, does anyone know what controls this > > > > path choice? I'm assuming it may be a compilation option for the > > > > LilyPond binary, but I really don't know. > > > > > > Here's a link to the script MacPorts is using to call lilypond. > > > > > > > https://github.com/macports/macports-ports/blob/master/textproc/lilypond-devel/files/lilypond.in > > > > > > It seems you have to set LDTL_LIBRARY_PATH. > > > > I saw that, of course, but I’m not sure what that variable even is. In > particular, I have no reason to believe that it affects Guile’s load > path...but I’ll try it and see. Thanks for the reminder. > > > > I *think* that the Guile load path is the last issue standing between me > and a self-contained 64-bit Mac .app bundle. Everything else appears to be > working. > > From my experiments, this is where LilyPond's relocation kicks in. I > think you have to provide .reloc files in etc/relocation, that's also > what GUB does. Yup, I copied those over from the GUB-built bundle. I'm not quite sure how they work, but it looks like the LilyPond executable looks for them on startup, right? Unfortunately, I don't quite see how to set the right path in those: an .app bundle is movable, and while the Mac OS path resolver has a special notation (@executable_path) for the path of the executable within that bundle, it doesn't seem to put it into an environment variable in any useful way. I tried @executable_path in those pathnames, but it didn't *seem* to work; OTOH, it changed enough behavior that further research may be worth while. I should say here that I don't know that much about Mac application packaging; I'm doing this mostly because no one else seemed interested to do it and I really want a 64-bit build. > It allows to dynamically set environment variables, in > this case GUILE_LOAD_PATH. > To point you to the next error in advance: You have to do the same for > Fontconfig or it can't find its config file > Ah, thanks for the warning. At this point I think it's all about path-munging. > > Hope this helps, > Jonas > Best, -- Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org
Re: Issue tracker access
"Michael Käppler" wrote 10/01/2020 07:02:42 Hi all, I would like to participate in LilyPond development (again, after many years - my last contributions date from 2009). Thus I'm asking for access to the Sourceforge issue tracker. My username is xmichael-k. Hi Michael, welcome back! You should now have access to the issue tracker with Create and Update permissions as well as Read. Trevor
Re: Poster for music engraving conference
Hello Fellows, in December Werner asked for a poster for the conference. Did somebody actually produce something? The last days I tried something based on the baposter-LaTeX-class. I'll not be able to finish the poster on my own until monday ... , but if you'd like to collaborate on this topic or you have a poster, I can donate some content to, please let me know! Jan-Peter Am 04.12.19 um 12:05 schrieb Werner LEMBERG: > > Folks, > > > the music engraving conference in Salzburg (January 17.-19.) aims to > present as much note engraving programs as possible. While some > companies send representatives (e.g., Dorico, Capella, Finale) – some > even with talks – we don't have something similar for LilyPond in the > main part of the conference. > > Instead, we would like to have a poster (in A0 format) that shows how > LilyPond works, together with some showcase results. > > Now my question: Are there people who are willing to produce such a > poster? Has anyone already done something similar for other > conferences? > > > Werner >
