search

conda-forge / libtiff-feedstock

A conda-smithy repository for libtiff.
BSD 3-Clause "New" or "Revised" License
1 stars 25 forks source link

libtiff.la: why does it define inherited_linker_flags=' -pthread'? #12

Closed croth1 closed 8 years ago

croth1 commented 8 years ago

For some weird reasons the libtiff.la on my mac contains:

# Linker flags that cannot go in dependency_libs.
inherited_linker_flags='  -pthread'

I am not sure how it got there and doubt that it should be there.

I tested with

libtiff - 4.0.6 - 4 - conda-forge

Broader context: I am trying to prepare a libgd package. When linking libtiff, libtool reads this variable and adds it to the linker flags. Clang however does not like -pthread during linking, which gives a warning. Which in turn ends up in an error due to a -Werror flag.

ocefpaf commented 8 years ago

I don't have a Mac to debug this. @jakirkham if you have some spare time can you take a quick look here please?

jakirkham commented 8 years ago

Why are you converting all the warnings to errors with clang? Compared to gcc, clang is very sensitive and many codes at least generate a few warnings with clang. Actually was overrunning log limits on Travis CI just due to warnings when building OpenBLAS for awhile. So I wouldn't really recommend this. Could you explain a bit more why this is necessary?

croth1 commented 8 years ago

Oh, I did not set -Werror. Upstream sets those by default. Patching the build system and removing -Werror sure is a possibility. I just wanted to find out if this is a bug in conda-forge and should be fixed here.

ocefpaf commented 8 years ago

BTW the default channel has the same flag in libtiff.la.

jakirkham commented 8 years ago

Upstream sets those by default.

I see that.

Yeah, sorry, I'm going to point the finger at libgd and would suggest that you raise an issue and point out this constraint is extreme. It seems crazy to turn every warning to an error as part of deployed builds. It may make sense as part of CI to smoke out issues on their end, but to do that with deployment builds makes no sense.

FWIW there seems to be an --enable-werror flag in their configure file. Maybe you could try --disable-werror. If that doesn't work, that seems like the right place for a patch at least.