[vlc-devel] [PATCH] contrib: pthreads: Fix building with llvm-mingw

[Martin Storsjö]

On Wed, 21 Feb 2018, Steve Lhomme wrote:

> Le 21/02/2018 à 12:58, Martin Storsjö a écrit :
>> This avoids doing things with dlltool that llvm-dlltool doesn't
>> implement.
>>
>> I don't see the need of running a second pass with dlltool to
>> produce an output def file and yet another pass to produce
>> an import library out of it; just make the linker output the
>> import library while linking the dll. (If the import library is
>> to be used by MSVC, there is a point in generating it with dlltool
>> instead of with ld though. Even then, there's no point in generating
>> the def file using dlltool though, when it could just be generated by
>> the linker.)
>>
>> Remove an inline declaration on a function that can't be inline-only
>> (static inline).
>>
>> For non-static inline functions in C, the compiler can choose to
>> use the inline function itself, or assume that a definition exists
>> in a different translation unit. In this case, clang seems to
>> not inline ptw32_cond_check_need_init and creates an undefined
>> reference to the same function that should be defined in another
>> translation unit (which doesn't exist).
>>
>> See https://www.greenend.org.uk/rjk/tech/inline.html for more details
>> on this.
>> ---
>>   contrib/src/pthreads/implib.patch        | 33 
> ++++++++++++++++++++++++++++++++
>>   contrib/src/pthreads/remove-inline.patch | 12 ++++++++++++
>>   contrib/src/pthreads/rules.mak           |  2 ++
>>   3 files changed, 47 insertions(+)
>>   create mode 100644 contrib/src/pthreads/implib.patch
>>   create mode 100644 contrib/src/pthreads/remove-inline.patch
>>
>> diff --git a/contrib/src/pthreads/implib.patch 
> b/contrib/src/pthreads/implib.patch
>> new file mode 100644
>> index 0000000..01ad44b
>> --- /dev/null
>> +++ b/contrib/src/pthreads/implib.patch
>> @@ -0,0 +1,33 @@
>> +diff -urN pthreads-orig/GNUmakefile pthreads/GNUmakefile
>> +--- pthreads-orig/GNUmakefile	2018-01-05 21:45:34.478551838 +0000
>> ++++ pthreads/GNUmakefile	2018-01-05 21:51:37.918541470 +0000
>> +@@ -523,25 +523,17 @@
>> +
>> +
>> + $(GC_DLL) $(GCD_DLL): $(DLL_OBJS)
>> +-	$(CC) $(OPT) -shared -o $(GC_DLL) $(DLL_OBJS) $(LFLAGS)
>> +-	$(DLLTOOL) -z pthread.def $(DLL_OBJS)
>
> In the original makefile it should be $(PTHREAD_DEF). They're not even 
> consistent
>> +-	$(DLLTOOL) -k --dllname $@ --output-lib $(GC_LIB) --def 
> $(PTHREAD_DEF)
>> ++	$(CC) $(OPT) -shared -o $(GC_DLL) -Wl,--out-implib,$(GC_LIB) 
> $(DLL_OBJS) $(LFLAGS)
>> +
>> + $(GCE_DLL): $(DLL_OBJS)
>> +-	$(CC) $(OPT) -mthreads -shared -o $(GCE_DLL) $(DLL_OBJS) $(LFLAGS)
>> +-	$(DLLTOOL) -z pthread.def $(DLL_OBJS)
>> +-	$(DLLTOOL) -k --dllname $@ --output-lib $(GCE_LIB) --def 
> $(PTHREAD_DEF)
>> ++	$(CC) $(OPT) -mthreads -shared -o $(GCE_DLL) 
> -Wl,--out-implib,$(GCE_LIB) $(DLL_OBJS) $(LFLAGS)
>
> You will end up generating a file like pthreadsGC2.def instead of 
> pthreads.def. In the context of our contribs it doesn't matter. But if 
> you plan on submitting it for backporting it may not be OK.

No, in this case it shouldn't produce any def file at all, unless we 
explicitly also pass -Wl,--output-def. Not that it's of much relevance to 
the patch itself.

Yes, you're right that this patch probably isn't quite finished wrt to 
upstreaming it to the original project.

// Martin