3.5.0 can't compile on my iMac
#1
Lightbulb 
Hello,

Unfortunately, the last version 3.5.0 doesn't compile on my iMac 27 under macOS High Sierra.

I get the following error message:

Code: (Select All)
c++  -w -std=gnu++11 -I./internal/c/libqb/include -I./internal/c/parts/core/src/ -I./internal/c/parts/core/glew/include/ -DDEPENDENCY_SOCKETS -DDEPENDENCY_NO_PRINTER -DDEPENDENCY_ICON -DDEPENDENCY_NO_SCREENIMAGE -DDEPENDENCY_LOADFONT  internal/c/libqb/src/http.cpp -c -o internal/c/libqb/src/http.o
Code: (Select All)
internal/c/libqb/src/http.cpp:98:51: error: use of undeclared identifier 'CURLINFO_CONTENT_LENGTH_DOWNLOAD_T'; did you mean
Code: (Select All)
      'CURLINFO_CONTENT_LENGTH_DOWNLOAD'?
Code: (Select All)
    CURLcode res = curl_easy_getinfo(handle->con, CURLINFO_CONTENT_LENGTH_DOWNLOAD_T, &cl);
Code: (Select All)
                                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Code: (Select All)
                                                  CURLINFO_CONTENT_LENGTH_DOWNLOAD
Code: (Select All)
/usr/include/curl/curl.h:2546:69: note: expanded from macro 'curl_easy_getinfo'
Code: (Select All)
#define curl_easy_getinfo(handle,info,arg) curl_easy_getinfo(handle,info,arg)
Code: (Select All)
                                                                    ^
Code: (Select All)
/usr/include/curl/curl.h:2274:3: note: 'CURLINFO_CONTENT_LENGTH_DOWNLOAD' declared here
Code: (Select All)
  CURLINFO_CONTENT_LENGTH_DOWNLOAD   = CURLINFO_DOUBLE + 15,
Code: (Select All)
  ^
Code: (Select All)
1 error generated.
Code: (Select All)
make: *** [internal/c/libqb/src/http.o] Error 1
Code: (Select All)
make: *** Waiting for unfinished jobs....
Code: (Select All)
Compilation of QB64-PE failed!
logout
Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.

[Opération terminée]


And before you ask, yes curl is installed on my system as shown bellow:

Code: (Select All)
LLast login: Tue Jan 10 02:37:43 on ttys001
Code: (Select All)
i-Mac-27:~ Philippe$ curl -V
Code: (Select All)
curl 7.87.0 (x86_64-apple-darwin17.7.0) libcurl/7.87.0 (SecureTransport) OpenSSL/1.1.1s zlib/1.2.11 brotli/1.0.9 zstd/1.5.2 libidn2/2.3.4 libssh2/1.10.0 nghttp2/1.51.0 librtmp/2.3
Code: (Select All)
Release-Date: 2022-12-21
Code: (Select All)
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Code: (Select All)
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd
Code: (Select All)
i-Mac-27:~ Philippe$


Any idea what is wrong? Sad

TIA for your help. Wink
Cheers.
Fifi

Note: I didn't modify nor remove any file of the complete QB64PE 4.5.1 project.
Before to send the arrow of truth, dip the head in a honey pot (Cheyenne saying).
Don't tell my Mom I'm on iMac with macOS, she thinks I work on PC with Windows. Tongue
Reply
#2
Your libcurl version is probably too old to have 
CURLINFO_CONTENT_LENGTH_DOWNLOAD_T
unfortunately. We can add a workaround for it, but you'll need to wait for the next patch release (likely next weekend). Basically we'll have to swap out
CURLINFO_CONTENT_LENGTH_DOWNLOAD_T
for
CURLINFO_CONTENT_LENGTH_DOWNLOAD
(without the
T
), but that passes back a different datatype so the fix gets a bit more complicated. It would probably compile though if you just swapped them yourself (and
LOF
would be broken) Big Grin

Note that the versions printed from
curl -v
aren't actually related to the libcurl version, it's a bit silly. The required libcurl version for that functionality is 7.55.0, which came out in 2017, right around the time High Sierra came out. I guess Apple never shipped an updated version of libcurl for you so you're stuck on a version slightly older than that.

I guess as a heads up to you, the lowest version of MacOS that we actively test is MacOS Catalina from 2019, since the GitHub runners we use do not support any XCode versions lower than that. And being that High Sierra has been unsupported by Apple for over two years now I don't really see that changing, if anything we're likely to lose the ability to test with Catalina and have to move to testing with Monterey's XCode sometime this year. That's not to say QB64-PE does not support High Sierra, but it does mean we're less likely to notice issues that only impact High Sierra and not newer MacOS versions.
Reply
#3
(01-10-2023, 02:27 AM)DSMan195276 Wrote: Your libcurl version is probably too old to have 
CURLINFO_CONTENT_LENGTH_DOWNLOAD_T
unfortunately. We can add a workaround for it, but you'll need to wait for the next patch release (likely next weekend). Basically we'll have to swap out
CURLINFO_CONTENT_LENGTH_DOWNLOAD_T
for
CURLINFO_CONTENT_LENGTH_DOWNLOAD
(without the
T
), but that passes back a different datatype so the fix gets a bit more complicated. It would probably compile though if you just swapped them yourself (and
LOF
would be broken) Big Grin

Hi DSMan195276

Thank you for your detailed post.
Just to make other tests not related to libcurl and while waiting for a fix, can you tell me where in the code I can do this swap?

(01-10-2023, 02:27 AM)DSMan195276 Wrote: Note that the versions printed from
curl -v
aren't actually related to the libcurl version, it's a bit silly. The required libcurl version for that functionality is 7.55.0, which came out in 2017, right around the time High Sierra came out. I guess Apple never shipped an updated version of libcurl for you so you're stuck on a version slightly older than that.

