search

ucscGenomeBrowser / kent

UCSC Genome Browser source tree. Stable branch: "beta".
http://genome.ucsc.edu/
Other
217 stars 84 forks source link

Fix linking Clang 11 compiled objects #54

Closed mbargull closed 3 years ago

mbargull commented 3 years ago

With Clang 11 htmlRecover from lib/htmshell.h is picked up as a definition, not just declaration of the jmp_buf. As such both lib/htmshell.c and hg/lib/cart.c export two symbols with the same name.

christopherLee1 commented 3 years ago

Hi mbargull, thanks for the suggestion, the code has been fixed as you've suggested. Many thanks!

christopherLee1 commented 3 years ago

Hi mbargull,

Can you share a bit more about how you found this error? Were you using our makefiles? What is your operating system and version? There should theoretically be a ton of these errors that you ran into so it's surprising it is just the htmshell.h one that's causing you a problem.

Also it looks like this is due to a default compiler flag change in clang 11, you can get around this error by compiling with -fcommon.

mbargull commented 3 years ago

Hi @christopherLee1,

I'm a member of the Bioconda project and we package some of your utils as Conda (cross-platform binary package manager) packages. We build for Linux as well as macOS for which we use GCC and Clang, respectively. For Linux we build in CentOS-based containers with CentOS 6 as the compatibility target. For macOS we build on CircleCI and GitHub-provided workers (10.13 SDK but OS X 10.9+ compatibility target). On both build platforms we use "our own" (provided by conda-forge) compilers instead of the system-provided ones.

We are in the process of batch rebuilding packages with new compiler versions, updating from GCC 7 to GCC 9 on Linux and Clang 9 to Clang 11 on macOS. @dpryan79 noticed failing builds for macOS and I could reproduce the linking issue on Linux with Clang 11, too.

Yes, we use your makefiles. And I was likewise surprised that it only reported the htmlshell.h one. I, however, only compiled one program (fastqToFa, arbitrarily chosen), so indeed, it is quite possible there could be more of such errors with Clang 11, depending on which combinations of units one links together.

Also it looks like this is due to a default compiler flag change in clang 11, you can get around this error by compiling with -fcommon.

Thank you, this is valuable information! We did not yet trace down the change from Clang 10 to 11 that caused this (since our Linux, i.e., GCC-based, builds usually have priority), but we did have other (unrelated) builds fail with similar errors, for which you most likely just provided us with possible fixes. Much appreciated! (@dpryan79, see ref.: https://releases.llvm.org/11.0.0/tools/clang/docs/ReleaseNotes.html#modified-compiler-flags .)

Cheers, Marcel