#1314 Build failure cross-compiling for x86_64-w64-mingw32 target

closed-fixed
None
5
2014-08-16
2013-12-23
Luke-Jr
No

OS: Gentoo stable x86 (32-bit)
Target: crossdev x86_64-w64-mingw32 (MingW64)
Versions affected: at least 7.33.0 and 7.34.0

curl_threads.c: In function 'Curl_thread_create':
curl_threads.c:69:5: error: conversion to non-scalar type requested
curl_threads.c:76:5: error: conversion to non-scalar type requested
curl_threads.c: In function 'Curl_thread_destroy':
curl_threads.c:84:3: error: conversion to non-scalar type requested
curl_threads.c: In function 'Curl_thread_join':
curl_threads.c:92:3: error: conversion to non-scalar type requested

Discussion

  • Daniel Stenberg

    Daniel Stenberg - 2013-12-23
    • assigned_to: Daniel Stenberg
     
  • Daniel Stenberg

    Daniel Stenberg - 2013-12-23

    Thanks. Clearly your pthread_t type is not a scalar type. I found this post that might be relevant: http://sourceware.org/ml/pthreads-win32/2011/msg00000.html

    Can you think of a way to define curl_thread_t_null differently so that the code works for you and other pthread implementations?

    Alternatively we change the internal API to not do comparisons with the pthread_t value, which seems to be the proper way to do this.

    Are you able to provide a patch

     
  • Luke-Jr

    Luke-Jr - 2013-12-23

    I don't see any POSIX-compliant way to define a null pthread_t. Perhaps libcurl could use a pthread_t* instead? I could probably provide a patch, but I need to know which approach/solution is acceptable.

     
  • Daniel Stenberg

    Daniel Stenberg - 2013-12-24

    Sure, using a pthread_t could work. The parent function then will need to copy the pointer if it isn't NULL.

     
  • Daniel Stenberg

    Daniel Stenberg - 2013-12-24

    Oh, clever move there. I think it looks good enough and I'm currently running the test suite to verify that it doesn't cause any major surprises. Looks fine!

    Thanks. Do you have another iteration of the patch in mind or should we go with that?

     
  • Luke-Jr

    Luke-Jr - 2013-12-24

    If it works, go ahead and go ahead with that one! I was just expecting some issue since I don't regularly do libcurl code and my last patch got ignored ;)

     
  • Daniel Stenberg

    Daniel Stenberg - 2013-12-24
    • status: open --> closed-fixed
     
  • Daniel Stenberg

    Daniel Stenberg - 2013-12-24

    Thanks a lot for your report and patch! I've merged and pushed your patch as commit e8b57d1e849c8. You'll notice that I moved a brace and updated the commit message.

    Case closed

     
  • Steve Holme

    Steve Holme - 2013-12-24

    I just wanted to give my two pennies worth as I have some Win32 pthread experience and am hoping to bring that to curl at some point in the future.

    Given that the malloc's of t and ac could fail independently (although fairly unlikely) but then be caught by the if after the ac malloc, wouldn't it be better to use Curl_safefree() instead of free?

     
  • Daniel Stenberg

    Daniel Stenberg - 2013-12-24

    Ah you're right, to better work with our own memory debug system and runtests -t etc, Curl_safefree() is better. I'll fix that. Thanks!

     
  • Luke-Jr

    Luke-Jr - 2013-12-25

    free() should be safe with NULL values.

     
    • Daniel Stenberg

      Daniel Stenberg - 2013-12-25

      free(), yes but not our memory debug system as both my comment above and the commit mention

       

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks