Bug#1077446: cmake: FTBFS: dh_auto_test: error: cd Build && make -j8 test ARGS\+=--verbose ARGS\+=-j8 -j1 "ARGS=-E CTestTestUpload\\|curl --timeout 5000 -j8" returned exit code 2
On Mon, Jul 29, 2024 at 1:57 AM Lucas Nussbaum wrote: > Source: cmake > Version: 3.30.1-1 ... > 492/721 Test #501: RunCMake.file-DOWNLOAD > ..***Failed ... > stdout does not match that expected. This is due to a change in curl's output introduced in curl 8.9. CMake 3.30.2 will update the test with the following MR: * https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9690 -Brad
Bug#1050506: [Pkg-cmake-team] Bug#1050506: Could NOT find EXPAT (missing: EXPAT_LIBRARY) (found version "2.5.0")
On Fri, Aug 25, 2023 at 10:15 AM Mathieu Malaterre wrote: > > Also, why do you think this is a CMake issue and not a VTK issue? > > As explained in my original report, this is a change of behavior in > current cmake 3.27. The problem is that VTK has its own copy of FindEXPAT that steps on private implementation details of CMake's FindEXPAT. In CMake 3.27, some of those implementation details changed: * https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8225 VTK's copy needs to be updated to account for them. -Brad
Bug#1041633: cmake: FindPython.cmake returns /usr/local/lib/python3.11/dist-packages for Python_SITEARCH
On Fri, Jul 21, 2023 at 2:37 PM Brad King wrote: > The behavior change came from this CMake merge request: > * https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8538 > because the distutils variant is deprecated. This is now under discussion in an upstream CMake issue: * https://gitlab.kitware.com/cmake/cmake/-/issues/25113 Thanks, -Brad
Bug#1041633: cmake: FindPython.cmake returns /usr/local/lib/python3.11/dist-packages for Python_SITEARCH
On Fri, Jul 21, 2023 at 11:21 AM Sebastiaan Couwenberg wrote: > On bookworm distutils is still used which returns: ... > On sid sysconfig is used which results: The behavior change came from this CMake merge request: * https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8538 because the distutils variant is deprecated. > To get the right path for the Debian python3 interpreter, > you need to add 'deb_system': With distutils a generic `plat_specific=True` option was enough to get each platform's preferred behavior. Does every client of Python's sysconfig need to have a big dispatch block that looks up the host platform and memorizes platform-specific arguments? A similar concern was raised here: * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998739#22 but never resolved. As a side note, adding `DEB_PYTHON_INSTALL_LAYOUT=deb` to the environment resolves this locally. -Brad
Bug#968672: libstdc++-10-dev patch for CUDA and __float128 needs update
Package: libstdc++-10-dev Version: 10.2.0-5 This patch: https://salsa.debian.org/toolchain-team/gcc/-/blob/10.2.0-5/debian/patches/cuda-float128.diff needs to be updated for new occurrences of `__float128` in `numbers` and `bits/stl_algobase.h`: ``` $ grep -r _GLIBCXX_USE_FLOAT128 /usr/include/c++/10 /usr/include/c++/10/numbers:#if !defined(__STRICT_ANSI__) && defined(_GLIBCXX_USE_FLOAT128) /usr/include/c++/10/type_traits:#if !defined(__STRICT_ANSI__) && defined(_GLIBCXX_USE_FLOAT128) && !defined(__CUDACC__) /usr/include/c++/10/bits/std_abs.h:#if !defined(__STRICT_ANSI__) && defined(_GLIBCXX_USE_FLOAT128) && !defined(__CUDACC__) /usr/include/c++/10/bits/stl_algobase.h:#if !defined(__STRICT_ANSI__) && defined(_GLIBCXX_USE_FLOAT128) ``` Those two unpatched occurrences are new to gcc 10 and did not exist in version 9: ``` $ grep -r _GLIBCXX_USE_FLOAT128 /usr/include/c++/9 /usr/include/c++/9/type_traits:#if !defined(__STRICT_ANSI__) && defined(_GLIBCXX_USE_FLOAT128) && !defined(__CUDACC__) /usr/include/c++/9/bits/std_abs.h:#if !defined(__STRICT_ANSI__) && defined(_GLIBCXX_USE_FLOAT128) && !defined(__CUDACC__) ``` Thanks, -Brad
Bug#959064: ignition-transport FTBFS in testing.
On 4/29/2020 10:40 PM, peter green wrote: The behavior of pkg-config has changed This lets though a -isystem parameter with a space which was previously suppressed And the space in said parameter breaks cmake. I think cmake should handle -isystem¹ and as this is reproducible without ignition-transport, I'm reassigning this to cmake. This certainly seems like the long term solution. This has been reported to CMake upstream: * PkgConfig chokes with `-isystem` with pkg-config 0.29.2 https://gitlab.kitware.com/cmake/cmake/-/issues/20652 -Brad
Bug#915148: [Pkg-cmake-team] Bug#915148: cmake: regression in ros-ros-comm build
On 12/7/18 7:44 AM, Jochen Sprickerhof wrote: >> Both are valid ways to link to the pthread library, which is all >> the `-pthread` flag does when used to drive linking. > > I don't agree. Quoting from my mail: > > "Define additional macros required" Macros are for compiling. It is not used during linking. Either way, `-lfoo` can appear for other libraries and ros-catkin needs the fix. -Brad
Bug#915148: [Pkg-cmake-team] Bug#915148: cmake: regression in ros-ros-comm build
On 12/6/18 4:16 PM, Jochen Sprickerhof wrote: > after reading up on this, I think this needs fixing in cmake. > > So neither adding -lpthread, > nor adding /usr/lib/x86_64-linux-gnu/libpthread.so > seems correct to me. Both are valid ways to link to the pthread library, which is all the `-pthread` flag does when used to drive linking. > I will revert the workaround in ros-catkin if you agree. The patch here: http://launchpadlibrarian.net/399812910/ros-catkin_0.7.14-7_0.7.14-7ubuntu1.diff.gz is not a workaround. The input to that logic could contain -lfoo generated by other means for other libraries. This case just happened to expose the existing bug in that logic. Actually looking at the applied fix https://sources.debian.org/src/ros-catkin/0.7.14-8/cmake/templates/pkgConfig.cmake.in/#L118 that logic may need additional work to handle plain `-pthread` or other link flags. > [FindThreads] promotes CMAKE_THREAD_PREFER_PTHREAD to get -pthread It's THREADS_PREFER_PTHREAD_FLAG for that. CMake's FindBoost and FindThreads could use some work to use `-pthread` more completely (perhaps with a policy to use it by default on appropriate compilers), and there is an issue related to this here: https://gitlab.kitware.com/cmake/cmake/issues/18638 However, that does not mean the above change should be reverted. -Brad
Bug#912443: cmake: Generates wrong link flags on hurd-i386
On Wed, 31 Oct 2018 19:05:55 +0300 Dmitry Shachnev wrote: > Such a flag is a problem when the referenced .so file is actually a symlink. > GCC does not resolve it and generates a dependency literally on libsndio.so. Linking a library by absolute path is okay (and preferred) if the library has a proper SONAME. What is the output of $ readelf -d /usr/lib/i386-gnu/libsndio.so | grep SONAME ? On x86_64 libsndio.so has a proper soname: 0x000e (SONAME) Library soname: [libsndio.so.7.0] -Brad
Bug#911088: cmake: Recognize /usr/include/x86_64-linux-gnu like /usr/include
On 10/15/2018 10:42 AM, Marc Glisse wrote: > It seems that cmake has special code to avoid adding -I/usr/include, > it would be good to extend it to the multiarch directory. I've opened an upstream issue here: * https://gitlab.kitware.com/cmake/cmake/issues/18455 It links to some related issues proposing a more general solution. -Brad
Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure
On 04/24/2016 11:59 AM, Andreas Beckmann wrote:
> On Thu, 7 Apr 2016 14:54:20 +0100 Steven Chamberlain wrote:
>> If I change all files except CustomCMakeInput.txt to have identical
>> timestamps, then I can reproduce the bug as seen on the buildds:
[snip]
>> And finally, it seems I can avoid that happening by making just the
>> Makefile have a newer timestamp than the others. The bug is no longer
>> reproducible then:
[snip]
> You may have to consider make's behavior w.r.t. files of the identical
> time stamp:
[snip]
> A target is considered up-to-date if it's timestamp is newer *or same*
> as its prerequisites. Even if a prerequisite was just created.
> (#820658, this is documented make behavior)
>
> And if I understand this correctly, cmake is doing the opposite:
That is *only* in the if(IS_NEWER_THAN) check which does not come into
play in the RunCMake.Configure test AFAIK. The way CMake decides whether
it needs to re-configure is the following:
* The "make" tool sees the cmake_check_build_system target in the Makefile
as always out of date and always runs CMake to do the check. See
the `cmake::CheckBuildSystem` method for the implementation.
* CMake reads CMakeFiles/Makefile.cmake and collects the timestamps
of all the files listed as CMAKE_MAKEFILE_{DEPENDS,OUTPUTS}.
* CMake finds the newest entry in DEPENDS and the oldest entry in OUTPUTS.
* If the newest dependency is newer than (but not equal to) the oldest
output then it decides to re-run. This is the same as the "make"
behavior for identical timestamps.
If you place `VERBOSE=1` in your environment then CMake will print out
what pair of files caused it to decide to re-run.
Steven, in your earlier test that I quoted above, did you ensure that
the timestamps of all files listed as described above (which includes
some under CMakeFiles/) had the same timestamp? If not then I don't
think the test was set up the way you intended.
-
FWIW I would not consider this test failure to be a blocking issue for
packaging a new CMake on this platform. The behavior of this logic is
the same as it has been for years in CMake. It is just that this test
case did not exist before.
-Brad
Bug#819072: closed by Sylvestre Ledru
On 07/02/2016 03:54 PM, Debian Bug Tracking System wrote: > It has been closed by Sylvestre Ledru . I can confirm 3.8.1-3 works now. Thanks! However, it looks like 3.9 needs additional work due to more upstream changes. The changes needed to support it will likely be incompatible with the 3.8 packages so you may need a new svn branch in the packaging repo for 3.9. I'll follow up in https://llvm.org/bugs/show_bug.cgi?id=28325 with more details. -Brad
Bug#819072: closed by Sylvestre Ledru (Bug#819072: fixed in llvm-toolchain-3.8 1:3.8.1-1)
On 06/27/2016 02:49 PM, Sylvestre Ledru wrote: >> I'm not familiar enough with debian packaging infrastructure to know >> how to create this symlink and get it included in the llvm-3.8-dev >> package, but it should be pretty simple for those that know. >> >> Meanwhile the attached patch removes an unnecessary `sed` operation >> that no longer matches anything or has any effect. >> > OK, many thanks. > > looks like the same as https://llvm.org/bugs/show_bug.cgi?id=28325 ? Yes. Both the 3.8 and 3.9 packages need all the fixes discussed here. Thanks, -Brad
Bug#819072: closed by Sylvestre Ledru (Bug#819072: fixed in llvm-toolchain-3.8 1:3.8.1-1)
On 06/23/2016 09:36 AM, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the llvm-3.8-dev package:
>
> #819072: llvm-3.8-dev: LLVM CMake files broken by Debian packaging
>
> It has been closed by Sylvestre Ledru .
There is one remaining problem as of 3.8.1-1.
In r1918 this change was made:
# Explicit debian/tmp since there are multiple declarations
-debian/tmp/usr/lib/llvm-@LLVM_VERSION@/share/llvm/cmake/*.cmake
usr/share/llvm-@LLVM_VERSION@/cmake/
+debian/tmp/usr/lib/llvm-@LLVM_VERSION@/share/llvm/cmake/*.cmake
This is correct. However, my suggestion to do that also stated
that we need to add a symlink:
/usr/share/llvm-@LLVM_VERSION@/cmake ->
/usr/lib/llvm-@LLVM_VERSION@/share/llvm/cmake
This symlink is missing and so CMake projects cannot find the package
in default search locations.
I'm not familiar enough with debian packaging infrastructure to know
how to create this symlink and get it included in the llvm-3.8-dev
package, but it should be pretty simple for those that know.
Meanwhile the attached patch removes an unnecessary `sed` operation
that no longer matches anything or has any effect.
Thanks,
-Brad
Index: debian/rules
===
--- debian/rules (revision 1983)
+++ debian/rules (working copy)
@@ -409,9 +409,6 @@
rm -f $(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/include/llvm/Support/LICENSE.TXT \
$(CURDIR)/debian/llvm-$(LLVM_VERSION)-dev/usr/lib/llvm-$(LLVM_VERSION)/build/autoconf/LICENSE.TXT
-# Change CMake module dir
- sed -i 's|LLVM_CMAKE_DIR "/usr/lib/llvm-$(LLVM_VERSION)/share/llvm/cmake"|LLVM_CMAKE_DIR "/usr/share/llvm-$(LLVM_VERSION)/cmake"|' $(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/share/llvm/cmake/LLVMConfig.cmake
-
# Disable CMake's package validation checks for target files that we may remove.
sed -i '/_IMPORT_CHECK_TARGETS \(Polly\|sancov\)/ {s|^|#|}' $(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/share/llvm/cmake/LLVMExports-*.cmake
Bug#819072: fixed in llvm-toolchain-3.8 1:3.8.1~+rc1-1~exp1
On 06/09/2016 10:14 AM, Brad King wrote:
> Here is an untested patch that uses the approach I suggested.
I just noticed Antoine's report also mentions "sancov". It looks like
that is built but not deployed in the same package as the CMake files
in question. Here is a revised patch that removes the check for that
too.
-Brad
Index: debian/rules
===
--- debian/rules (revision 1945)
+++ debian/rules (working copy)
@@ -411,6 +411,9 @@
# Change CMake module dir
sed -i 's|LLVM_CMAKE_DIR "/usr/lib/llvm-$(LLVM_VERSION)/share/llvm/cmake"|LLVM_CMAKE_DIR "/usr/share/llvm-$(LLVM_VERSION)/cmake"|' $(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/share/llvm/cmake/LLVMConfig.cmake
+# Disable CMake's package validation checks for target files that we may remove.
+ sed -i '/_IMPORT_CHECK_TARGETS \(Polly\|sancov\)/ {s|^|#|}' $(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/share/llvm/cmake/LLVMExports-*.cmake
+
# Managed in python-lldb-X.Y.links.in
rm -f $(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/python*/site-packages/lldb/_lldb.so
Bug#819072: fixed in llvm-toolchain-3.8 1:3.8.1~+rc1-1~exp1
Hi Sylvestre,
Thanks for taking care of this issue.
On 06/09/2016 09:53 AM, Sylvestre Ledru wrote:
> Le 09/06/2016 à 15:15, antoine.pierlot-gar...@scle.fr a écrit :
>> (Similar to section 3 of Brad King's message #20 at
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819072#20 )
>
> A patch would be appreciated, I don't have time to investigate this :/
Here is an untested patch that uses the approach I suggested.
Thanks,
-Brad
Index: debian/rules
===
--- debian/rules (revision 1945)
+++ debian/rules (working copy)
@@ -411,6 +411,9 @@
# Change CMake module dir
sed -i 's|LLVM_CMAKE_DIR "/usr/lib/llvm-$(LLVM_VERSION)/share/llvm/cmake"|LLVM_CMAKE_DIR "/usr/share/llvm-$(LLVM_VERSION)/cmake"|' $(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/share/llvm/cmake/LLVMConfig.cmake
+# Disable CMake's package validation checks for Polly target files that we may remove.
+ sed -i '/_IMPORT_CHECK_TARGETS Polly/ {s|^|#|}' $(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/share/llvm/cmake/LLVMExports-*.cmake
+
# Managed in python-lldb-X.Y.links.in
rm -f $(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/python*/site-packages/lldb/_lldb.so
Bug#820334: Segfaults caused by new DT_MIPS_RLD_MAP_REL tag and RPATH removers
On 04/09/2016 11:01 AM, Mathieu Malaterre wrote: > On Sat, Apr 9, 2016 at 2:14 PM, Aurelien Jarno wrote: >> You mean that cmake is not calling chrpath, but instead has an embedded >> copy? In that case I'll look at that later today. Yes, CMake has a separate implementation. It is not a copy of chrpath but its own implementation, and was created because (at least at the time) chrpath did not support changing cross-compiled binaries. > That is how I understand the code in cmSystemTools::RemoveRPath (it > should hopefully be very close to chrpath implementation). > > Brad, is this the only location that needs to be fixed ? Yes, IIRC. -Brad
Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure
On 04/06/2016 05:42 PM, Steven Chamberlain wrote:
> | if(${BuildDepends_BINARY_DIR}/Project/multi2-real.txt
> | IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi2-stamp.txt)
>
> If multi2-real.txt and multi2-stamp.txt are created within 1 second of
> each other, the test will most likely fail on those filesystems.
>
> I think the testcase should allow something like "newer or equal to".
> I don't know if there's a CMake macro to do exactly that.
FYI, the IS_NEWER_THAN check actually documents that it returns true
when the times are exactly equal:
https://cmake.org/cmake/help/v3.5/command/if.html
"If the file time stamps are exactly the same, an IS_NEWER_THAN
comparison returns true, so that any dependent build operations
will occur in the event of a tie."
One can confirm this in the implementation here:
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmConditionEvaluator.cxx;hb=v3.5.1#l720
"fileIsNewer==1 || fileIsNewer==0"
This change was made to CMake long ago specifically to fix cases on
filesystems with low time resolution. Upstream CMake nightly testing
runs on some filesystems with 1s resolution, such as HFS on OS X.
The failures under discussion here are indeed strange. Thanks for
investigating!
-Brad
Bug#819072: llvm-3.8-dev: LLVM CMake files broken by Debian packaging
On 03/31/2016 04:26 PM, Sylvestre Ledru wrote: > many thanks. I will try to integrate that asap. Great! I can try installing a revised package to check it, when ready. > By the way, a side question, after the build with cmake, before the > "make install", is > it possible to remove the temporary files (*.o for example)? > The whole build requires a lot of spaces. 29G on my system. There is no builtin feature to remove just the .o files but you could script it yourself. However, following that with "make install" will recompile them. Instead use "make install/fast" to perform the installation without re-checking any build dependencies. -Brad
Bug#819072: llvm-3.8-dev: LLVM CMake files broken by Debian packaging
On 03/24/2016 11:42 AM, Sylvestre Ledru wrote:
>> CMake Error at /usr/share/llvm-3.8/cmake/LLVMConfig.cmake:178 (include):
>> include could not find load file:
> As you are much more familiar than me on this, would you mind proposing a
> patch?
While I'm familiar with LLVM's CMake packaging infrastructure I'm not so
much with debian packaging. I'm not set up to try building the package
myself but I can help you update
https://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/3.8/
as covered in the following sections.
--
The `debian/patches/fix-cmake-config-prefix.diff` patch needs to be extended
to cover the CMake build system too. I've attached the updated file.
That will fix LLVM_INSTALL_PREFIX and therefore everything LLVMConfig.cmake
computes relative to it (except LLVM_CMAKE_DIR, see below).
--
In `debian/llvm-X.Y-dev.install.in` we have:
# Explicit debian/tmp since there are multiple declarations
debian/tmp/usr/lib/llvm-@LLVM_VERSION@/share/llvm/cmake/*.cmake
usr/share/llvm-@LLVM_VERSION@/cmake/
This moves the CMake packaging files out of their original/intended location
under the install prefix and into a separate directory so they can be found
by default by find_package(LLVM) in CMake projects. However, this approach
breaks a few things:
* LLVMConfig.cmake uses
set(LLVM_CMAKE_DIR "${LLVM_INSTALL_PREFIX}/share/llvm/cmake")
to compute the location of the CMake packaging files. This is broken
when they are moved. Previously `debian/rules` accounted for this by
fixing up LLVMConfig.cmake:
# Change CMake module dir
sed -i 's|LLVM_CMAKE_DIR
"/usr/lib/llvm-$(LLVM_VERSION)/share/llvm/cmake"|LLVM_CMAKE_DIR
"/usr/share/llvm-$(LLVM_VERSION)/cmake"|'
$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/share/llvm/cmake/LLVMConfig.cmake
This line does not work with the CMake-based build of LLVM because the
content in LLVMConfig.cmake that it tries to update is now different.
* LLVMExports.cmake expects to find the LLVM library files (*.a, etc.)
relative to its own location. This is broken when it is moved.
One possible fix is to hack both of these files post-installation again.
This approach may require future maintenance as the content of the files
changes. IMO instead we should do what I suggested in #785931 originally:
drop the relocation of the cmake directory and instead add a symlink
/usr/share/llvm-@LLVM_VERSION@/cmake ->
/usr/lib/llvm-@LLVM_VERSION@/share/llvm/cmake
That way the CMake packaging files can compute everything relative to
their own location. The symlink will still allow find_package(LLVM)
to work out of the box.
--
CMake's packaging files have checks to make sure the library files
it installed are all there. After manually hacking my local system
to pretend the above changes were made to the packaging, I now get
this error:
CMake Error at /usr/lib/llvm-3.8/share/llvm/cmake/LLVMExports.cmake:1034
(message):
The imported target "PollyISL" references the file
"/usr/lib/llvm-3.8/lib/libPollyISL.a"
but this file does not exist. Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
"/usr/lib/llvm-3.8/share/llvm/cmake/LLVMExports.cmake"
but not all the files it references.
The reason for this is because `debian/rules` does:
# Don't think it is used
rm -f $(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/libPolly*a
We either need to leave these files in place or teach `debian/rules` to
fix content in `LLVMExports-relwithdebinfo.cmake`:
sed -i '/_IMPORT_CHECK_TARGETS Polly/ {s|^|#|}'
$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/share/llvm/cmake/LLVMExports-*.cmake
This simply disables CMake's check that the Polly library files exist.
--
After manually hacking my local system to pretend the above changes
were made to the packaging, I now get this error:
CMake Error at /usr/lib/llvm-3.8/share/llvm/cmake/LLVMExports.cmake:1034
(message):
The imported target "LLVM" references the file
"/usr/lib/llvm-3.8/lib/libLLVM-3.8.so.1"
but this file does not exist. Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
"/usr/lib/llvm-3.8/share/llvm/cmake/LLVMExports.cmake"
but not all the files it references.
The package moves this file to /usr/lib/x86_64-linux-gnu/libL
Bug#819072: llvm-3.8-dev: LLVM CMake files broken by Debian packaging
Package: llvm-3.8-dev Version: 1:3.8-2 Severity: normal Dear Maintainer, Issues similar to those in bug #785931 have returned in the 3.8 package. When a CMake-based project does find_package(LLVM) on Debian one gets CMake Error at /usr/share/llvm-3.8/cmake/LLVMConfig.cmake:178 (include): include could not find load file: /usr/share/llvm/cmake/LLVMExports.cmake The reason is explained in this thread on the llvm mailing list: http://thread.gmane.org/gmane.comp.compilers.llvm.cvs/255502/focus=255724 Basically upstream LLVM made changes during 3.8 development to make their CMake packaging files relocatable by computing locations relative to one another. However, Debian's packaging changes these relative locations by moving things around after installation. Therefore the wrong locations are computed. Debian packaging must be taught to patch LLVMConfig.cmake to specify absolute locations of LLVM_INSTALL_PREFIX, LLVM_CMAKE_DIR, etc. based on where Debian puts them. Note that the 'castxml' package requires LLVM/Clang CMake packaging files to build. Therefore building that package against a llvm-*-dev package (and libclang-*-dev) will reveal such problems. -Brad
Bug#813875: insighttoolkit4: FTBFS on i386 (member reference base type 'void' is not a structure or union)
On 02/06/2016 06:34 AM, Gert Wollny wrote: > As you can see, this is actually a bug in castxml [snip] > would you please consider filing a bug upstream I've recorded the issue upstream here: https://github.com/CastXML/CastXML/issues/47 Please follow that for updates. -Brad
Bug#785931: llvm-3.6-dev: LLVM CMake files broken by Debian packaging
On 06/23/2015 10:51 AM, Sylvestre Ledru wrote: > I guess 3.6.1-1 didn't fix the issue... sorry about that. For reference, upstream has made changes that affect the packaging of CMake files for llvm 3.7. See this thread/message for the changes needed in Debian: [PATCH] Make CMake files generated by the Autoconf build system relocatable. http://thread.gmane.org/gmane.comp.compilers.llvm.cvs/255502/focus=255724 That does not affect this issue for llvm 3.6 packaging though. -Brad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#785931: llvm-3.6-dev: LLVM CMake files broken by Debian packaging
On 05/20/2015 10:13 AM, Brad King wrote: > On 05/20/2015 09:54 AM, Sylvestre Ledru wrote: >> I just updated 3.6.1-1 which should fix this issue. > Indeed, I see the packaging change: > > http://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/3.6/debian/rules?r1=1541&r2=1577&pathrev=1577 I just installed llvm-3.6-dev version 3.6.1-1 from unstable but the path is not fixed: $ grep set.LLVM_CMAKE_DIR /usr/share/llvm-3.6/cmake/LLVMConfig.cmake set(LLVM_CMAKE_DIR "/usr/lib/llvm-3.6/share/llvm/cmake") Was that version built with the above change? Thanks, -Brad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#785931: llvm-3.6-dev: LLVM CMake files broken by Debian packaging
On 05/20/2015 09:54 AM, Sylvestre Ledru wrote: > I just updated 3.6.1-1 which should fix this issue. > Could you check that? Indeed, I see the packaging change: http://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/3.6/debian/rules?r1=1541&r2=1577&pathrev=1577 It fixes the content of LLVMConfig.cmake to match the packaged location of the files. Thanks, -Brad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735592: llvm-3.5-dev: LLVM/Clang CMake package files missing
On 03/13/2015 12:20 PM, Ulf Wetzker wrote:
>> The files contain bad internal filenames.
>>
>> CMake Error at /usr/share/llvm-3.5/cmake/LLVMConfig.cmake:43 (include):
>>> include could not find load file:
>>>
>>> /usr/lib/llvm-3.5/share/llvm/cmake/LLVMExports.cmake
>
> In LLVMConfig.cmake the variable ${LLVM_CMAKE_DIR} is set to
> /usr/lib/llvm-3.5/share/llvm/cmake. While trying to include
> LLVMExports.cmake from ${LLVM_CMAKE_DIR} this error it thrown since
> LLVMConfig.cmake and LLVMExports.cmake are both located in
> /usr/share/llvm-3.5/cmake/
The original issue has been addressed upstream. This new error is
caused by how Debian packaging modifies the installation layout.
I've reported this as a separate issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785931
-Brad
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#785931: llvm-3.6-dev: LLVM CMake files broken by Debian packaging
Package: llvm-3.6-dev Version: 1:3.6-2 Severity: normal Dear Maintainer, The issue reported in bug #735592 is not fully resolved (as reported in some follow-up posts in that issue). While that problem has been resolved in upstream LLVM 3.6, another problem is caused by Debian packaging. When a CMake-based project does find_package(LLVM) on Debian one gets: CMake Error at /usr/share/llvm-3.6/cmake/LLVMConfig.cmake:52 (include): include could not find load file: /usr/lib/llvm-3.6/share/llvm/cmake/LLVMExports.cmake The problem does not occur with upstream LLVM 3.6. It is caused by the adjustment of the installed file layout done by Debian packaging. First 'debian/rules' configures with --prefix=/usr/lib/llvm-$(LLVM_VERSION) The build generates content in debian/tmp/usr/lib/llvm-@LLVM_VERSION@/share/llvm/cmake/LLVMConfig.cmake that references the directory /usr/lib/llvm-@LLVM_VERSION@/share/llvm/cmake because that is where files are installed by upstream for the given prefix. Then 'debian/llvm-X.Y-dev.install.in' has: debian/tmp/usr/lib/llvm-@LLVM_VERSION@/share/llvm/cmake/*.cmake usr/share/llvm-@LLVM_VERSION@/cmake/ This moves these files to a different location during packaging, but the content of 'LLVMConfig.cmake' expects the original location. I'm able to work around the issue locally by running $ sudo ln -s /usr/share/llvm-3.6 /usr/lib/llvm-3.6/share/llvm to restore the existence of the original path to the files. The Debian package should be updated to add this symlink. Or, it can install the files to the original location and add a symlink in the other direction (to satisfy default find_package search paths). Thanks, -Brad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#691948: cmake: Insists on using non-existent (when cross-compiling) --rdynamic flag
On 10/04/2014 08:58 AM, Mathieu Malaterre wrote: > I think OP should have mentioned that the project is C-only, eg: Yes. Your --out-implib problem was due to trying to use the Linux host C++ compiler for cross-compiling to Windows. To build a project using C++ one would also need: -DCMAKE_CXX_COMPILER=i686-w64-mingw32-g++ > $ cmake -G 'Unix Makefiles' -DCMAKE_SYSTEM_NAME=Windows > -DCMAKE_C_COMPILER=i686-w64-mingw32-gcc > -DCMAKE_RC_COMPILER=i686-w64-mingw32-windres .. > -- The C compiler identification is GNU 4.6.3 > -- Check for working C compiler: /usr/bin/i686-w64-mingw32-gcc > -- Check for working C compiler: /usr/bin/i686-w64-mingw32-gcc -- broken > CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61 > (message): > The C compiler "/usr/bin/i686-w64-mingw32-gcc" is not able to compile a > simple test program. [snip] > i686-w64-mingw32-gcc: error: unrecognized option '-rdynamic' I cannot reproduce that with CMake 3.0. -Brad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761516: cmake: decide on a place for third parties to install extra modules
On 09/15/2014 02:12 PM, Ximin Luo wrote: > So, what do you think Debian maintainers should do? Leave it to the upstreams. > "Use their discretion" or what? I couldn't find any on my local system, > but from the looks of it there are quite a few other packages that > install these files, but they all do their own thing and there's no standard: > > https://packages.debian.org/search?suite=sid&arch=any&searchon=contents&keywords=cmake The current listing at that link mostly contains .cmake language files, not CMake package configuration files for find_package(). Debian maintainers cannot simply relocate .cmake files even if they are meant to be found by find_package. Such files contain information about the other files in their packages, often represented as a path relative to the location of the .cmake file itself. IMO this is a non-issue for Debian. -Brad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761516: cmake: decide on a place for third parties to install extra modules
On 09/14/2014 10:51 AM, Ximin Luo wrote: > the following paths will automatically be picked up by CMake: > > /usr/(lib/|lib|share)/cmake/$package/ > /usr/(lib/|lib|share)/$package/ > /usr/(lib/|lib|share)/$package/(cmake|CMake)/ Correct. >> http://www.cmake.org/cmake/help/git-master/manual/cmake-packages.7.html For reference, a more permanent URL for the current version of the document is: http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html >> That document recommends /usr/lib/cmake as the install location; however that >> is arguably not compatible with FHS because cmake files are architecture >> independent, so should be in /usr/share/cmake The package configuration files are not always architecture independent. For some projects they are, for some projects they are not. Sometimes they contain information derived from the target architecture while building the project. -Brad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#747306: SIGSEGV: cmGlobalGenerator::FindMakeProgram(cmMakefile*) ()
On 05/07/2014 08:58 AM, Mathieu Malaterre wrote: > segmentation fault I just fixed this upstream and added a test: ctest_build: Do not crash on bad generator name http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=54111286 The hunk in Source/CTest/cmCTestBuildCommand.cxx could easily be backported to earlier versions. -Brad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735592: llvm-3.5-dev: LLVM/Clang CMake package files missing
On 02/19/2014 04:54 PM, Sylvestre Ledru wrote: > this patch fixes it. I will upload it when I have more stuff to upload > (except if you need it soon) Thanks. I will wait for the next update and then try it again. -Brad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735592: llvm-3.5-dev: LLVM/Clang CMake package files missing
On 02/14/2014 12:41 PM, Sylvestre Ledru wrote: > I just uploaded a new snapshot release of llvm with your changes. Thanks. However, the files still do not appear as of 1:3.5~svn201412-1. I downloaded the package source and it does have the changes to the Makefile rules but the files still do not seem to be installed. Does the packaging config file "debian/llvm-3.5-dev.install" line: cmake/modules/*.cmake usr/share/llvm-3.5/cmake/ influence this? The missing modules appear in the build tree here: cmake/modules/LLVMConfig.cmake cmake/modules/LLVMConfigVersion.cmake cmake/modules/LLVMExports.cmake The "make install" rules install the needed modules from both the build and source trees when building with configure+make by hand but I have not tried building the debian package from source. -Brad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735592: llvm-3.5-dev: LLVM/Clang CMake package files missing
On 01/24/2014 03:47 PM, Brad King wrote: > I've prepared a more general-purpose series and posted it > for upstream review on llvm-commits The series has been applied upstream trunk as of r201053: http://thread.gmane.org/gmane.comp.compilers.llvm.cvs/173517/focus=175229 This issue should be automatically resolved when a version containing that change is released and packaged. -Brad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735592: llvm-3.5-dev: LLVM/Clang CMake package files missing
On 01/22/2014 10:54 AM, Sylvestre Ledru wrote: > wahou, that is excellent. Thanks! > Are you going to submit them upstream ? > (I can apply them if you need a contact). I've prepared a more general-purpose series and posted it for upstream review on llvm-commits: http://thread.gmane.org/gmane.comp.compilers.llvm.cvs/173517 Thanks, -Brad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735592: llvm-3.5-dev: LLVM/Clang CMake package files missing
On 01/22/2014 09:46 PM, Sylvestre Ledru wrote: > Beside: > +# TODO: De-duplicate target lists w.r.t. 'autoconf/configure.ac' [snip] > It sounds good. Could you see to fix that? Since that requires re-running autoconf I went ahead and took care of the other AC_SUBST updates too. Updated patch 2 attached. Note now that the version components go through AC_SUBST this patch will conflict in autoconf/configure.ac when moved between versions of LLVM. I built it on top of 3.4. This must be followed up by a patch to 'configure' made by running "autoconf/AutoRegen.sh". However, I do not have the versions of the autotools required by that script so the 'configure' generated on my machine for local testing is not suitable for distribution. Thanks, -Brad >From 83cb7d3898947b7b38eaf6960a3b0022bf0c7266 Mon Sep 17 00:00:00 2001 Message-Id: <83cb7d3898947b7b38eaf6960a3b0022bf0c7266.1390495723.git.brad.k...@kitware.com> In-Reply-To: <52e08268.2090...@debian.org> References: <52e08268.2090...@debian.org> From: Brad King Date: Wed, 22 Jan 2014 10:00:50 -0500 Subject: [PATCH] Makefile: Build and install CMake package modules Teach the Makefile build system to generate and install modules LLVMConfig.cmake and LLVMConfigVersion.cmake so that applications that build with CMake can use 'find_package(LLVM)' even when LLVM is not built with CMake. These modules tell such applications about available LLVM libraries and their dependencies. Run llvm-config to generate the list of libraries and use the results of LLVMBuild to generate the library dependencies. Use sed to perform substitutions in the LLVMConfig.cmake.in and LLVMConfigVersion.cmake.in sources that our CMake build system uses. Teach autoconf/configure.ac to AC_SUBST several new values that we need. --- Makefile| 4 +- Makefile.config.in | 15 Makefile.rules | 15 +--- autoconf/configure.ac | 24 +--- autoconf/m4/define_subst.m4 | 5 +++ cmake/Makefile | 12 ++ cmake/modules/Makefile | 90 + 7 files changed, 152 insertions(+), 13 deletions(-) create mode 100644 autoconf/m4/define_subst.m4 create mode 100644 cmake/Makefile create mode 100644 cmake/modules/Makefile diff --git a/Makefile b/Makefile index e3672b7..e38cc6d 100644 --- a/Makefile +++ b/Makefile @@ -15,7 +15,7 @@ LEVEL := . # 3. Build IR, which builds the Intrinsics.inc file used by libs. # 4. Build libs, which are needed by llvm-config. # 5. Build llvm-config, which determines inter-lib dependencies for tools. -# 6. Build tools and docs. +# 6. Build tools, docs, and cmake modules. # # When cross-compiling, there are some things (tablegen) that need to # be build for the build system first. @@ -31,7 +31,7 @@ ifeq ($(BUILD_DIRS_ONLY),1) OPTIONAL_DIRS := tools/clang/utils/TableGen else DIRS := lib/Support lib/TableGen utils lib/IR lib tools/llvm-shlib \ - tools/llvm-config tools docs unittests + tools/llvm-config tools docs cmake unittests OPTIONAL_DIRS := projects bindings endif diff --git a/Makefile.config.in b/Makefile.config.in index dcca45f..7633be2 100644 --- a/Makefile.config.in +++ b/Makefile.config.in @@ -15,6 +15,8 @@ # Define LLVM specific info and directories based on the autoconf variables LLVMPackageName := @PACKAGE_TARNAME@ LLVMVersion := @PACKAGE_VERSION@ +LLVM_VERSION_MAJOR := @LLVM_VERSION_MAJOR@ +LLVM_VERSION_MINOR := @LLVM_VERSION_MINOR@ LLVM_CONFIGTIME := @LLVM_CONFIGTIME@ ### @@ -118,6 +120,7 @@ HOST_ARCH=@HOST_ARCH@ # Target hardware architecture ARCH=@ARCH@ TARGET_NATIVE_ARCH := $(ARCH) +LLVM_NATIVE_ARCH := @LLVM_NATIVE_ARCH@ # Indicates, whether we're cross-compiling LLVM or not LLVM_CROSS_COMPILING=@LLVM_CROSS_COMPILING@ @@ -207,13 +210,22 @@ POD2MAN:= @POD2MAN@ PDFROFF:= @PDFROFF@ ZIP:= @ZIP@ +HAVE_LIBZ := @HAVE_LIBZ@ +HAVE_DLOPEN := @HAVE_DLOPEN@ HAVE_PTHREAD := @HAVE_PTHREAD@ +HAVE_TERMINFO := @HAVE_TERMINFO@ LIBS := @LIBS@ +# Targets that are possible to build +ALL_TARGETS := @ALL_TARGETS@ + # Targets that we should build TARGETS_TO_BUILD=@TARGETS_TO_BUILD@ +# Targets supporting JIT +TARGETS_WITH_JIT := @TARGETS_WITH_JIT@ + # Path to directory where object files should be stored during a build. # Set OBJ_ROOT to "." if you do not want to use a separate place for # object files. @@ -250,6 +262,9 @@ ENABLE_CLANG_STATIC_ANALYZER = @ENABLE_CLANG_STATIC_ANALYZER@ # When ENABLE_WERROR is enabled, we'll pass -Werror on the command line ENABLE_WERROR = @ENABLE_WERROR@ +# When ENABLE_TERMINFO is enabled, we use terminfo. +ENABLE_TERMINFO = @ENABLE_TERMINFO@ + # When ENABLE_OPTIMIZED is enabled, LLVM code is optimized and output is put # into the "Re
Bug#735592: llvm-3.5-dev: LLVM/Clang CMake package files missing
On 01/18/2014 10:54 AM, Sylvestre Ledru wrote:
> Maybe there is a way to generate this file with the autotools?
Yes, and here are patches to do so.
I built these on top of the 3.4 release:
llvm/branches/release_34@197944
They also correctly work on top of a recent trunk:
llvm/trunk@199058
They should work for r197556.
The latter patch contains some hacks to avoid re-running
autoconf so it can be simplified if it goes upstream as
noted in the TODO comments.
-Brad
>From deeda6e64171bff53b96d6d32f54f4741b1a0da9 Mon Sep 17 00:00:00 2001
Message-Id:
In-Reply-To: <52daa3d3.8030...@debian.org>
References: <52daa3d3.8030...@debian.org>
From: Brad King
Date: Tue, 21 Jan 2014 09:50:53 -0500
Subject: [PATCH 1/2] Simplify LLVMConfig.cmake inclusion of LLVM-Config module
The LLVMConfig.cmake file we generate already hard-codes include and lib
paths under the install prefix and therefore works only from the install
tree. Simply include LLVM-Config from the location it is known to be
installed. In the future we could configure a separate LLVMConfig.cmake
to work in the build tree.
---
cmake/modules/LLVMConfig.cmake.in | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/cmake/modules/LLVMConfig.cmake.in b/cmake/modules/LLVMConfig.cmake.in
index 68fe296..32d1c7f 100644
--- a/cmake/modules/LLVMConfig.cmake.in
+++ b/cmake/modules/LLVMConfig.cmake.in
@@ -43,16 +43,4 @@ set(LLVM_INCLUDE_DIRS ${LLVM_INSTALL_PREFIX}/include)
set(LLVM_LIBRARY_DIRS ${LLVM_INSTALL_PREFIX}/lib)
set(LLVM_DEFINITIONS "-D__STDC_LIMIT_MACROS" "-D__STDC_CONSTANT_MACROS")
-# We try to include using the current setting of CMAKE_MODULE_PATH,
-# which suppossedly was filled by the user with the directory where
-# this file was installed:
-include( LLVM-Config OPTIONAL RESULT_VARIABLE LLVMCONFIG_INCLUDED )
-
-# If failed, we assume that this is an un-installed build:
-if( NOT LLVMCONFIG_INCLUDED )
- set(CMAKE_MODULE_PATH
-${CMAKE_MODULE_PATH}
-"@LLVM_SOURCE_DIR@/cmake/modules")
- include( LLVM-Config )
-endif()
-
+include(${LLVM_INSTALL_PREFIX}/share/llvm/cmake/LLVM-Config.cmake)
--
1.8.5.2
>From b9ac38eeed2946b61c3e0d63c0510129cf677a21 Mon Sep 17 00:00:00 2001
Message-Id:
In-Reply-To: <52daa3d3.8030...@debian.org>
References: <52daa3d3.8030...@debian.org>
From: Brad King
Date: Wed, 22 Jan 2014 10:00:50 -0500
Subject: [PATCH 2/2] Makefile: Build and install CMake package modules
Teach the Makefile build system to generate and install modules
LLVMConfig.cmake and LLVMConfigVersion.cmake so that applications that
build with CMake can use 'find_package(LLVM)' even when LLVM is not
built with CMake. These modules tell such applications about available
LLVM libraries and their dependencies.
Run llvm-config to generate the list of libraries and use the results
of LLVMBuild to generate the library dependencies. Use sed to perform
substitutions in the LLVMConfig.cmake.in and LLVMConfigVersion.cmake.in
sources that our CMake build system uses.
Several values that we need are not AC_SUBST'd by autoconf/configure.ac
so parse them out of include/llvm/Config/config.h for now and leave TODO
comments.
---
Makefile | 4 +-
Makefile.config.in | 1 +
Makefile.rules | 15 ---
cmake/Makefile | 12 ++
cmake/modules/Makefile | 103 +
5 files changed, 128 insertions(+), 7 deletions(-)
create mode 100644 cmake/Makefile
create mode 100644 cmake/modules/Makefile
diff --git a/Makefile b/Makefile
index e3672b7..e38cc6d 100644
--- a/Makefile
+++ b/Makefile
@@ -15,7 +15,7 @@ LEVEL := .
# 3. Build IR, which builds the Intrinsics.inc file used by libs.
# 4. Build libs, which are needed by llvm-config.
# 5. Build llvm-config, which determines inter-lib dependencies for tools.
-# 6. Build tools and docs.
+# 6. Build tools, docs, and cmake modules.
#
# When cross-compiling, there are some things (tablegen) that need to
# be build for the build system first.
@@ -31,7 +31,7 @@ ifeq ($(BUILD_DIRS_ONLY),1)
OPTIONAL_DIRS := tools/clang/utils/TableGen
else
DIRS := lib/Support lib/TableGen utils lib/IR lib tools/llvm-shlib \
- tools/llvm-config tools docs unittests
+ tools/llvm-config tools docs cmake unittests
OPTIONAL_DIRS := projects bindings
endif
diff --git a/Makefile.config.in b/Makefile.config.in
index dcca45f..2d8d613 100644
--- a/Makefile.config.in
+++ b/Makefile.config.in
@@ -207,6 +207,7 @@ POD2MAN:= @POD2MAN@
PDFROFF:= @PDFROFF@
ZIP:= @ZIP@
+HAVE_LIBZ := @HAVE_LIBZ@
HAVE_PTHREAD := @HAVE_PTHREAD@
LIBS := @LIBS@
diff --git a/Makefile.rules b/Makefile.rules
index 68f6cf8..0355ca7 100644
--- a/Makefile.rules
+++ b/Makefile.rules
@@ -78,6 +78,10 @@ LLVMBuildTool := $(PROJ_SRC_ROOT)/utils/llvm-build/llvm-build
# The files we are going to generate using llvm-build.
Bug#735592: llvm-3.5-dev: LLVM/Clang CMake package files missing
Package: llvm-3.5-dev Version: 1:3.5~svn197556-1 Severity: normal Dear Maintainer, The issue reported in archived bug #701153 is not fully resolved. The main problem still exists as of llvm-3.5-dev 1:3.5~svn197556-1. The cmake/modules/*.cmake files from the llvm source are installed including a file called "LLVM-Config.cmake". However, the files needed to use CMake to build against LLVM as documented here: http://llvm.org/docs/CMake.html#embedding-llvm-in-your-project are not installed. These files are: LLVMConfig.cmake= package configuration file LLVMConfigVersion.cmake = package version file They are produced during the CMake configuration process for building LLVM itself. Their purpose is to hold information about what was built and where it is installed. Note that "LLVM-Config.cmake" is *not* the same as "LLVMConfig.cmake". The former is a module that upstream authors wrote to contain some CMake-language API code. The latter is a CMake "package configuration file" that is located and loaded by applications using find_package(LLVM) or find_package(LLVM CONFIG REQUIRED) in their CMake code as shown in the LLVM documentation. Without the missing files the applications fail to build with errors like that shown below. -Brad CMake Error at CMakeLists.txt:36 (find_package): Could not find a package configuration file provided by "LLVM" with any of the following names: LLVMConfig.cmake llvm-config.cmake Add the installation prefix of "LLVM" to CMAKE_PREFIX_PATH or set "LLVM_DIR" to a directory containing one of the above files. If "LLVM" provides a separate development package or SDK, be sure it has been installed. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages llvm-3.5-dev depends on: ii libc6 2.17-97 ii libcloog-isl4 0.18.1-3 ii libffi-dev 3.0.13-4 ii libffi63.0.13-4 ii libgcc11:4.8.2-10 ii libgmp10 2:5.1.3+dfsg-1 ii libisl10 0.12.1-2 ii libjsoncpp00.6.0~rc2-3 ii libllvm3.5 1:3.5~svn197556-1 ii libstdc++6 4.8.2-10 ii libtinfo-dev 5.9+20130608-1 ii libtinfo5 5.9+20130608-1 ii llvm-3.5 1:3.5~svn197556-1 llvm-3.5-dev recommends no packages. llvm-3.5-dev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#717144: Remove workaround-gcc296-bugs from ctest -T MemCheck
On 07/17/2013 07:15 AM, Modestas Vainius wrote: > Yes, I do. I fail to see why you would point me to it. Just to be clear, I'm > NOT against fixing this bug, I'm against fixing this bug via Debian patch. > That's it. > > So either you report it upstream (which will be faster), or I will do it > sometime eventually. This was changed upstream in May 2013: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3b5b7589 -Brad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#700320: cmake: Cmake licensing may not be open source
On 02/11/2013 11:22 AM, Nigel Horne wrote: > According to Copright.txt in cmake: > > CMake - Cross Platform Makefile Generator > Copyright 2000-2011 Kitware, Inc., Insight Software Consortium > All rights reserved. > > It's either open source or "all rights reservered". The caveats underneath > that notice are not relavent since the two are mutually incompatible. The license is a standard OSI-approved BSD 3-Clause license: http://opensource.org/licenses/BSD-3-Clause The license template starts with: Copyright (c) , All rights reserved. -Brad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683484: cmake: Please add multiarch libdir into CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES
On 08/01/2012 03:48 AM, D. Barbier wrote:
> I use ${CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES} to remove system
> paths from RPATH.
FYI, CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES is not documented by
CMake as a publicly available value. It is an internal implementation
detail, though I doubt it is going away.
> It worked fine, but after migrating this package to multiarch, RPATH
> now contains
> /usr/lib/ because this directory is not listed in
> CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES.
> Can you please add it?
CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES contains hard-coded
guesses on specific platforms for typical system directories.
It pre-dates CMake's modern functionality that detects the real
implicit library search path used by the compiler front-end.
Those results are stored in
CMAKE_${lang}_IMPLICIT_LINK_DIRECTORIES
where "${lang}" is "C", "CXX", "Fortran", etc. for each language
that has been enabled. This one is publicly documented:
http://www.cmake.org/cmake/help/v2.8.8/cmake.html#variable:CMAKE_LANG_IMPLICIT_LINK_DIRECTORIES
Use that instead. It first appeared in CMake 2.8.0.
-Brad
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#667417: fixing __float128?
On 07/27/2012 02:17 AM, Mathieu Malaterre wrote: > On Fri, Jul 27, 2012 at 4:13 AM, Steve M. Robbins wrote: >> Hey ... is there a trick to fix #654718 similar to that for __int128? > > #undef _GLIBCXX_USE_FLOAT128 No, that is not the same problem. The __int128 fix told the *standard library* headers not to use the type by setting its own preprocessor symbols correctly. In this case the problem is in the fftw headers. The fftw3.h header contains a big #if test to decide whether the __float128 type is available. It *already* contains an exclusion for the Intel compiler. It also needs an exclusion for gccxml just as it would for any other compiler that defines __GNUC__ but is not really the GNU compiler version it reports. This is what I suggested in the original thread on our list: http://thread.gmane.org/gmane.comp.compilers.gccxml/602 Other projects have accepted upstream modifications for the same reason, such as Boost: http://svn.boost.org/svn/boost/tags/release/Boost_1_50_0/boost/config/compiler/gcc_xml.hpp -Brad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675181: gccxml cannot parse under GCC 4.7.1
On 07/26/2012 05:31 AM, Mathieu Malaterre wrote: > reopen 675181 > severity grave > retitle 675181 gccxml cannot parse under GCC 4.7.1 > forwarded 675181 http://www.gccxml.org/Bug/view.php?id=13372 > thanks > > Not sure if this is ideal to reopen the bug instead of creating a new > one. But I believe doko intention was to kill #667417 with this gccxml > bug. So continuing the effort. > > I can reproduce the __int128 issue with current gccxml package in > debian. It seems it also affect upstream (not checked if this is > fixed), since upstream bug tracker reports it as open on 2012/07/02. > > Brad could you please confirm bug 13372 in gccxml stills affect current > gccxml ? It did until I just fixed it. Thanks for reminding me. -Brad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#680825: [Debichem-devel] Bug#680825: gromacs: FTBFS: mv: cannot stat `/«PKGBUILDDIR»/debian/gromacs-mpich/usr/lib/*.so': No such file or directory
On 07/11/2012 02:55 PM, Brad King wrote: > This hunk: > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7ced0732#patch4 > Seems to have reversed a previous fix: > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=43cad3e4 > of a problem similar to what we observe here. This should fix it: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8720aa04 Ideally we should add a test for this case but I have no time now. We'll include the fix in the next 2.8.9 rc. -Brad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#680825: [Debichem-devel] Bug#680825: gromacs: FTBFS: mv: cannot stat `/«PKGBUILDDIR»/debian/gromacs-mpich/usr/lib/*.so': No such file or directory
On 07/11/2012 02:29 PM, Brad King wrote:
> Try adding the flag
>
> -DCMAKE_INSTALL_DEFAULT_COMPONENT_NAME=Unspecified
>
> to the CMake configuration step to work around the problem.
Nevermind about this workaround. I had tested it with a leftover
build of a "good" version during git bisect.
This hunk:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7ced0732#patch4
@@ -35,7 +36,9 @@ cmInstallCommandArguments::cmInstallCommandArguments()
,NamelinkOnly (&Parser, "NAMELINK_ONLY" , &ArgumentGroup)
,NamelinkSkip (&Parser, "NAMELINK_SKIP" , &ArgumentGroup)
,GenericArguments(0)
-{}
+{
+ this->Component.SetDefaultString(defaultComponent.c_str());
+}
Seems to have reversed a previous fix:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=43cad3e4
of a problem similar to what we observe here. The SetDefaultString
code never worked AFAICT.
-Brad
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#680825: [Debichem-devel] Bug#680825: gromacs: FTBFS: mv: cannot stat `/«PKGBUILDDIR»/debian/gromacs-mpich/usr/lib/*.so': No such file or directory
On 07/11/2012 03:40 AM, Evgeni Golov wrote: > Dear cmake maintainers, could you please have a look at the bug (and > build log) and guess why 2.8.9 stopped building the libraries in the > "mdrun" target? Is it a bad cmake file or a regression in cmake? It is a regression in CMake AFAICT. I bisected it down to here: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7ced0732 Try adding the flag -DCMAKE_INSTALL_DEFAULT_COMPONENT_NAME=Unspecified to the CMake configuration step to work around the problem. We'll try to get this fixed before the final 2.8.9 release. -Brad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#661676: CMake: Generated export file
On 2/29/2012 3:02 AM, Mathieu Malaterre wrote: Bug #661383 and #506992 describe the symptoms. Basically cmake internal mecanism to generating export file store full path to library [snip] IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE "/usr/lib/libz.so;vtksys" Right. CMake uses full paths for linking to avoid ambiguities. Users that set ZLIB_LIBRARY=/some/path/to/a/file/libz.so expect *that* file to be used, not /some/other/path/that/came/first/in/search/path/libz.so, and not /some/path/to/a/file/libz.a. When building against a library that publishes this file in its link interface users expect the *same* library to be used for that link as was used originally. I do not know if this possible but it would be much more flexible if cmake could generated instead: [snip] IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE "z;vtksys" If you want the VTK package to use "z" as its zlib library instead of a specific file then build it with -DZLIB_LIBRARY=z to tell it so. -Brad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#600889: cmake: find_package(VTK) with additional version requirement fails
On 01/10/2011 05:04 PM, Brad King wrote: > Debian can fix this for its VTK packages by adding such a file. > A tutorial is here: > > http://www.cmake.org/Wiki/CMake_2.6_Notes#Package_Version_Files > > The issue should be filed with VTK upstream too. I thought this seemed familiar. It's already fixed in VTK 5.5 and later: http://vtk.org/gitweb?p=VTK.git;a=commitdiff;h=19852427 The VTK 5.[024] series predated this fix. Debian's packages for those versions can add them to address this issue. -Brad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#600889: cmake: find_package(VTK) with additional version requirement fails
On 11/27/2010 09:39 AM, Kai Wasserbäch wrote: > tag 600889 + upstream patch > thanks > > Hello Michael, > I've investigated the problem further and it seems like FindVTK.cmake is > missing > a case for handling the VTK 5.x case. I've prepared a patch (applies on top of > FindVTK.cmake), which I've attached to this message. It needs probably some > more > thorough testing from somebody using VTK. So please try it with CMake 2.8.3 > (alternatively you can just use the FindPackageHandleStandardArgs.cmake file > from 2.8.3). As I commented in the CMake bug report: http://www.cmake.org/Bug/view.php?id=11678#c24561 this change to FindVTK.cmake is incorrect. The entire block of code around it is specifically looking for VTK 4.0 and nothing more recent. It starts with: # Special search for VTK 4.0. and the case reported in the bug is intentionally commented as # We found the wrong version. Pretend we did not find it. By "wrong version" it means "not 4.0". The *real* search takes place before that entire block begins: # Use the Config mode of the find_package() command to find VTKConfig. # If this succeeds (possibly because VTK_DIR is already set), the # command will have already loaded VTKConfig.cmake and set VTK_FOUND. IF(NOT _VTK_40_ONLY AND NOT VTK_FOUND) FIND_PACKAGE(VTK QUIET NO_MODULE) ENDIF() and is actually implemented in C++ in the find_package() command. This is actually a VTK issue. It does not provide a package version file (VTKConfigVersion.cmake) file next to its package configuration file (VTKConfig.cmake). Therefore it does not support versioned finds as documented by the find_package command: http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_package "When the [version] argument is given Config mode will only find a version of the package that claims compatibility with the requested version" Debian can fix this for its VTK packages by adding such a file. A tutorial is here: http://www.cmake.org/Wiki/CMake_2.6_Notes#Package_Version_Files The issue should be filed with VTK upstream too. -Brad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#496391: Fixed upstream, for real
Hi Folks, This bug was reported upstream and partly fixed in Dec 2008: http://www.gccxml.org/Bug/view.php?id=8083 There were *two* scripts with the problem. One was MIPSpro/find_flags, the other was "gccxml_find_flags" which was the one fixed (and later replaced by a C++ implementation anyway). At the time I missed that the MIPSpro one evaluates content of the file from /tmp in a shell as command-line arguments, permitting the back-tick evaluation attack. No one ever re-opened the bug to point that out or forwarded this Debian report upstream until now. I re-opened the upstream report with a link to this report, committed a fix, and closed it again with a reference to the commit. -Brad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#500883: vol_id doesn't recognize Adaptec 1220SA raid signature
Hi Folks,
FYI, I'm also having this problem with a 'via' software raid controller.
$ dpkg --status udev ~
Package: udev
Status: install ok installed
Priority: optional
Section: admin
Installed-Size: 804
Maintainer: Marco d'Itri <[EMAIL PROTECTED]>
Architecture: i386
Version: 0.125-7
...
# dmraid -r
/dev/sdb: via, "via_bcbdfdafja", mirror, ok, 1953525167 sectors, data@ 0
/dev/sda: via, "via_bcbdfdafja", mirror, ok, 1953525167 sectors, data@ 0
# dmraid -l
...
via : VIA Software RAID (S,0,1,10)
...
# udevadm info --query=all --name=sda
P: /block/sda
N: sda
S: disk/by-id/ata-WDC_WD10EACS-00ZJB0_WD-WCASJ0030976
S: disk/by-id/scsi-SATA_WDC_WD10EACS-00_WD-WCASJ0030976
S: disk/by-path/pci-:00:0f.0-scsi-0:0:0:0
E: ID_VENDOR=ATA
E: ID_MODEL=WDC_WD10EACS-00Z
E: ID_REVISION=01.0
E: ID_SERIAL=SATA_WDC_WD10EACS-00_WD-WCASJ0030976
E: ID_SERIAL_SHORT=WD-WCASJ0030976
E: ID_TYPE=disk
E: ID_BUS=scsi
E: ID_ATA_COMPAT=WDC_WD10EACS-00ZJB0_WD-WCASJ0030976
E: ID_PATH=pci-:00:0f.0-scsi-0:0:0:0
# udevadm info --query=all --name=sdb
P: /block/sdb
N: sdb
S: disk/by-id/ata-WDC_WD10EACS-00ZJB0_WD-WCASJ1473432
S: disk/by-id/scsi-SATA_WDC_WD10EACS-00_WD-WCASJ1473432
S: disk/by-path/pci-:00:0f.0-scsi-1:0:0:0
E: ID_VENDOR=ATA
E: ID_MODEL=WDC_WD10EACS-00Z
E: ID_REVISION=01.0
E: ID_SERIAL=SATA_WDC_WD10EACS-00_WD-WCASJ1473432
E: ID_SERIAL_SHORT=WD-WCASJ1473432
E: ID_TYPE=disk
E: ID_BUS=scsi
E: ID_ATA_COMPAT=WDC_WD10EACS-00ZJB0_WD-WCASJ1473432
E: ID_PATH=pci-:00:0f.0-scsi-1:0:0:0
Note that there is no ID_FS_USAGE entry.
Removing ENV{ID_FS_USAGE}=="raid" from 85_dmraid.rules does work around
the problem (actually, I copied the file to 85_dmraid-hack.rules and
removed the condition in there).
-Brad
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#494167: xvfb: crashes due to dbus/hal problems
Package: xvfb
Version: 2:1.4.2-2
Severity: important
I run tests of a project that needs an X server on a nightly basis. For
years I've been running them off-screen using Xvfb. I start an
instance:
Xvfb :52 -screen 0 1024x768x24 -fbdir /tmp/xvfb.52 -ac
and then run tests with "DISPLAY=:52". Recently I updated my debian
testing system and the server has started crashing regularly after a few
hundred tests have run. I tried building the version of the code being
tested to a time before this problem started but it didn't help.
Unfortunately I've been unable to reproduce the crash except by running
all the tests (and eventually one crashes Xvfb but which one is not
repeatable). However, I've localized the problem somewhat.
The Xvfb process reports a bunch of these messages (about 1 per test):
--
FreeFontPath: FPE "/usr/share/fonts/X11/misc" refcount is 2, should be 1;
fixing.
--
Later it reports a few messages of this form:
--
[config/hal] couldn't initialise context:
org.freedesktop.DBus.Error.LimitsExceeded (Connection ":1.20" is not allowed to
add more match rules (increase limits in configuration file if required))
--
and then crashes. If I stop the dbus daemon (/etc/init.d/dbus stop) the
crash does not occur. I found some discussion about this error here:
http://www.nabble.com/org.freedesktop.DBus.Error.LimitsExceeded-td17000158.html
but didn't see much about fixing it.
I used "apt-get source" for dbus and hal to build them with debug
symbols and install them into my home directory. Using LD_LIBRARY_PATH
I ran the system's Xvfb installation with my own dbus and hal libraries.
Of course it stopped crashing. Then I discovered that if I use
--localstatedir=/var when building dbus it crashes again. I'm pretty
sure that's because it needs to see the file
/var/run/dbus/system_bus_socket
Running with debug builds of the dbus and hal libraries let me get a
partial backtrace for the segfault:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2b8f43d80610 (LWP 1266)]
0x0020 in ?? ()
(gdb) where
#0 0x0020 in ?? ()
#1 0x2b8f428a8014 in filter_func (connection=0xb9abe0, message=0xb9b060,
user_data=0xd2d2b0) at libhal.c:1190
#2 0x2b8f42ac348b in dbus_connection_dispatch (connection=0xb9abe0) at
dbus-connection.c:4385
#3 0x2b8f42ac3843 in _dbus_connection_read_write_dispatch
(connection=0xb9abe0, timeout_milliseconds=0, dispatch=)
at dbus-connection.c:3414
#4 0x004bb0ab in ?? ()
The line "libhal.c:1190" is inside this a condition and loop:
if (dbus_message_is_signal (message, "org.freedesktop.Hal.Device",
"PropertyModified"))
if (ctx->device_property_modified != NULL) {
...
for (i = 0; i < num_modifications; i++) {
...
ctx->device_property_modified (ctx, // line 1190
object_path,
key,
removed,
added);
It looks like the device_property_modified pointer-to-function is bad.
Please let me know if you need more information.
FYI, I originally posted the problem to debian-user asking to what
package I should report this bug:
http://lists.debian.org/debian-user/2008/07/msg02915.html
but I have not heard back for a week so I'm guessing xvfb.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (989, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.22-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages xvfb depends on:
ii libc6 2.7-10 GNU C Library: Shared libraries
ii libdbus-1-3 1.2.1-2simple interprocess messaging syst
ii libfontenc1 1:1.0.4-3 X11 font encoding library
ii libhal1 0.5.11-2 Hardware Abstraction Layer - share
ii libpixman-1-0 0.10.0-2 pixel-manipulation library for X a
ii libxau6 1:1.0.3-3 X11 authorisation library
ii libxdmcp6 1:1.0.2-3 X11 Display Manager Control Protoc
ii libxfont1 1:1.3.3-1 X11 font rasterisation library
ii x11-common1:7.3+14 X Window System (X.Org) infrastruc
Versions of packages xvfb recommends:
ii xbase-clients 1:7.3+14 miscellaneous X clients - metapack
ii xfonts-base 1:1.0.0-5 standard fonts for X
xvfb suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Conta
Bug#316932: apcupsd: problem still exists in 3.14.2-1
Hi Folks,
I have a debian 'testing' system with /usr under lvm2 control and hit
this problem. I've gotten killpower working with a slightly patched
apcupsd 3.14.3-2, as follows:
$ apt-get source apcupsd
$ sudo apt-get build-dep apcupsd
$ cd apcupsd-3.14.3
$ patch -p1 < ~/apcupsd-lvm.patch
$ fakeroot debian/rules binary
Then install the .deb files produced for apcupsd and apcupsd-doc and
configure as normal. The patch switches to linking against static
libnetsnmp, libcrypto, and libz. It also removes a call to 'wall' during
apccontrol killpower (for some reason the echo before apcupsd --killpower
does not use wall but the call after it does, so I removed the extra call).
apcupsd-lvm.patch
--
diff --git a/configure b/configure
index 9983225..d49fedd 100755
--- a/configure
+++ b/configure
@@ -11972,7 +11972,7 @@ fi
echo "$as_me:$LINENO: result: $ac_cv_lib_crypto_EVP_DigestInit" >&5
echo "${ECHO_T}$ac_cv_lib_crypto_EVP_DigestInit" >&6
if test $ac_cv_lib_crypto_EVP_DigestInit = yes; then
- echo ' including crypto library for snmp.'; DRVLIBS="$DRVLIBS -lcrypto"
+ echo ' including crypto library for snmp.'; DRVLIBS="$DRVLIBS -Wl,-Bstatic
-lcrypto -lz -Wl,-Bdynamic"
fi
@@ -12048,7 +12048,7 @@ fi
echo "$as_me:$LINENO: result: $ac_cv_lib_netsnmp_snmp_open" >&5
echo "${ECHO_T}$ac_cv_lib_netsnmp_snmp_open" >&6
if test $ac_cv_lib_netsnmp_snmp_open = yes; then
- DRVLIBS="$DRVLIBS -lnetsnmp"
+ DRVLIBS="-Wl,-Bstatic -lnetsnmp -Wl,-Bdynamic $DRVLIBS"
SNMP_LIB_FOUND="yes"
fi
diff --git a/platforms/apccontrol.in b/platforms/apccontrol.in
index cc2aae9..e8fa840 100644
--- a/platforms/apccontrol.in
+++ b/platforms/apccontrol.in
@@ -61,7 +61,7 @@ case "$1" in
echo "Apccontrol doing: ${APCUPSD} --killpower on UPS ${2}"
sleep 10
${APCUPSD} --killpower
- echo "Apccontrol has done: ${APCUPSD} --killpower on UPS ${2}" | ${WALL}
+ echo "Apccontrol has done: ${APCUPSD} --killpower on UPS ${2}"
;;
commfailure)
echo "Warning communications lost with UPS ${2}" | ${WALL}
--
I hope this solution helps others.
-Brad
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#287579: vtk API changes
Mathieu Malaterre wrote: Mark Hymers wrote: I've just been talking to some of the people on #debian about this and we've agreed that API changes (e.g. those from 4.2 to 4.4) without soname bumps are a serious bug. Unfortunately, it looks like upstream doesn't behave sanely in this area. As the Debian maintainer, are you > Brad King recently fix the versioning in VTK CVS (before the 5.0) > branch. And I believe everything is set properly using CMake: SOVERSION. > Brad do you want to add anything ? I've been making several changes with the goal of bringing VTK into the modern world of versioned installations. The upcoming VTK 5.0 release does have full soname versioning when building with shared libraries. It also has fully configurable install locations so that the libraries, executables, cmake packaging, Tcl wrappers, python wrappers, etc. can all be configured to go to specific places. If there are further troubles with smoothly creating a Debian package out of the 5.0 release please post to the VTK developers list: http://www.vtk.org/mailman/listinfo/vtk-developers and I will be happy to help you with them. -Brad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
