Hi LLVMDev,
There’s been a good bit of progress this month, and with the dev meeting later this week I thought I’d send out a second update. There are only two outstanding blocking issues that don’t have patches proposed, PR 21568 & PR 23947. I would greatly appreciate if someone who works on Mips would take a look at PR 23947.
The following issues have been marked as fixed since the last update I sent out.
- Bug 14109 - CMake build for compiler-rt should use just-built clang
- Bug 24157 - CMake built shared library does not export all public symbols
These issues are still outstanding. Classification of blocking vs non-blocking are my own opinions, please let me know if you disagree. All non-blocking issues are still serious bugs that need to be fixed.
Blocking Issues:
- Bug 14200 - -fno-rtti not in cxxflags given by llvm-config (Patches out for review http://reviews.llvm.org/D11849)
- Bug 21568 - Cannot add rpath
- Bug 23947 - CMake+Mips: find_library() doesn’t work correctly when recursing 64-bit (both N32 and N64 ABI’s) compiler on Debian Jessie
- Bug 25059 - CMake libllvm.so.$MAJOR.$MINOR shared object name not compatible with ldconfig (Two conflicting approaches are proposed to fix this in http://reviews.llvm.org/D13841 & http://reviews.llvm.org/D14040)
Non-Blocking Issues:
- Bug 19875 - libraries and executables need different rpaths
- Bug 22466 - cmake build should provide way to run tablegen with no arguments
- Bug 23746 - test-suite lacks CMake support (Part 1 landed r251431, Part 2 approved patches http://reviews.llvm.org/D14061)
- Bug 24919 - [autoconf → cmake] libclang.a is not packaged in the Ubuntu x86_64 pre-built
Other issues not tracked by bugs:
- FreeBSD seemed to have problems with CMake identifying itself as amd64 causing x86_64 tests to fail
- Migrating buildbots
- We need to make sure libc++ works properly on Darwin
- Put together a “cheat sheet” document for transitioning
Thank you everyone who has helped out to get us this far. We’re getting awfully close now!
Thanks,
-Chris
This seems interesting. Do you have any more information?
Thanks,
Steve.
Thanks for all of your efforts and for owning this!
Hi LLVMDev,
There’s been a good bit of progress this month, and with the dev meeting
later this week I thought I’d send out a second update. There are only
two outstanding blocking issues that don’t have patches proposed,
PR 21568 & PR 23947. I would greatly appreciate if someone who works on
Mips would take a look at PR 23947.
The following issues have been marked as fixed since the last update I
sent out.
* Bug 14109 - CMake build for compiler-rt should use just-built clang
* Bug 24157 - CMake built shared library does not export all public symbols
These issues are still outstanding. Classification of blocking vs
non-blocking are my own opinions, please let me know if you disagree.
All non-blocking issues are still serious bugs that need to be fixed.
Blocking Issues:
* Bug 21568 - Cannot add rpath
I don't think this ^ one is a blocker. Reid gives a suitable workaround in the bug ticket.
Jon
- FreeBSD seemed to have problems with CMake identifying itself as amd64
causing x86_64 tests to fail
This seems interesting. Do you have any more information?
This came from an old thread: http://lists.llvm.org/pipermail/llvm-dev/2014-October/078363.html
I don’t have any context more than what was there.
-Chris
Ok, thanks. I can't tell if it's an upstream cmake issue or a llvm
downstream issue. I'll assume the latter until any information shows
otherwise :).
Thanks,
Steve.
* FreeBSD seemed to have problems with CMake identifying itself as amd64
causing x86_64 tests to fail
This seems interesting. Do you have any more information?
This came from an old thread:
[LLVMdev] RFC: Timeline for deprecating the autoconf build system?
<http://lists.llvm.org/pipermail/llvm-dev/2014-October/078363.html>
I don’t have any context more than what was there.
Ok, thanks. I can't tell if it's an upstream cmake issue or a llvm
downstream issue. I'll assume the latter until any information shows
otherwise :).
I assume the later as well. I also am treating it as non-blocking because there isn’t a bug report.
-Chris
Hi LLVMDev,
There’s been a good bit of progress this month, and with the dev meeting later this week I thought I’d send out a second update. There are only two outstanding blocking issues that don’t have patches proposed, PR 21568 & PR 23947. I would greatly appreciate if someone who works on Mips would take a look at PR 23947.
The following issues have been marked as fixed since the last update I sent out.
- Bug 14109 - CMake build for compiler-rt should use just-built clang
- Bug 24157 - CMake built shared library does not export all public symbols
These issues are still outstanding. Classification of blocking vs non-blocking are my own opinions, please let me know if you disagree. All non-blocking issues are still serious bugs that need to be fixed.
Blocking Issues:
- Bug 14200 - -fno-rtti not in cxxflags given by llvm-config (Patches out for review http://reviews.llvm.org/D11849)
- Bug 21568 - Cannot add rpath
- Bug 23947 - CMake+Mips: find_library() doesn’t work correctly when recursing 64-bit (both N32 and N64 ABI’s) compiler on Debian Jessie
- Bug 25059 - CMake libllvm.so.$MAJOR.$MINOR shared object name not compatible with ldconfig (Two conflicting approaches are proposed to fix this in http://reviews.llvm.org/D13841 & http://reviews.llvm.org/D14040)
Sorry Chris, I had not seen your proposal. A little more background on why I implemented such a complicated approach.
Debian’s current packaging tacks a “.1” on the end of the SONAME. I think this is necessary, but I’m not a Debian packaging expert; Sylvestre could confirm. Anyway, that .1 doesn’t make sense for everyone (anyone else?), which is why it would be specified in an option.
Hi LLVMDev,
There’s been a good bit of progress this month, and with the dev meeting later this week I thought I’d send out a second update. There are only two outstanding blocking issues that don’t have patches proposed, PR 21568 & PR 23947. I would greatly appreciate if someone who works on Mips would take a look at PR 23947.
The following issues have been marked as fixed since the last update I sent out.
- Bug 14109 - CMake build for compiler-rt should use just-built clang
- Bug 24157 - CMake built shared library does not export all public symbols
These issues are still outstanding. Classification of blocking vs non-blocking are my own opinions, please let me know if you disagree. All non-blocking issues are still serious bugs that need to be fixed.
Blocking Issues:
- Bug 14200 - -fno-rtti not in cxxflags given by llvm-config (Patches out for review http://reviews.llvm.org/D11849)
- Bug 21568 - Cannot add rpath
- Bug 23947 - CMake+Mips: find_library() doesn’t work correctly when recursing 64-bit (both N32 and N64 ABI’s) compiler on Debian Jessie
- Bug 25059 - CMake libllvm.so.$MAJOR.$MINOR shared object name not compatible with ldconfig (Two conflicting approaches are proposed to fix this in http://reviews.llvm.org/D13841 & http://reviews.llvm.org/D14040)
Sorry Chris, I had not seen your proposal. A little more background on why I implemented such a complicated approach.
Debian’s current packaging tacks a “.1” on the end of the SONAME. I think this is necessary, but I’m not a Debian packaging expert; Sylvestre could confirm. Anyway, that .1 doesn’t make sense for everyone (anyone else?), which is why it would be specified in an option.
Your patch and mine do very different things, and I’m not very picky about how this gets handled because I mostly care about Darwin. My patch reworks construction of the output file names so that they match autoconf (libLLVM-3.8.0svn.so as opposed to libLLVM.so.3.8.0svn). Your patches make the versions and library name configurable. Not sure if they both meet the same need.
I’m not really picky about how the problem is solved as long as it is solved.
-Chris