On 06/23/17 23:32, Brian Brooks wrote:
> On 06/23 22:50:09, Maxim Uvarov wrote:
>> clang -m32 on x86 failed.
> 
> On 32-bit machines -latomic is needed when compiling with
> Clang. It is not needed with GCC.
> 
> I suspect the atomics checking in
> /platform/linux-generic/m4/configure.ac is always using
> GCC when compiling these mini sources. It needs to be using
> ${CC}. Is that possible?
> 

I think not all cflags went for examples from configure. I remember I
sent something to fix this example build...


>> Joe, do you want to take a look at it?
>>
>> [...truncated 76.24 KB...]
>>      cc:                     clang
>>      cc version:             3.5.0
>>      cppflags:               
>>      am_cppflags:            
>> -I<https://ci.linaro.org/job/odp-tool-check/build_type=clang_and_m32_on_64,label=docker-jessie-amd64/ws/check-odp/installed/x86_64-i386/openssl-OpenSSL_1_0_1h/include>
>> -I<https://ci.linaro.org/job/odp-tool-check/build_type=clang_and_m32_on_64,label=docker-jessie-amd64/ws/check-odp/installed/x86_64-i386/cunit-2.1-3/include>
>>      am_cxxflags:            -std=c++11
>>      cflags:                 -m32
>>      am_cflags:               -pthread  -DIMPLEMENTATION_NAME=odp-linux
>> -DODP_DEBUG_PRINT=0 -DODPH_DEBUG_PRINT=0 -DODP_DEBUG=0 -W -Wall -Werror
>> -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
>> -Wold-style-definition -Wpointer-arith -Wcast-align -Wnested-externs
>> -Wcast-qual -Wformat-nonliteral -Wformat-security -Wundef
>> -Wwrite-strings -std=c99  -mcx16
>>      ldflags:                -m32
>>      am_ldflags:               -pthread -lrt
>> -L<https://ci.linaro.org/job/odp-tool-check/build_type=clang_and_m32_on_64,label=docker-jessie-amd64/ws/check-odp/installed/x86_64-i386/openssl-OpenSSL_1_0_1h/lib>
>> -L<https://ci.linaro.org/job/odp-tool-check/build_type=clang_and_m32_on_64,label=docker-jessie-amd64/ws/check-odp/installed/x86_64-i386/cunit-2.1-3/lib>
>>      libs:                   -lcunit -lcrypto
>>      defs:                   -DHAVE_CONFIG_H
>>      static libraries:       yes
>>      shared libraries:       yes
>>      ABI compatible:         yes
>>      Deprecated APIs:        no
>>      cunit:                  yes
>>      test_vald:              yes
>>      test_perf:              yes
>>      test_perf_proc:         yes
>>      test_cpp:               no
>>      test_helper:            yes
>>      test_example:           yes
>>      user_guides:            no
>>
>>   CC       odp_ipfragreass-odp_ipfragreass.o
>>   CC       odp_ipfragreass-odp_ipfragreass_fragment.o
>>   CC       odp_ipfragreass-odp_ipfragreass_helpers.o
>>   CC       odp_ipfragreass-odp_ipfragreass_reassemble.o
>>   CCLD     odp_ipfragreass
>> odp_ipfragreass-odp_ipfragreass_reassemble.o: In function
>> `atomic_strong_cas_dblptr':
>> odp_ipfragreass_reassemble.c:(.text+0x89f): undefined reference to
>> `__atomic_compare_exchange_8'
>> clang: error: linker command failed with exit code 1 (use -v to see
>> invocation)
>> Makefile:695: recipe for target 'odp_ipfragreass' failed
>>
>> On 06/13/17 17:44, Joe Savage wrote:
>>>>>>> Joe,
>>>>>>>
>>>>>>> can you please make it work with clang? I sent a patch to ml before. It
>>>>>>> might still apply, so you can review it.
>>>>>>> https://travis-ci.org/muvarov/odp/jobs/223572921
>>>>>>>
>>>>>>> the goal is to find good combination of -mcx16 and -latomic flags. And
>>>>>>> we need to test that it still works on arm due to there is no mcx16 
>>>>>>> flag.
>>>>>>>
>>>>>>> Maxim.
>>>>>>
>>>>>> Hey Maxim,
>>>>>>
>>>>>> As we discussed previously, from my end the example should work perfectly
>>>>>> with clang, it is just a matter of passing the right flags to the 
>>>>>> compiler
>>>>>> through the project infrastructure. As such, you should be in a much 
>>>>>> better
>>>>>> position to evaluate this than I. Looking at the descriptions of the 
>>>>>> patches
>>>>>> alone, however, it looks like your patch combined with Brian Brooks'
>>>>>> "configure.ac: fix native Clang build on ARMv8" should resolve any
>>>>>> compilation issues here.
>>>>>>
>>>>>> Joe
>>>>>>
>>>>>
>>>>> Ok, than if you want I can update my patch and send together with yours
>>>>> as patchset.
>>>>>
>>>>> Maxim.
>>>>
>>>> Sure -- if that's how you'd like the patches to be grouped, go for it.
>>>
>>> Any progress on this, Maxim?
>>>
>>

Reply via email to