Wait, that's actually exactly what ${SIZEOF_LONG_CODE} does! So instead of
using #cmakedefine, I think we could just switch everything to
${VARIABLE_CODE} and that would simply support that!
I'm gonna give it a shot!
On Wed, May 22, 2019 at 12:17 PM Jonas Vautherin <jonas.vauthe...@gmail.com>
wrote:
> Thanks a lot for the answer, that was helpful!
>
> It turns out that the toolchain is actually setting multiple OSX
> architectures, and CMake is behaving as per the doc [1], i.e.:
>
> > The variable “${VARIABLE}” may be “0” when CMAKE_OSX_ARCHITECTURES has
> multiple architectures for building OS X universal binaries. This indicates
> that the type size varies across architectures.
>
> So ${SIZEOF_LONG} gets set to "0", and therefore `#cmakedefine
> SIZEOF_LONG ${SIZEOF_LONG}` becomes "/* #undef SIZEOF_LONG */" [3].
>
> One solution for me would be to build curl separately for 32-bits and
> 64-bits, and then merge them using the `lipo` tool. But I am thinking that
> maybe, there could be a way to add support for multiple
> CMAKE_OSX_ARCHITECTURES in curl: when ${SIZEOF_LONG} is "0", CMake also
> defines other values [1], including ${SIZEOF_LONG_CODE}, which gives, e.g.
> for CMAKE_OSX_ARCHITECTURES=armv7;armv7s;arm64:
>
> #if defined(__ARM_ARCH_7A__)
> # define SIZEOF_LONG 4
> #elif defined(__ARM_ARCH_7S__)
> # define SIZEOF_LONG 4
> #elif defined(__aarch64__)
> # define SIZEOF_LONG 8
> #else
> # error SIZEOF_LONG unknown
> #endif
>
> I think that if that could replace `#define SIZEOF_LONG <...>` in the
> resulting `curl_config.h`, then that would be fine.
>
> What do you think? And does somebody see a way to deal with this in
> `curl_config.h.cmake`? I am not sure if it is possible to add some logic
> there =/.
>
> [1]: https://cmake.org/cmake/help/v3.0/module/CheckTypeSize.html
> [2]: https://github.com/curl/curl/blob/master/lib/curl_config.h.cmake#L901
> [3]:
> https://cmake.org/cmake/help/v3.2/command/configure_file.html?highlight=cmakedefine
>
> On Fri, May 17, 2019 at 10:21 AM Daniel Stenberg <dan...@haxx.se> wrote:
>
>> On Fri, 17 May 2019, Jonas Vautherin via curl-library wrote:
>>
>> > I have been trying to cross-compile curl for iOS, using leetal's
>> toolchain
>> > [1] (and another, similar one that has the same issue).
>> >
>> > When building for the "Xcode" cmake generator (cmake -G Xcode <...>),
>> curl
>> > build successfully. But when building for the "Unix Makefiles"
>> generator, I
>> > get an error saying that SIZEOF_LONG is undefined.
>>
>> Seems lame. The curl cmake file has always checked that size since the
>> first
>> day we had one. Although I don't know how good cmake is at doing that for
>> cross-compiles...
>>
>> > I see that SIZEOF_LONG is defined in curl_config.h.cmake [2], but I
>> don't
>> > really get where it comes from.
>>
>> In cmake builds, here:
>>
>>
>> https://github.com/curl/curl/blob/f3e0f071b14fcb46a453f69bdf4e062bcaacf362/CMakeLists.txt#L798
>>
>> (and obviouly similarly by configure, but that's not the topic here)
>>
>> > Should I set it somewhere manually?
>>
>> You should at least set it somewhere. Exactly what the best way is for
>> you to
>> set it, I leave to you.
>>
>> > And if yes, it is always right to say that it should be "8" on 64-bits
>> > archs, and "4" on 32-bits archs (as described here [3])?
>>
>> All 64 bit iOS targets will have it at 8 as far as I know, yes.
>>
>> --
>>
>> / daniel.haxx.se | Get the best commercial curl support there is -
>> from me
>> | Private help, bug fixes, support, ports, new features
>> | https://www.wolfssl.com/contact/
>>
>
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
