Closed davert318 closed 1 year ago
Hi @davert318, thanks for your bug report for MacOS Sonoma. I see the same warnings in the github CI pipeline https://github.com/fredowski/homebrew-pspp/actions where pspp is build on MacOS 12.6.9. So I do not think that the xgettext warnings about the ITS are the cause for the build failure. Are there no errors further up the in the output? Unfortunately my Macbook runs on 12.7 so I cannot try on MacOS 14.
Hi - thanks for maintaining this excellent replacement for SPSS!
I didn’t see any but I’ll go through it again and check. Wish it was saving them in a log.
The build in the pipeline was 3 hours old. The current latest version pspp-2.0.0-pre2g2a803f also fails due to a failure in the regression. But this is the same on other platforms. So that has to be fixed first.
Aha! Quick work.
On Nov 1, 2023, at 3:34 PM, Friedrich Beckmann @.***> wrote:
The build in the pipeline was 3 hours old. The current latest version pspp-2.0.0-pre2g2a803f also fails due to a failure in the regression. But this is the same on other platforms. So that has to be fixed first.
The CI pipeline now works. Could try brew install --head --verbose pspp
?
Thanks! Trying it now… nope. I wish I knew homebrew better, so I could play with configuration.
All warnings… configure: WARNING: unrecognized options: --disable-debug PSPP configured successfully.
Oops, you were right, I missed this! (The prior error still shows up.)
This isn’t urgent, I should mention… I can wait...
libtool: compile: clang -DHAVE_CONFIG_H -DEXEEXT=\"\" -I. -I./gl -I./gl -DINSTALLDIR=\"/usr/local/Cellar/pspp/HEAD/bin\" -I./src -I./lib -Isrc -I./src/language/commands -I/private/tmp/pspp-20231102-25067-mg34li/pspp-2.0.0-pre2g2ec99d/src/language/expressions -I./src/language/expressions -Isrc -I/usr/local/Cellar/glib/2.78.1/include -I/usr/local/Cellar/glib/2.78.1/include/glib-2.0 -I/usr/local/Cellar/glib/2.78.1/lib/glib-2.0/include -I/usr/local/opt/gettext/include -I/usr/local/Cellar/pcre2/10.42/include -I/usr/local/opt/libpng/include/libpng16 -I/usr/local/opt/freetype/include/freetype2 -I/usr/local/Cellar/fontconfig/2.14.2/include -I/usr/local/Cellar/libxau/1.0.11/include -I/usr/local/Cellar/libxdmcp/1.1.4/include -I/usr/local/Cellar/libxcb/1.16/include -I/usr/local/Cellar/libx11/1.8.7/include -I/usr/local/Cellar/libxext/1.3.5/include -I/usr/local/Cellar/libxrender/0.9.11/include -I/usr/local/Cellar/pixman/0.42.2/include/pixman-1 -I/usr/local/Cellar/cairo/1.18.0/include/cairo -I/usr/local/Cellar/fribidi/1.0.13/include/fribidi -I/usr/local/Cellar/graphite2/1.3.14/include -I/usr/local/Cellar/harfbuzz/8.2.2/include/harfbuzz -I/usr/local/Cellar/pango/1.50.14/include/pango-1.0 -I/usr/local/Cellar/xorgproto/2023.2/include -I/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/ffi -Wall -Wextra -Wwrite-strings -Wstrict-prototypes -Wpointer-arith -Wno-sign-compare -Wmissing-prototypes -g -O2 -DGCC_LINT -fgnu89-inline -c src/ui/gui/psppire-marshal.c -o src/ui/gui/psppire-marshal.o >/dev/null 2>&1 src/ui/terminal/main.c:39:10: fatal error: 'gsl/gsl_errno.h' file not found
Tried relinking gsl which is already installed.
On Nov 2, 2023, at 12:59 PM, Friedrich Beckmann @.***> wrote:
The CI pipeline now works. Could try brew install --head --verbose pspp?
— Reply to this email directly, view it on GitHub https://github.com/fredowski/homebrew-pspp/issues/5#issuecomment-1791124438, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACQ7TJYHQG5NUFCCNT77CP3YCPGNVAVCNFSM6AAAAAA6ZV73CSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJRGEZDINBTHA. You are receiving this because you were mentioned.
Before I waste your time - I realized I could run brew doctor. I have some domestic issues to clean up first…sorry!
The latest problem was indeed my own. It builds but fails test 1327 - 1327: convert invalid UTF-8 to ISO-8859-1 This is much better! SO close!
Yes, that looks much better! The pspp package is build in a temporary directory that looks similar like this:
/private/tmp/pspp-20231104-4828-120vn4r/pspp-2.0.0-pre3g43669f
Could you go to that directory and find a file "tests/testsuite.log" ? That file contains the detailed in- und outputs during the failing tests. We would need that to get an idea why the test fails.
"Sam" runs into the same problem on MacOS 14 with arm based m1 hardware. He managed to read the "testsuite.log" file. Test "convert invalid UTF-8 to ISO-8859-1" fails. It seems that invalid UTF-8 is now catched in the conversion routine resulting in an abort.
## ---------------------- ##
## Detailed failed tests. ##
## ---------------------- ##
# -*- compilation -*-
1327. i18n.at:43: testing convert invalid UTF-8 to ISO-8859-1 ...
./i18n.at:43: i18n-test supports_encodings 'UTF-8' 'ISO-8859-1'
./i18n.at:43: i18n-test recode 'UTF-8' 'ISO-8859-1' 'xy\300z'
--- /dev/null 2023-11-04 10:54:08
+++ /private/tmp/pspp-20231104-37365-p8xoer/pspp-2.0.0-pre3g43669f/tests/testsuite.dir/at-groups/1327/stderr 2023-11-04 10:54:43
@@ -0,0 +1,3 @@
+Character conversion error: Operation not supported on socket
+Assertion failed: (0), function try_recode, file i18n.c, line 237.
+/private/tmp/pspp-20231104-37365-p8xoer/pspp-2.0.0-pre3g43669f/tests/testsuite.dir/at-groups/1327/test-source: line 40: 34529 Abort trap: 6 i18n-test recode 'UTF-8' 'ISO-8859-1' 'xy\300z'
--- - 2023-11-04 10:54:43
+++ /private/tmp/pspp-20231104-37365-p8xoer/pspp-2.0.0-pre3g43669f/tests/testsuite.dir/at-groups/1327/stdout 2023-11-04 10:54:43
@@ -1,2 +1 @@
-xy?z
./i18n.at:43: exit code was 134, expected 0
1327. i18n.at:43: 1327. convert invalid UTF-8 to ISO-8859-1 (i18n.at:43): FAILED (i18n.at:43)
Wonderful! Hope this issue will be fixed soon.
pspp uses the native MacOS iconv library on MacOS. It seems that Apple has changed the library by removing GNU GPL parts. The license changed from GNU GPL to BSD between MacOS 13 and MacOS 14. See discussion here: https://github.com/Homebrew/homebrew-core/pull/142490#issuecomment-1752444627 That would explain the different behaviour between MacOS 12 Monterey and MacOS 14 Sonoma.
I am not sure how to proceed from here. I see the option to use the GNU iconv library but my feeling is that this might result in clashes when different parts of pspp use different libraries (native <-> GNU iconv). The alternative would be to have platform dependent code in i18n.c which seems really bad.
It looks to me like Mac OS is using EOPNOTSUPP as if it were EILSEQ. The following change is worth a try:'
diff --git a/src/libpspp/i18n.c b/src/libpspp/i18n.c
index 5e9aa0d59c..7697ac614c 100644
--- a/src/libpspp/i18n.c
+++ b/src/libpspp/i18n.c
@@ -214,6 +215,7 @@ try_recode (struct converter *cvtr, char fallbackchar,
return out - 1 - out_;
case EILSEQ:
+ case EOPNOTSUPP:
if (outbytes == 0)
return -E2BIG;
if (!fallbackchar)
The new patch as described by Ben above landed in the latest source build and has been run on the CI pipeline. Could you give it a try on MacOS 14 by building with:
brew install --head --verbose --keep-tmp pspp
?
The problem on Somona also affects the stable 1.6.2 release as reported by M Ilham Setya Aji: https://lists.gnu.org/archive/html/bug-gnu-pspp/2023-11/msg00005.html
I'm doing it now but I think it froze on line 1326 (Sonoma, version 2):
i18n recoding
1323: convert reflexively ok 1324: convert without any change ok 1325: convert from ISO-8859-1 to UTF-8 ok 1326: convert from UTF-8 to ISO-8859-1 ok
I'm trying it again now.
make[3]: [tests_check] Error 1 make[2]: [check-am] Error 2 make[1]: [check-recursive] Error 1 make: [check] Error 2 ==> Temporary files retained at: /private/tmp/pspp-20231105-1748-6a79xk
1327: convert invalid UTF-8 to ISO-8859-1 FAILED (i18n.at:43) 1328: convert truncated UTF-8 to ISO-8559-1 ok
Very nice! Can you go to the directory
/private/tmp/pspp-20231105-1748-6a79xk/pspp-2.0.0-gXXXXXX
and then check there for a file "tests/testsuite.log"? That file contains the detailed test output. You can then upload the file here.
Thanks! The relevant part is:
1327. i18n.at:43: testing convert invalid UTF-8 to ISO-8859-1 ...
./i18n.at:43: i18n-test supports_encodings 'UTF-8' 'ISO-8859-1'
./i18n.at:43: i18n-test recode 'UTF-8' 'ISO-8859-1' 'xy\300z'
--- /dev/null 2023-11-05 17:18:50
+++ /private/tmp/pspp-20231105-1748-6a79xk/pspp-2.0.0-pre3g1799ab/tests/testsuite.dir/at-groups/1327/stderr 2023-11-05 17:18:57
@@ -0,0 +1 @@
+/private/tmp/pspp-20231105-1748-6a79xk/pspp-2.0.0-pre3g1799ab/tests/testsuite.dir/at-groups/1327/test-source: line 40: 98363 Killed: 9 i18n-test recode 'UTF-8' 'ISO-8859-1' 'xy\300z'
--- - 2023-11-05 17:18:58
+++ /private/tmp/pspp-20231105-1748-6a79xk/pspp-2.0.0-pre3g1799ab/tests/testsuite.dir/at-groups/1327/stdout 2023-11-05 17:18:58
@@ -1,2 +1 @@
-xy?z
./i18n.at:43: exit code was 137, expected 0
1327. i18n.at:43: 1327. convert invalid UTF-8 to ISO-8859-1 (i18n.at:43): FAILED (i18n.at:43)
So Apple iconv does not simply have a different error number...
The Apple iconv is broken then. If you use it instead of GNU iconv, then PSPP will be broken too. Disabling the test will just hide that.
You said something earlier about mixing GNU and Apple iconv. What did you mean by that? I think that it is better if PSPP only uses GNU iconv, not a mix of the wo.
On Sun, Nov 5, 2023 at 9:41 AM Friedrich Beckmann @.***> wrote:
Thanks! The relevant part is:
- i18n.at:43: testing convert invalid UTF-8 to ISO-8859-1 ... ./i18n.at:43: i18n-test supports_encodings 'UTF-8' 'ISO-8859-1' ./i18n.at:43: i18n-test recode 'UTF-8' 'ISO-8859-1' 'xy\300z' --- /dev/null 2023-11-05 17:18:50 +++ /private/tmp/pspp-20231105-1748-6a79xk/pspp-2.0.0-pre3g1799ab/tests/testsuite.dir/at-groups/1327/stderr 2023-11-05 17:18:57 @@ -0,0 +1 @@ +/private/tmp/pspp-20231105-1748-6a79xk/pspp-2.0.0-pre3g1799ab/tests/testsuite.dir/at-groups/1327/test-source: line 40: 98363 Killed: 9 i18n-test recode 'UTF-8' 'ISO-8859-1' 'xy\300z' --- - 2023-11-05 17:18:58 +++ /private/tmp/pspp-20231105-1748-6a79xk/pspp-2.0.0-pre3g1799ab/tests/testsuite.dir/at-groups/1327/stdout 2023-11-05 17:18:58 @@ -1,2 +1 @@ -xy?z
./i18n.at:43: exit code was 137, expected 0
- i18n.at:43: 1327. convert invalid UTF-8 to ISO-8859-1 (i18n.at:43): FAILED (i18n.at:43)
So Apple iconv does not simply have a different error number...
— Reply to this email directly, view it on GitHub https://github.com/fredowski/homebrew-pspp/issues/5#issuecomment-1793800569, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEVYS5BDYXQB4CKL2C66GDYC7FS7AVCNFSM6AAAAAA6ZV73CSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJTHAYDANJWHE . You are receiving this because you commented.Message ID: @.***>
Apple provides an iconv library. That was based on gnu libiconv up to MacOS 13. With MacOS 14 they changed the library such that it behaves differently as we see. Currently pspp also links to the MacOS iconv library:
Fredo:Formula fritz$ otool -L /usr/local/bin/pspp
/usr/local/bin/pspp:
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1858.112.0)
/usr/local/Cellar/pspp/HEAD/lib/pspp/libpspp-2.0.0-pre3g1799ab.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/Cellar/pspp/HEAD/lib/pspp/libpspp-core-2.0.0-pre3g1799ab.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.9.0)
/usr/local/opt/pango/lib/libpangocairo-1.0.0.dylib (compatibility version 5001.0.0, current version 5001.14.0)
/usr/local/opt/pango/lib/libpango-1.0.0.dylib (compatibility version 5001.0.0, current version 5001.14.0)
/usr/local/opt/glib/lib/libgobject-2.0.0.dylib (compatibility version 7801.0.0, current version 7801.1.0)
/usr/local/opt/glib/lib/libglib-2.0.0.dylib (compatibility version 7801.0.0, current version 7801.1.0)
/usr/local/opt/harfbuzz/lib/libharfbuzz.0.dylib (compatibility version 60822.0.0, current version 60822.0.0)
/usr/local/opt/cairo/lib/libcairo.2.dylib (compatibility version 2.0.0, current version 2.0.0)
/usr/local/opt/gsl/lib/libgsl.27.dylib (compatibility version 28.0.0, current version 28.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/local/opt/gsl/lib/libgslcblas.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
/usr/local/opt/gettext/lib/libintl.8.dylib (compatibility version 13.0.0, current version 13.0.0)
Fredo:Formula fritz$
See: /usr/lib/libiconv.2.dylib
above which is provided by Apple. The problem is that gettext/libintl also links to that library.
Fredo:Formula fritz$ otool -L /usr/local/opt/gettext/lib/libintl.8.dylib
/usr/local/opt/gettext/lib/libintl.8.dylib:
/usr/local/opt/gettext/lib/libintl.8.dylib (compatibility version 13.0.0, current version 13.0.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1858.112.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1141.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)
Fredo:Formula fritz$
homebrew provides the gnu libiconv library, but with the following warning:
==> Caveats
libiconv is keg-only, which means it was not symlinked into /usr/local,
because macOS already provides this software and installing another version in
parallel can cause all kinds of trouble.
I guess that is the reason why all brew projects currently rely on the MacOS iconv library. Mixing is not recommended. I would prefer to wait what gettext and brew is doing and just follow that path. Hoping that Apple will fix the problems with their iconv I would suggest to disable the failing test for the moment on MacOS.
Reasonable solution rather than jumping to partial solutions. Should probably file a bug report with Apple.
OK. I put back in the crash and the skipped test.
My code for skipping did not work properly... If you want - I can do that.
My code for skipping did not work properly... If you want - I can do that.
Yes please. Thank you!
Just fixed it. @blp: Could you trigger a new source build?
@davert318 : Are you running on arm64 m1 or m2 hardware? You build log indicates that you are on intel hardware (or Rosetta).
Triggering now. Thanks for including the update command for brew in there so I didn't have to remember it. Mac Mini 8,1 - Intel i7. Wish it was an M1 or M2 but... not yet! I have another machine but it's Mojave so not that useful for this sort of thing.
@davert318 : You need to wait for the source build from Ben...
The source builds arrive here: https://pspp.benpfaff.org/~blp/pspp-master/ and that build has to include the commit 2c9fe24.
The current "latest" source build is commit 1799abc8 from yesterday. brew does not build pspp directly from git but from the source package.
I triggered a build. It should be ready in a few minutes.
On Sun, Nov 5, 2023 at 1:38 PM Friedrich Beckmann @.***> wrote:
@davert318 https://github.com/davert318 : You need to wait for the source build from Ben...
The source builds arrive here: https://pspp.benpfaff.org/~blp/pspp-master/ and that build has to include the commit 2c9fe24 https://git.savannah.gnu.org/cgit/pspp.git/commit/?id=2c9fe2407245037d1fc2203a814687d7525296e2 .
The current "latest" source build is commit 1799abc8 https://git.savannah.gnu.org/cgit/pspp.git/commit/?id=1799abc8539bd1a49c72c5723d1fa89ff4463e3f from yesterday. brew does not build pspp directly from git but from the source package.
— Reply to this email directly, view it on GitHub https://github.com/fredowski/homebrew-pspp/issues/5#issuecomment-1793853328, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEVYSYE22Z3WICIMC4S6QLYDABNJAVCNFSM6AAAAAA6ZV73CSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJTHA2TGMZSHA . You are receiving this because you were mentioned.Message ID: @.***>
Well, what do you know? that fixed it! Excellent work!! Thank you!
Very nice! Could you start psppire on MacOS Somona and do some tests with the gui?
@SamLo2200: Could you try to build on the MacOS Somona arm architecture?
Opens instantly. As with every other version, it doesn't actually show data and syntax files unless I switch to "all files." Recognizes 1.62's recent files. Never used Tables before but it works nicely! Be nice to have the main menubar in the output window ;) but that's a PSPP thing. I'll swear it's faster than the binary I downloaded of 1.62... though it might just be because I've been using SPSS 20 in Windows lately for a class. Scatterplot works well. Syntax works well. Can't find any flaws. Anything you want me to look at in particular?
Spoke too soon. When I quit: proximate cause: Segmentation Violation version: GNU pspp 2.0.0-pre3g2c9fe2 host_system: x86_64-apple-darwin23.1.0 build_system: x86_64-apple-darwin23.1.0 locale_dir: /usr/local/Cellar/pspp/HEAD/share/locale compiler version: Apple LLVM 15.0.0 (clang-1500.0.40.1)
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000028
Exception Codes: 0x0000000000000001, 0x0000000000000028
VM Region Info: 0x28 is not in any region. Bytes before following region: 140737487831000
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
--->
shared memory 7ffffff80000-7ffffff81000 [ 4K] r-x/r-x SM=SHM
@davert318 : Thanks for your tests! I just wanted to see if there is anything obvious not working in the gui. Investigating the reason for the crash at quit needs more work. But I guess we can say that pspp is not completely useless on MacOS Somona. Thanks!
Crashing on quit is I think the least of anyone’s worries! Thanks for doing this for so long. I’ve been using your binaries for years. I must admit that my primary use of PSPP - interpreting my students’ PSPP output - has had to end due to SPSS’ tweaking of its output files so PSPP can’t read them any more (they also stopped issuing their own readers). I’m only adjunct faculty and unlikely to spend the five figures they want for SPSS proper - and PSPP doesn’t do block or stepwise or forward or backward regression… I admit I’ve been tempted by Jamovi and/or JASP. But for my own use, when I personally need to do stats, I love having a fast-loading, fast-responding SPSS clone that I can use syntax with! (Without learning R - given my age, that’s a big ask.)
Very nice! Could you start psppire on MacOS Somona and do some tests with the gui?
@SamLo2200: Could you try to build on the MacOS Somona arm architecture?
Sorry, I haven't check my github recently. I tested out today on my macbook air 2020(m1), compiled successfully, but I still can't edit any variable name.
Thanks for testing! Can you describe what you try to do step by step? When I start pspp gui, then I can enter new variables in the variable view and then edit and change the name.
2.0.0-pre1ge32bec Sonoma, haven't had any issues but I'm Intel not Mx. (Opened, entered new variables, changed names.) Tried rebuilding to latest version but brew said there weren't any updates.
Same as you, but I can't modify any variable name. When I typed something into the cell, and press enter, all text will disappear.
@SamLo2200: Can you open a new issue "MacOS 10.15 Somona on ARM M1/M2 - Variable field is empty after edit"? Then we can close this issue which was about pspp is not installable at all.
Sure
Thanks! Then I close this issue here for the build failure. The gui problem on ARM that the variable is not editable is tracked in issue #6.
FYI, with the release of 2.1 or 2.01, I started an update today. So far so good, I'm up to make with no errors. ... but it's been on Make for a LONG time.
Update: it's fine. I show a new install without errors for PSPP 2.0.0-gee8fab. I guess it'll take a while for 2.01 to show up.
Homebrew install using head (development) for version 2 fails -
Error: fredowski/pspp/pspp HEAD did not build pspp's formula was built from an unstable upstream --HEAD.
The log it points to, doesn't exist - /Users/****/Library/Logs/Homebrew/pspp/config.log
error seems to be here: xgettext --copyright-holder="Free Software Foundation, Inc." --package-name=pspp --package-version=2.0.0-pre2g2a803f --msgid-bugs-address=pspp-dev@gnu.org --from-code=UTF-8 --add-comments='TRANSLATORS:' --directory=. -j doc/org.gnu.pspp.metainfo.xml.in -o po/pspp.pot,tmp xgettext: warning: a fallback ITS rule file '/usr/local/Cellar/gettext/0.22.3/share/gettext-0.22.3/its/metainfo.its' is used; it may not be in sync with the upstream xgettext --copyright-holder="Free Software Foundation, Inc." --package-name=pspp --package-version=2.0.0-pre2g2a803f --msgid-bugs-address=pspp-dev@gnu.org --from-code=UTF-8 --add-comments='TRANSLATORS:' --directory=. -j doc/org.gnu.pspp.desktop.in -o po/pspp.pot,tmp mv po/pspp.pot,tmp po/pspp.pot make[1]: [all-recursive] Error 1 make: [all] Error 2
Wait... occurs to me I need to update/upgrade brew and dependents. Trying again in a moment ;)
... nope, same issue.
xgettext: warning: a fallback ITS rule file '/usr/local/Cellar/gettext/0.22.3/share/gettext-0.22.3/its/gtkbuilder.its' is used; it may not be in sync with the upstream