Hi Chase,
Thanks to your advice about the submodule, I was able to make some progress.
Unfortunately, I am now getting a lot of errors from the headers, e.g.:
./ast_fs.h:147:18: warning: 'struct statvfs64' declared inside parameter list
will not be visible outside of this definition or declaration
147 | #define statvfs statvfs64
| ^~~~~~~~~
./ast_sys.h:14:26: note: in definition of macro '__PROTO__'
14 | # define __PROTO__(x) x
| ^
/usr/include/sys/statvfs.h:48:19: note: in expansion of macro 'statvfs'
48 | #define statvfs64 statvfs
| ^~~~~~~
./ast_fs.h:147:18: warning: 'struct statvfs64' declared inside parameter list
will not be visible outside of this definition or declaration
147 | #define statvfs statvfs64
| ^~~~~~~~~
./ast_sys.h:14:26: note: in definition of macro '__PROTO__'
14 | # define __PROTO__(x) x
| ^
/usr/include/sys/statvfs.h:48:19: note: in expansion of macro 'statvfs'
48 | #define statvfs64 statvfs
| ^~~~~~~
ast_std.h:300:16: error: unknown type name 'off64_t'; did you mean 'off_t'?
300 | #define off_t off64_t
| ^~~~~~~
It appears this fork of ksh93 supports LFS on Linux in a way that's
incompatible with musl, and the pull you linked is for an unrelated issue with
ksh 2020.
I had been hoping to get a Motif 2.1 compatible version of CDE working on
UnixWare, but I believe these changes, using autoconf and an out of tree ksh,
are going to pose significant challenges for the future portability of CDE
because it would be contingent on support by other projects. A similar
transition by X.org resulted in OpenBSD implementing their own makefile build
system with Xenocara, and I have had experience with autoconf releases after
2.13 turning into an effort trying to debug some rather inscrutable m4. Imake,
for all its limitations, generates easy to understand Makefiles, is simple to
configure manually if need be, and only assumes a knowledge of make and the cpp.
What would your advice be for anyone wanting to continue using CDE on platforms
that are unsupported by the autotools or ksh?
Kind regards,
Lev
> On Jan 17, 2021, at 20:13, Chase <nicetry...@protonmail.ch> wrote:
>
> I would not get too ahead of yourself with that, we are planning on making
> the jump to the gnu autotools pretty soon, imake has a multitude of issues
> that, if we want to see significant progress in the fields of OS packaging
> and cross compiling, it will need to be done away with. Upstream might
> appreciate any help with turning nmake into plain makefiles or autotooling it
> however. It also just occured to me why your build was failing, after you
> checkout master-ksh93-upgrade, make sure you do "git submodule update --init
> --recursive" or else git will not pull in the submodule, thats why your
> ./bin/package was missing. If you still have technical problems with it
> afterwards, maybe this commit from att ksh could help
> https://github.com/att/ast/pull/260
>
>
> Thank you for your time,
> -Chase
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Sunday, January 17, 2021 9:02 PM, Lev <int...@mailbox.org> wrote:
>
>> Hi Chase,
>>
>> I am thinking of revamping the bundled dtksh to build directly with imake
>> instead of nmake, using a ksh93 configure script to generate a .cf file with
>> the appropriate defines as a replacement for iffe. If this isn’t the ksh
>> 2020 fork but the new ksh 93u one, backporting the fixes shouldn’t be too
>> difficult because they basically started from scratch to my understanding.
>>
>> Kind regards,
>> Lev
>>
>>> On Jan 17, 2021, at 17:28, Chase via cdesktopenv-devel
>>> cdesktopenv-devel@lists.sourceforge.net wrote:
>>> Lev,
>>> This is a known issue with upstream ksh93:
>>> https://github.com/ksh93/ksh/issues/3, maybe I am being a bit
>>> inconsiderate, but I think that the benefit of us not having to maintain
>>> our own decade old out of tree fork of ksh93 anymore is a worthy trade off
>>> for musl support. Could any of your most recent patches be applied
>>> upstream? I saw that you did edit a few files in the ksh93 tree.
>>> Thank you for your time,
>>> -Chase
>
>
_______________________________________________
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
