Configure: fixed --with-libatomic=DIR with recent libatomic_ops. #460
Conversation
There was a problem hiding this comment.
There is a LINK_DEPS entry without a corresponding target. CORE_DEPS already ensures the build order, so we can drop the library dependency.
With some make implementations (NetBSD 9.x make with compatibility mode off specifically), this results in
make: make: don't know how to make ../lib/libatomic_ops-7.2/build/lib/libatomic_ops.a. Stop
|
Sure, thanks. Caught by FreeBSD's make (which essentially NetBSD's make) in parallel build as well. |
|
Changes:
|
I've once again changed Makefile generation, back to LINK_DEPS. |
|
@bavshin-f5 please review now that I've added win32 support. |
|
First patch looks good. |
The build location of the resulting libatomic_ops.a was changed in v7.4.0 after converting libatomic_ops to use libtool. The fix is to use library from the install path, this allows building with both old and new versions. Initially reported here: https://mailman.nginx.org/pipermail/nginx/2018-April/056054.html
Let's put win32 support aside for now, unless there will be a demand. |
The build location of the resulting libatomic_ops.a was changed in v7.4.0 after converting libatomic_ops to use libtool. The fix is to use headers and library from the install prefix, similar how we do this with OpenSSL. This approach allows building with both old and new library versions.
Initially reported here:
https://mailman.nginx.org/pipermail/nginx/2018-April/056054.html