Prior to perform the qb64pe 3.5.0 install and following the instruction, I made a complete install of curl using brew (that took almost 2 hours on my iMac27 i7 with HighSierra installed on a very fast 2 Tb SSD Crucial). So, it seems totally silly that the libcurl version could be different than the complete curl package installation that is the latest 7.87.0 on my iMac 27 i7 with High Sierra. However, do you know a method to display the libcurl version because the command "curl -V" shows also libcurl/7.87.0 (SecureTransport) as you can see below :

Code: (Select All)
curl Last login: Tue Jan 10 13:59:02 on ttys000
i-Mac-27:~ Philippe$ curl -V
curl 7.87.0 (x86_64-apple-darwin17.7.0) libcurl/7.87.0 (SecureTransport) OpenSSL/1.1.1s zlib/1.2.11 brotli/1.0.9 zstd/1.5.2 libidn2/2.3.4 libssh2/1.10.0 nghttp2/1.51.0 librtmp/2.3
Release-Date: 2022-12-21
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd
i-Mac-27:~ Philippe$

So since I obviously have the last version of both curl and libcurl, the only problem I can see is that there is still an old release of libcurl on my system and that the simlink is wrong and points on that old release. So, do you know the command to simlink to the right libcurl? Or should I proceed to a complete curl uninstall then reinstall it?

(01-10-2023, 02:27 AM)DSMan195276 Wrote: I guess as a heads up to you, the lowest version of MacOS that we actively test is MacOS Catalina from 2019, since the GitHub runners we use do not support any XCode versions lower than that. And being that High Sierra has been unsupported by Apple for over two years now I don't really see that changing, if anything we're likely to lose the ability to test with Catalina and have to move to testing with Monterey's XCode sometime this year. That's not to say QB64-PE does not support High Sierra, but it does mean we're less likely to notice issues that only impact High Sierra and not newer MacOS versions.

Fortunately, I've a second iMac27 i5 "late 2012" that supports macOS 10.15.7 (Catalina). So, I'll install that OS release ASAP and will tell you the result. However for the future, I know that my Apple dealer can do an upgrade to Monterey of both my current development iMac 27 i7 "mid 2011" (that is not supposed to receive a later version of macOS than High Sierra) and my iMac 27 i5 "late 2012" (that is not supposed to receive a later version of macOS than Catalina) but these changes will cost me around 300 Euros each for nothing but being able to run qb64pe. So I'd really prefer a fix since, BTW, I'm very happy with High Sierra and have no real need to change. Meanwhile, in any case I'll upgrade my second iMac 27 i5 to Catalina.

Further, I guess a qb64pe fixed release would work on any newer OS release, am I wrong?

Last point: with your next macOS development environment, you said you'll use Xcode. But have you been already able to interface the QB64pe language with Xcode on your Catalina system, and if so, how do you do it? I'll be very interested to do it even on my next Catalina machine Vs using CodeBlocks.

Please, let me know about the swap at your earliest convenience and TIA for your concern and help.

Cheers.
Fifi
Before to send the arrow of truth, dip the head in a honey pot (Cheyenne saying).
Don't tell my Mom I'm on iMac with macOS, she thinks I work on PC with Windows. Tongue
Reply
#4
(01-10-2023, 11:24 PM)Fifi Wrote: Prior to perform the qb64pe 3.5.0 install and following the instruction, I made a complete install of curl using brew (that took almost 2 hours on my iMac27 i7 with HighSierra installed on a very fast 2 Tb SSD Crucial). So, it seems totally silly that the libcurl version could be different than the complete curl package installation that is the latest 7.87.0 on my iMac 27 i7 with High Sierra.

I agree it's silly, but it is the truth Big Grin The versions aren't related because the
libcurl
version printed from
curl -v
is the version of
libcurl
compiled directly into
curl
itself. The libcurl copy we're using is the one that exists probably in /usr/lib, and
curl
doesn't make use of it. It's also unlikely that installing an updated
curl
using brew would also update libcurl. I don't know a good way to check the libcurl version you have installed.



(01-10-2023, 11:24 PM)Fifi Wrote: Fortunately, I've a second iMac27 i5 "late 2012" that supports macOS 10.15.7 (Catalina). So, I'll install that OS release ASAP and will tell you the result. However for the future, I know that my Apple dealer can do an upgrade to Monterey of both my current development iMac 27 i7 "mid 2011" (that is not supposed to receive a later version of macOS than High Sierra) and my iMac 27 i5 "late 2012" (that is not supposed to receive a later version of macOS than Catalina) but these changes will cost me around 300 Euros each for nothing but being able to run qb64pe. So I'd really prefer a fix since, BTW, I'm very happy with High Sierra and have no real need to change. Meanwhile, in any case I'll upgrade my second iMac 27 i5 to Catalina.

Further, I guess a qb64pe fixed release would work on any newer OS release, am I wrong?

Last point: with your next macOS development environment, you said you'll use Xcode. But have you been already able to interface the QB64pe language with Xcode on your Catalina system, and if so, how do you do it? I'll be very interested to do it even on my next Catalina machine Vs using CodeBlocks.


Yes, to clarify, when we make a new QB64-PE release that includes a fix for this, it will also work on any MacOS versions newer than High Sierra as well (and Windows and Linux).

Also I'm not sure I know enough to answer your last question Undecided In terms of XCode I just mean the SDK that comes along with it. We can change the version of XCode installed on the system so that even though we're on a newer macOS version, the code is compiled against the SDK for an older one (and thus we can test that we compiled correctly for those older systems).
Reply




Users browsing this thread: 4 Guest(s)