imap support

[crazywhalecc]

@DubbleClick

but even that requires a lot of patches both in the form of .patch files as well as replacing contents in files that no .patch file is available for. This project doesn't have any logic to apply patch files yet.

I understand. I tried the patch code in my previous implementation of libmemcached, where I originally planned to put the patch code in the src/globals/patch/ directory, like this. But in the end, I directly used homebrew's build logic and independent mirror repo, and did not choose patch because it has not been updated for a long time: https://github.com/crazywhalecc/libmemcached-macos

It also needs multiple services to be running on the system and a (self signed is fine) certificate. It's a complete mess that requires decisions to be taken to integrate it here that I'm not in a position to make.

From the results of my current local testing, it requires at least kerberos, and I'm currently stuck on compiling kerberos.

Under the existing architecture, it may not be a good idea to use pre-installed dynamic libraries or packages on the system, because this will limit the environment in which spc can run.

[DubbleClick]

The link you posted in the parent issue was very helpful to get dynamic compilation going: https://github.com/Homebrew/homebrew-core/blob/e7b36de55df0ffeb3bc8a9f7996906a4dd0cc5b8/Formula/imap-uw.rb

Building all this ourselves, installing the services and then attempting a static build is way worse than getting libc-client compiled.

I could generate patch files to apply all the necessary changes if you want to push the old patch logic you created for libmemcached. Hosting them in this repository would be fine.

[crazywhalecc]

I prefer to use the patched repo directly and create a new GitHub repo for it if the library has not been updated for a long time. But if the patched library is relatively new or is still being continuously updated, this patch logic is necessary. If you need this, we can first complete a method to quickly use the patch files in the project.

[DubbleClick]

Ok, the library hasn't been updated since 2007 so you will probably prefer a repo with all the patches and necessary changes done.

If you would like to create a repository with the original sources (https://mirrorservice.org/sites/ftp.cac.washington.edu/imap/imap-2007f.tar.gz), I will see to create a PR with patches and makefile changes next week.

[DubbleClick]

https://github.com/uw-imap/imap

is a mirror with all necessary patches except one to make it work with openssl 3.

[crazywhalecc]

You could create a project, it doesn't have to be me. Because now the project also uses a lot of mirror repos, not the original ones.

By the way, would it be better to merge these ancient projects into a GitHub repo and then download it to the same source? WDYT?

In addition, for the current libmemcached extension, because I use the mac-only patched repository, this source code cannot be used directly on Linux. I have not solved this problem yet. How are you going to handle this kind of problem on imap?

[DubbleClick]

Sure, I can create the repo. But thinking about it again, if we keep openssl 1.1.1 we can use the github mirror without change.

By the way, would it be better to merge these ancient projects into a GitHub repo and then download it to the same source? WDYT?

You mean libc-client and uw-imap? I don't have any idea how we could potentially handle pop3d/imapd/kerberos yet. As for libc-client we can use the official mirror I believe because it doesn't need patches.

In addition, for the current libmemcached extension, because I use the mac-only patched repository, this source code cannot be used directly on Linux. I have not solved this problem yet. How are you going to handle this kind of problem on imap?

I'm not sure I follow? uw-imap compiles in linux too.

[DubbleClick]

Running into undefined reference sigsetjmp when building this on aarch64 with openssl enabled (works without openssl).

/usr/bin/ld: ../c-client/c-client.a(osdep.o): in function `ssl_onceonlyinit':
/opt/static-php-cli/source/imap/c-client/osdep.c:303: warning: the use of `tmpnam' is dangerous, better use `mkstemp'
/usr/bin/ld: mtest.o: in function `prompt':
/opt/static-php-cli/source/imap/mtest/mtest.c:598: warning: the `gets' function is dangerous and should not be used.
/usr/bin/ld: /opt/static-php-cli/buildroot/lib/libcrypto.a(libcrypto-lib-armcap.o): in function `arm_probe_for':
armcap.c:(.text.startup+0x1c): undefined reference to `sigsetjmp'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:41: mtest] Error 1
make[2]: Leaving directory '/opt/static-php-cli/source/imap/mtest'
make[1]: *** [Makefile:709: bundled] Error 2
make[1]: Leaving directory '/opt/static-php-cli/source/imap'
make: *** [Makefile:311: slx] Error 2

That doesn't even make sense, considering

[root@aarch64 imap]# grep -Rni "sigsetjmp" /usr/local/musl/
grep: /usr/local/musl/lib/libc.a: binary file matches
grep: /usr/local/musl/lib/libc.so: binary file matches
/usr/local/musl/include/setjmp.h:28:int sigsetjmp (sigjmp_buf, int) __setjmp_attr;
/usr/local/musl/aarch64-linux-musl/include/setjmp.h:28:int sigsetjmp (sigjmp_buf, int) __setjmp_attr;
grep: /usr/local/musl/aarch64-linux-musl/lib/libc.a: binary file matches
grep: /usr/local/musl/aarch64-linux-musl/lib/libc.so: binary file matches
grep: /usr/local/musl/aarch64-linux-musl/lib/ld-musl-aarch64.so.1: No such file or directory
grep: /usr/local/musl/libexec/gcc/aarch64-linux-musl/9.4.0/cc1: binary file matches
grep: /usr/local/musl/libexec/gcc/aarch64-linux-musl/9.4.0/cc1plus: binary file matches
grep: /usr/local/musl/libexec/gcc/aarch64-linux-musl/9.4.0/lto1: binary file matches
grep: /usr/local/musl/libexec/gcc/aarch64-linux-musl/9.4.0/install-tools/fixincl: binary file matches```