Build on MacOS fails due to "error: use of undeclared identifier 'c'"

Question

Build on MacOS fails due to "error: use of undeclared identifier 'c'"

lukvacek opened this issue 2 years ago · 6 comments

Hello! I was able to successfully build and run this package on Ubuntu, but building on Mac OS results in the following error:

cipher-ctr-mt-functions.c:270:26: error: use of undeclared identifier 'c'
                thread_loop_check_exit(c);
                                       ^
cipher-ctr-mt-functions.c:277:27: error: use of undeclared identifier 'c'
                        thread_loop_check_exit(c);
                                               ^

I used the following ./configure command:
./configure --prefix="$(printf "%q\n" "$(pwd)")/dist" LDFLAGS="-L/usr/local/opt/openssl/lib" CPPFLAGS="I/usr/local/opt/openssl/include"

Also tried using gcc 11 installed through:

brew install gcc@11
CC="gcc-11"

Answer 1 · 2022-11-28T17:11:02.000Z

Can you let me know which version of OpenSSL you are using? I'm guessing 3.0 but I want to confirm. Also, did you use brew to install openssl or did you compile it yourself? If you did compile it on your own can you give me the config line for that? Fortunately, I have a mac so I can test this pretty easily. Once I get that information. Thanks!

…

On 11/28/22 2:20 AM, Lukas Vacek wrote: Hello! I was able to successfully build and run this package on Ubuntu, but building on Mac OS results in the following error: |cipher-ctr-mt-functions.c:270:26: error: use of undeclared identifier 'c' thread_loop_check_exit(c); ^ cipher-ctr-mt-functions.c:277:27: error: use of undeclared identifier 'c' thread_loop_check_exit(c); ^ | I used the following ./configure command: |./configure --prefix="$(printf "%q\n" "$(pwd)")/dist" LDFLAGS="-L/usr/local/opt/openssl/lib" CPPFLAGS="I/usr/local/opt/openssl/include"| Also tried using gcc 11 installed through: |brew install ***@***.*** CC="gcc-11" | — Reply to this email directly, view it on GitHub <#40>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKL66CDJZIYOL3UHY5WL4DWKRMLHANCNFSM6AAAAAASNADQCM>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

Answer 2 · 2022-11-28T17:29:58.000Z

Hey, I don't need the extra information. I figured out what is going on. Basically, OS X needs an extra check to see if a thread should exit and that code path isn't used on other OSes. Since we use a preprocessor define to create a dummy function if it's not OS X the normal checks to see if a variable is defined don't come into play. I've got a fix but I want to test it before I push it out to the repo. However, if you want to test it yourself the diff is attached. Keep in mind I haven't tested it yet but if you want to give it a go... diff --git a/cipher-ctr-mt-functions.c b/cipher-ctr-mt-functions.c index 68240b524..45fd4f070 100644 --- a/cipher-ctr-mt-functions.c +++ b/cipher-ctr-mt-functions.c @@ -267,14 +267,14 @@ thread_loop(void *job) pthread_testcancel(); /* Check if we should exit as well */ - thread_loop_check_exit(c); + thread_loop_check_exit(aes_mt_ctx); /* Lock queue and block if its draining */ q = &aes_mt_ctx->q[qidx]; pthread_mutex_lock(&q->lock); pthread_cleanup_push(thread_loop_cleanup, &q->lock); while (q->qstate == KQDRAINING || q->qstate == KQINIT) { - thread_loop_check_exit(c); + thread_loop_check_exit(aes_mt_ctx); pthread_cond_wait(&q->cond, &q->lock); } pthread_cleanup_pop(0);

…

On 11/28/22 2:20 AM, Lukas Vacek wrote: Hello! I was able to successfully build and run this package on Ubuntu, but building on Mac OS results in the following error: |cipher-ctr-mt-functions.c:270:26: error: use of undeclared identifier 'c' thread_loop_check_exit(c); ^ cipher-ctr-mt-functions.c:277:27: error: use of undeclared identifier 'c' thread_loop_check_exit(c); ^ | I used the following ./configure command: |./configure --prefix="$(printf "%q\n" "$(pwd)")/dist" LDFLAGS="-L/usr/local/opt/openssl/lib" CPPFLAGS="I/usr/local/opt/openssl/include"| Also tried using gcc 11 installed through: |brew install ***@***.*** CC="gcc-11" | — Reply to this email directly, view it on GitHub <#40>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKL66CDJZIYOL3UHY5WL4DWKRMLHANCNFSM6AAAAAASNADQCM>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

Answer 3 · 2022-11-28T19:27:08.000Z

The above patch tests out on my system and I've pushed it to the master branch. Once we get another issue resolved I'll update tags/releases with this fix.

Answer 4 · 2022-12-03T01:21:32.000Z

Awesome, thank you! Successfully compiles and runs for me as well.

As an aside (happy to discuss elsewhere), since you have a Mac too I am curious if have you had much success tuning the TCP stack for long fat networks? I have followed pretty much every resource I could find out there and cannot seem to get more than 12 MB/s (peaks to 15MB/s) between a Mac / linux computer pair on a 250-300ms latency connection over the internet. Mac-Mac is even worse. Running a linux-linux TCP connection yields 25-30 MB/s on the same connection. The connection has a limit of around ~36MB/s. I'm guessing it is because we cannot change the Mac's TCP congestion algorithm to something else like BBR / HTCP but wanted to check if this is comparable with your results as well?

Answer 5 · 2022-12-03T21:08:56.000Z

So I have a MBP with a M1Pro chip in it. There are, shall we say, issues with how Apple tunes their TCP stack. First off, a lot of the systems don't have the ability to use jumbo frames (9k packet sizes - it reduces the number packets that need to be processed and decreases the ratio of bytes used for the header in comparison to the payload). On MBPs there also isn't really an option for anything more than a 1Gb/s connection. That said, the Studios have 10Gb ports which, I would hope, have support for jumbo frames.

Anyway, You should take a look at the https://fasterdata.es.net/host-tuning/osx/ tuning guide from ESNet (part of the DoE). There aren't a lot of options to play with but increasing the win_scale and the rcv/snd buffer max will help out a lot. On Ventura those seem to top out at 4MB. For a 300ms connection on, say, a 1Gb path you'll need closer to 34 to 36MB of buffer space on both ends (look up 'bandwidth delay product').

Answer 6 · 2022-12-09T19:16:49.000Z

Thanks! Yes I've already followed that guide and a bunch of others as well (e.g., rolande.wordpress.com, macgeekery, etc). One thing I have noticed is that on a Mac downloads seem to work much better than uploads over a high latency connection. It seems like there is another bottleneck other than buffer sizes as for example testing ~8MB and ~16MB for the buffer sizes yields roughly the same speeds. I'm suspicious it's the fact that Macs can only use the TCP Cubic congestion algorithm which is very sensitive to even small amounts of packet loss compared to say BBR or HTCP.