Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build fails with ./configure --enable-shared --disable-static on Windows #9803

lazka opened this issue Oct 26, 2022 · 6 comments


Copy link

lazka commented Oct 26, 2022

This issue is a continuation from #9521 (comment)

I did this

# using gcc/clang + mingw-w64
autoreconf -vfi
./configure --enable-shared --disable-static --with-schannel
make -j
libtool: compile:  windres -I../include -DCURL_EMBED_MANIFEST -i curl.rc  -DDLL_EXPORT -DPIC -o .libs/curl.o
  CCLD     curl.exe
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find curl.o: No such file or directory
collect2.exe: error: ld returned 1 exit status

git bisect -> 6de7322

$ git bisect good
6de7322c03d5b4d91576a7d9fc893e03cc9d1057 is the first bad commit
commit 6de7322c03d5b4d91576a7d9fc893e03cc9d1057
Author: Viktor Szakats
Date:   Sun Sep 18 12:05:35 2022 +0000

I expected the following

it to build

curl/libcurl version


operating system

Windows 11

Copy link

lazka commented Oct 26, 2022

replying to #9521 (comment):

@lazka: Thanks! A separate Issue would be helpful indeed. --enable-shared --disable-static is the exact combination where in curl-for-win I explicitly skip building curl.exe (due to fatal ltwrapper issues post-link, and we also happen to not need this binary). This explains why this escaped my local tests. We also miss it from CI tests apparently. I could reproduce it now.

Do you have any suggestion for a fix?

Do you mean for the ltwrapper issue (context?) or the windres issue? Likely for neither though. I could try porting our package recipe to cmake :D

Copy link

@lazka: I keep this build-case disabled due to long time ltwrapper issues, but this is unrelated to this problem.

CMake should work and may also be faster.

For now I'm siding with reverting this patch, and deleting curl-for-win autotools efforts with it.

@vszakats vszakats changed the title Build fails with ./configure --enable-shared --disable-static --with-schannel Build fails with ./configure --enable-shared --disable-static Oct 26, 2022
@vszakats vszakats changed the title Build fails with ./configure --enable-shared --disable-static Build fails with ./configure --enable-shared --disable-static on Windows Oct 26, 2022
Copy link

[ Deleted --with-schannel from title, it's not necessary for it to fail. Also added Windows. ]

Copy link

lazka commented Oct 26, 2022

I've reverted those two commits now downstream, so there is need no hurry.

I don't understand the libtool/autotools/make magic, but as a lead: removing $(LIBTOOL) --tag=RC --mode=compile makes it work. libtool rewrites the target path to ./.libs/curl.o while the following link command expects it at ./curl.o somehow.

Copy link

vszakats commented Oct 26, 2022

Yes, that might work, but as luck has it, building libcurl does seem to require the translation "magic":

2022-10-26T10:13:20.5922663Z libtool: compile:  windres -I../include -i libcurl.rc  -o .libs/libcurl.o

Having to use libtool in lib and bare RC in src, looks... kind of strange. I'll make some tests later.

In the meantime, everyone is welcome for suggestions on what is the autotools-way of solving this.

vszakats added a commit to vszakats/curl that referenced this issue Oct 26, 2022
`./configure --enable-shared --disable-static` fails when trying to link
a shared `curl.exe`, due to `libtool` magically changing the output
filename of `windres` to one that it doesn't find when linking:

/bin/sh ../libtool --tag=RC --mode=compile windres -I../../curl-7.86.0/include -DCURL_EMBED_MANIFEST  -i ../../curl-7.86.0/src/curl.rc -o curl.o
libtool: compile:  windres -I../../curl-7.86.0/include -DCURL_EMBED_MANIFEST -i ../../curl-7.86.0/src/curl.rc  -o .libs/curl.o
CCLD     curl.exe
clang: error: no such file or directory: 'curl.o'

Until we understand the exact mechanics of this, let's work around the
problem by skipping `libtool` and calling `windres` directly. Do this
for `src` (aka `curl.exe`) only, because `lib` does need the `libtool`
magic. The workaround is compatible with building a static `curl.exe`.

This build scenario is not CI-tested.

While here, delete an obsolete comment about a permanent `libtool`
warning that we've resolved earlier.

Regression from 6de7322

Reported-by: Christoph Reiter
Fixes curl#9803
Closes #xxxx
Copy link

Odd as it is, using windres directly in src seems to fix it, while also not breaking static curl.exe builds.

autotools-ways are really mysterious, so I'm not 100% confident this doesn't break some other scenario, but till we have a better idea about this, I suggest going with this one.

PR: #9805

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Successfully merging a pull request may close this issue.

2 participants