Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Sonoma Homebrew install, unstable v2 #5

Closed
davert318 opened this issue Nov 1, 2023 · 46 comments
Closed

Sonoma Homebrew install, unstable v2 #5

davert318 opened this issue Nov 1, 2023 · 46 comments
Labels
good first issue Good for newcomers

Comments

@davert318
Copy link

davert318 commented Nov 1, 2023 •
edited
Loading

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
@fredowski
Copy link
Owner

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.

@davert318
Copy link
Author

davert318 commented Nov 1, 2023 via email

@fredowski
Copy link
Owner

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.

@davert318
Copy link
Author

davert318 commented Nov 1, 2023 via email

@fredowski
Copy link
Owner

The CI pipeline now works. Could try brew install --head --verbose pspp?

@davert318
Copy link
Author

davert318 commented Nov 2, 2023 via email

@davert318
Copy link
Author

davert318 commented Nov 2, 2023 via email

@davert318
Copy link
Author

davert318 commented Nov 2, 2023 via email

@fredowski
Copy link
Owner

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.

@fredowski
Copy link
Owner

"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)

@SamLo2200
Copy link

Wonderful! Hope this issue will be fixed soon.

@fredowski fredowski mentioned this issue Nov 4, 2023
Merged
@fredowski
Copy link
Owner

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: Homebrew/homebrew-core#142490 (comment) 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.

@blp
Copy link

blp commented Nov 4, 2023

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)

@fredowski
Copy link
Owner

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 ?

@fredowski
Copy link
Owner

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

@davert318
Copy link
Author

davert318 commented Nov 5, 2023 •
edited
Loading

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.

@davert318
Copy link
Author

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

@fredowski
Copy link
Owner

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.

@davert318
Copy link
Author

Attached.
log.txt

@fredowski
Copy link
Owner

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...

@blp
Copy link

blp commented Nov 5, 2023 via email

@fredowski
Copy link
Owner

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.

@davert318
Copy link
Author

Reasonable solution rather than jumping to partial solutions. Should probably file a bug report with Apple.

@blp
Copy link

blp commented Nov 5, 2023

OK. I put back in the crash and the skipped test.

@fredowski
Copy link
Owner

My code for skipping did not work properly... If you want - I can do that.

@blp
Copy link

blp commented Nov 5, 2023

My code for skipping did not work properly... If you want - I can do that.

Yes please. Thank you!

@fredowski
Copy link
Owner

Just fixed it. @blp: Could you trigger a new source build?

@fredowski
Copy link
Owner

@davert318 : Are you running on arm64 m1 or m2 hardware? You build log indicates that you are on intel hardware (or Rosetta).

@davert318
Copy link
Author

davert318 commented Nov 5, 2023 •
edited
Loading

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.

@fredowski
Copy link
Owner

@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.

@blp
Copy link

blp commented Nov 5, 2023 via email

@davert318
Copy link
Author

Well, what do you know? that fixed it! Excellent work!! Thank you!

@fredowski
Copy link
Owner

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?

@davert318
Copy link
Author

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?

@davert318
Copy link
Author

davert318 commented Nov 6, 2023 •
edited
Loading

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

@fredowski
Copy link
Owner

@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!

@davert318
Copy link
Author

davert318 commented Nov 8, 2023 via email

@SamLo2200
Copy link

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.

@fredowski
Copy link
Owner

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.

@davert318
Copy link
Author

davert318 commented Nov 12, 2023 •
edited
Loading

2.0.0-pre1ge32bec Sonoma, haven't had any issues but I'm Intel not M_x_. (Opened, entered new variables, changed names.) Tried rebuilding to latest version but brew said there weren't any updates.

@SamLo2200
Copy link

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.

@fredowski
Copy link
Owner

@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.

@SamLo2200
Copy link

Sure

@fredowski
Copy link
Owner

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.

@fredowski fredowski added the good first issue Good for newcomers label Nov 13, 2023
@oleg-derevenetz oleg-derevenetz mentioned this issue Jan 8, 2024
Closed
2 tasks
@davert318
Copy link
Author

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.

@davert318
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
good first issue Good for newcomers
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@blp @fredowski @davert318 @SamLo2200