Test fails building from source on macOS 12.5, M1

[LeeTibbert]

For historical interest:

When I clone from source, build, and run "sbt test" I get two
instances of the error curl_easy_setop: 1, one for 'get' and one for 'put'.

This was several recursion levels deep from the work I was trying to
get done, so I report it only in case the information may help others.

[armanbilge]

Since we do not replicate this error with macOS x86-64 in #5 (comment), it makes me wonder if it is specific to M1.

[armanbilge]

@keynmol reports that the example app is hanging on M1 /shrug

[LeeTibbert]

A data point in the hope that it might help others.

I did a fresh clone of 'main', commit 8dbf686, into a newly created empty directory on
Apple M1 running Monterrey 12.6 with brew curl. I then did a " sbt "++3.1.3 ; shell"

welcome to sbt 1.7.1 (Azul Systems, Inc. Java 17.0.4)

The link succeeded but I got a warning for the Apple X86_64 directory
specified in build.sbt `ld: warning: directory not found for option '-L/usr/local/opt/curl/lib')
So the "specify both both X86_64 & M1 location" approach would not work. Arrgh!
Still, better a succesful link than the missing .dylib we had before.

I ran "test" and got 2 failing tests and one successful (probably the enclosing test).
Failure in both cases was the curl_easy_setop: 1 we have seen before.

I ran "example/run" . It linked and executed, giving one Exception "curl_easy_setop: 1"

So no hang here, for which I am grateful.

If this is working on macOS X86_64, perhaps the short-to-midterm is to say on
the GH ReadMe that M1 is under development, does not work, and is not currently
supported.

[armanbilge]

According to the curl docs

CURLE_UNSUPPORTED_PROTOCOL (1)

The URL you passed to libcurl used a protocol that this libcurl does not support. The support might be a compile-time option that you did not use, it can be a misspelled protocol string or just a protocol libcurl has no code for. 

https://curl.se/libcurl/c/libcurl-errors.html

This suggests to me that the error is happening here:

http4s-curl/curl/src/main/scala/org/http4s/curl/CurlClient.scala

Lines 170 to 176 in 8dbf686

	throwOnError(
	libcurl.curl_easy_setopt_url(
	handle,
	libcurl_const.CURLOPT_URL,
	toCString(req.uri.renderString),
	)
	)

I cannot imagine how that would be going wrong. The "unsupported protocol" suggests to me that somehow the https protocol portion of the URL is being affected: perhaps the url is being truncated, or prefixed by garbage somehow? That could be a bug in toCString.

Or, perhaps your curl is built without SSL support and does not support https? That would seem odd.

[LeeTibbert]

Execution seems to get to here, with httpVersion as 1.1.
Given the https URL, one would expect V2.0.

          throwOnError(
              libcurl.curl_easy_setopt_http_version(
                handle,
                libcurl_const.CURLOPT_HTTP_VERSION,
                httpVersion
              )
            )

To shake the trees, I made sure that I was using the brew curl.
and made curl queries to the postman.com URL, both with
and without --http2. Both came back with HTTP 2 (as one would expect).

I am done with this for the day. I may try adding the "-v" verbose flag to
the link to see which libcurl I am picking up.

Yeah, agreed in spades, I ought to be able to let this go... Sorry for the noise.

[LeeTibbert]

A data point: On my M1 system, both the brew (executed directly from the brew bin) and the /usr/bin variants
of curl-config --libs return simply -lcurl.

So if the build.sbt ever gets more cycles, there needs to be an architecture check (drat) and only
add the -LappleIntel/path on Intel. Not a crying need. I will let it sit on my back brain for when
I am standing in line at the local grocery store.

M1 is snappy but the more time I try to do development on it, the less I like it.