It seems it is not current possible to statically link LibCurl. I compiled my
own:
~~~
git clone --depth 1 git://github.com/curl/curl
cd curl
mingw32-make -C lib -f Makefile.m32
~~~
but it fails with `std.net.curl`:
~~~
$ cat std_net_curl.d
import std.net.curl;
void main() {
auto s1 = "http://speedtest.lax.hivelocity.net";
s1.get;
}
$ ldc2 std_net_curl.d wldap32.lib libcurl.lib
$ ./std_net_curl
std.net.curl.CurlException@std\net\curl.d(4223): Failed to load curl, tried
"libcurl.dll", "curl.dll".
~~~
and it fails with `etc.c.curl`:
~~~
$ cat etc_c_curl.d
import etc.c.curl;
void main() {
curl_easy_init();
}
$ ldc2 etc_c_curl.d wldap32.lib libcurl.lib
lld-link: error: libcurl.lib(easy.o): invalid symbol index in addrsig section
~~~
looking at the code, it seems the problem is here:
~~~
alias loadSym = GetProcAddress;
~~~
<https://github.com/dlang/phobos/blob/d5dc0115/std/net/curl.d#L4194>
I am not an expert, but I think `GetProcAddress` is for working with DLL, not
static libraries:
<https://docs.microsoft.com/windows/win32/api/libloaderapi/nf-libloaderapi-getprocaddress>
Comment #1 by alphaglosined — 2020-03-21T08:11:34Z
The dynamic loading facilities such as dlsym and GetProcAddress can be used to look for symbols in the host executable image.
As per: https://github.com/dlang/phobos/blob/d5dc0115/std/net/curl.d#L4206
It is configured to do this by default, allowing for static linking into the executable.
My guess is that the symbol its looking for has an underscore prepended to its name which is not uncommon. This would cause the issues that you are seeing.
The simplest way to confirm, is to compile curl without the leading underscore or to i.e. objdump its symbol table.
Comment #2 by pro.mathias.lang — 2020-03-21T11:11:26Z
As Richard mentioned, the first lookup is on the binary itself.
Do you have `libcurl.dll` in the folder your binary is in ?
Comment #3 by doob — 2020-03-21T11:54:59Z
This is required for iOS derived platforms where "dlopen" is not allowed.
Comment #4 by srpen6 — 2020-03-21T14:49:25Z
> My guess is that the symbol its looking for has an underscore prepended to its
> name which is not uncommon. This would cause the issues that you are seeing.
>
> The simplest way to confirm, is to compile curl without the leading underscore
> or to i.e. objdump its symbol table.
That sounds promising, but I dont think thats the problem:
~~~
$ objdump -x libcurl.lib | ag curl_global_init
[17](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 0) 0x00000000 curl_global_init
[32](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 0) 0x000000a0 curl_global_init_mem
0000000000000000 IMAGE_REL_AMD64_ADDR32NB curl_global_init
0000000000000004 IMAGE_REL_AMD64_ADDR32NB curl_global_init
000000000000000c IMAGE_REL_AMD64_ADDR32NB curl_global_init_mem
0000000000000010 IMAGE_REL_AMD64_ADDR32NB curl_global_init_mem
~~~
> As Richard mentioned, the first lookup is on the binary itself. Do you have
> `libcurl.dll` in the folder your binary is in ?
Have you ever built a D program that uses static LibCurl? Because I find it hard
to believe what you are saying. I have built hundreds of static Windows programs
over the years, and the shared libary was never required at runtime or build
time.
Comment #5 by kinke — 2020-03-21T15:43:06Z
(In reply to Richard Cattermole from comment #1)
> The dynamic loading facilities such as dlsym and GetProcAddress can be used
> to look for symbols in the host executable image.
>
> As per: https://github.com/dlang/phobos/blob/d5dc0115/std/net/curl.d#L4206
>
> It is configured to do this by default, allowing for static linking into the
> executable.
In that case, the custom static curl library will almost certainly need to be built with a special config, using `__declspec(dllexport)` for the implementations, so that the executable will export the symbols for GetProcAddress() usage.
Comment #6 by kinke — 2020-03-22T14:52:26Z
(In reply to kinke from comment #5)
> In that case, the custom static curl library will almost certainly need to
> be built with a special config, using `__declspec(dllexport)` for the
> implementations, so that the executable will export the symbols for
> GetProcAddress() usage.
Nope, it's simpler than that - the linker just needs the .exp file (auto-generated when building the DLL, just like the import library) as additional input file when linking the executable (besides the static curl library of course). The executable then features the exports, and std.net.curl works as expected. See https://github.com/ldc-developers/ldc/issues/3376 (incl. a link to a prebuilt package).
Comment #7 by robert.schadek — 2024-12-01T16:36:33Z