Summary of whats blocking perl builds? #4
Comments
|
To what extent can the external libs be built using Aliens? These handle patching and the like and are not dependent on drive paths. It should be possible to sequentially build the respective Aliens as shared installs, collating the folder structures along the way into what will become the And can some of the lowest level dependencies be first copied across from msys2 and renamed? e.g. libtermcap has no non-system dependencies so perhaps it could be renamed with the trailing underscores, and any pkgconfig data updated as needed. One caveat is that not all Aliens support dynamic builds, but this could be a matter of updates to the respective Aliens. |
|
The |
|
Thanks. That's good to hear. |
|
You can check out the repo with the dockerfile and run the commands yourself if you'd like to help debug: https://github.com/StrawberryPerl/spbuild#synopsis |
|
Would it be possible to create issues for each broken thing, so that people can chip away at them? |
|
Check out the latest spbuild repo, create your own fork of the build-extlibs repo and create a build script named Then run through the build process lined out in https://github.com/StrawberryPerl/spbuild#synopsis against that small file. You'll see that readline fails. If you can figure out why that's failing, please let me know. |
|
Then, rinse and repeat for the other failures in my gist above |
|
Looking at the more detailed build logs now I'm running it, the readline error looks to have been reported upstream with a patch: Edit: The patch appears to be in readline 8.2, released 2022-09-26 |
|
Great news. Thank you for looking into that. I'll try to kick off a build this evening with 8.2 instead of 8.1 and then check into the next thing that fails. |
ContainerAdministrator@95fd81efafc8 MINGW64 /z/extlib
# ./build.sh 5034-small __
###### [12:40:00] BUILD STARTED param1='5034-small' param2='__'
...trimmed...
######## retval=success
######## gonna launch: make
test -d shlib || mkdir shlib
( cd shlib ; make all )
... trimmed ...
../rlprivate.h:308:37: error: unknown type name 'fd_set'
308 | extern int _rl_timeout_select (int, fd_set *, fd_set *, fd_set *, const struct timeval *, const sigset_t *);
| ^~~~~~
../rlprivate.h:308:47: error: unknown type name 'fd_set'
308 | extern int _rl_timeout_select (int, fd_set *, fd_set *, fd_set *, const struct timeval *, const sigset_t *);
| ^~~~~~
../rlprivate.h:308:57: error: unknown type name 'fd_set'
308 | extern int _rl_timeout_select (int, fd_set *, fd_set *, fd_set *, const struct timeval *, const sigset_t *);
| ^~~~~~
../rlprivate.h:308:97: error: unknown type name 'sigset_t'
308 | extern int _rl_timeout_select (int, fd_set *, fd_set *, fd_set *, const struct timeval *, const sigset_t *);
| ^~~~~~~~
make[1]: *** [Makefile:116: parens.so] Error 1
make[1]: Leaving directory '/c/spbuild/extlib/_5034-small__.src/readline-8.2/shlib'
make: *** [Makefile:219: shared] Error 2
######## retval=FAILURE
... trimmed ...
ContainerAdministrator@95fd81efafc8 MINGW64 /z/extlib
# grep -E 'retval=' _5034-small__/*.build.log
_5034-small__/readline-8.2.build.log:######## retval=success
_5034-small__/readline-8.2.build.log:######## retval=FAILURE
_5034-small__/readline-8.2.build.log:######## retval=FAILURE
_5034-small__/termcap-1.3.1.build.log:######## retval=success
_5034-small__/termcap-1.3.1.build.log:######## retval=success
_5034-small__/termcap-1.3.1.build.log:######## retval=success
_5034-small__/termcap-1.3.1.build.log:######## retval=success
_5034-small__/termcap-1.3.1.build.log:######## retval=success
_5034-small__/termcap-1.3.1.build.log:######## retval=success
_5034-small__/termcap-1.3.1.build.log:######## retval=success
👎 |
|
I got a response from the readline group and they have a patch for that already: |
|
Other updates: #5 Proj is probably not needed any more I can submit PRs for each of these, or one omnibus PR with one change per distribution. Just let me know. I think that leaves libhdf, libgdbm, libsodium and libssh with fails. libsodium has an existing alien and might not be needed? It is not in the 5.32 distribution but perhaps there are plans for it. (Edited 2022-10-17: s/libgdm/libgdbm/) |
|
A PR per item would be nice! Thank you for all of your help |
|
Not a problem. PRs in #9 (libiconv) and #10 (fontconfig). I've held off on cfitsio and proj. The latest cfitsio does not append the DLLSUFFIX and appears not to be needed anyway. I don't think proj is needed in the Strawberry c dir and the build for version 9 requires an additional dependency (sqlite). |
|
libssl and libssh2 summary is in #14 |
|
Another for my PR list: libhdf5 can be updated to 1.13.2 The build has many fewer warnings. |
|
Much closer: |
|
This is good to see. Proj needs sqlite, which is not currently in the build system. My notes are in #5 I have not tried building libsodium. |
|
libsodium builds successfully with Linking to libssp or adding There is also this news item which suggests the problem will disappear with a more recent mingw: That still leaves the addition of the DLLSUFFIX to the dll name, though. |
|
libsodium builds with gcc-13, and has the DLLSUFFIX. |
|
Srawberry perl 5.36.1 and 5.38.0 have been released. I think this issue can be closed now. |
|
And finally closing |
I have from tpf slack the following irc snippet https://www.irccloud.com/pastebin/Bt8wnGHH/explanation%20of%20current%20problem.txt
Which indicates that reliance on Z: needs to be reworked for builds to continue in Docker?
I am hoping someone can provide a summary of whats blocking strawberry perl builds.
The text was updated successfully, but these errors were encountered: