|
Notes |
|
|
(0024343)
|
|
Craig Scott
|
|
2010-12-31 06:55
|
|
|
The file at cmake-2.8.3/Source/kwsys/SystemInformation.cxx pulls in the sys/procfs.h header, which is not part of the LSB, but it would appear that the header can be omitted and things build okay without it. |
|
|
|
(0024344)
|
|
Craig Scott
|
2010-12-31 07:08
(edited on: 2010-12-31 07:12) |
|
frm_driver.c and frm_post.c use getmaxx and getmaxy, neither of which are defined in the LSB. Note that the curses.h header defines getmaxyx(), but that might not be close enough to what getmaxx and getmaxy are used for.
|
|
|
|
(0024347)
|
|
Craig Scott
|
|
2010-12-31 19:20
|
|
|
Ignore the frm_driver.c.patch and frm_post.c.patch attachments - they don't do anything. I'll attach updated patches for these shortly (it would seem I can't delete attachments, so I'll have to rename the new patch files). |
|
|
|
(0024348)
|
|
Craig Scott
|
2010-12-31 19:26
(edited on: 2010-12-31 19:42) |
|
The frm_*.c.patch.2 files replace the getmaxx() and getmaxy() calls with reimplementations in terms of getmaxyx(), since getmaxyx() has been part of the LSB spec since 1.3. These changes eliminate link errors that result from getmaxx() and getmaxy() being undefined.
The patch for frm_driver.c also reimplements a call to getattrs(), since getattrs() is also not in the LSB. The change uses wattr_get() and wattr_set() which should result in equivalent behaviour, but someone more familiar with the CMake code will need to verify this.
|
|
|
|
(0024349)
|
|
Craig Scott
|
|
2010-12-31 21:37
|
|
The cmlibarchive.patches attachment allows ccmake and cmake-gui to link when performing an LSB build. The way this was done was to take the makedev(), major() and minor() macros that are defined in sys/sysmacros.h and inline them (with appropriate #ifdef's so that they only get pulled in for LSB builds). Again, someone more familiar with the CMake code should verify that behaviour remains unchanged with these patches. My main area of concern is whether the macros have equivalent implementations on other LSB platforms, as I've only been able to check x86 and x86_64.
Note also that I've asked the LSB mailing list whether makedev() and friends can be included in the LSB spec, since they appear to be very well supported by all major linux distributions. |
|
|
|
(0024350)
|
|
Craig Scott
|
|
2011-01-01 00:12
|
|
For extra info, the motivation for wanting to build CMake with LSB 4.0 compilers is related to getting the latest Qt sources building with LSB 4.0. Details (with patches) can be found here (feel free to vote for it so it gets more attention!):
http://bugreports.qt.nokia.com/browse/QTBUG-16385 [^]
Combining the patches found there and the patches attached to this CMake bug report has yielded a successful LSB build of OpenSSL, Qt and CMake for me. |
|
|
|
(0024363)
|
|
Brad King
|
|
2011-01-03 12:23
|
|
|
|
|
(0024364)
|
|
Brad King
|
|
2011-01-03 12:23
|
|
|
|
|
(0024367)
|
|
Brad King
|
|
2011-01-03 16:26
|
|
|
The cmlibarchive.patches file changes code in our copy of the "libarchive" project. The upstream libarchive still uses major/minor/makedev. Has libarchive itself been ported to LSB? |
|
|
|
(0024378)
|
|
Craig Scott
|
|
2011-01-03 19:02
|
|
|
Is libarchive a separate project external to CMake? I wasn't aware of that. I don't have any familiarity with it beyond seeing it here with this LSB CMake issue. The changes in the libarchive patch will result in slightly different built binary, but the end behaviour should be identical to current. The patch merely inlines the implementations of major/minor/makedev functions as found on linux systems. |
|
|
|
(0024381)
|
|
Eric NOULARD
|
|
2011-01-04 02:22
|
|
|
|
|
(0024382)
|
|
Craig Scott
|
|
2011-01-04 03:50
|
|
Okay, I've reported this in the cmlibarchive bug tracker:
http://code.google.com/p/libarchive/issues/detail?id=125 [^]
It looks like they have partially addressed the problem, but not sufficiently. They have already inlined the implementations for major, minor and makedev, but their top level CMakeLists.txt file allows non-LSB headers to be checked when looking for mkdev.h and sysmacros.h. |
|
|
|
(0024383)
|
|
Brad King
|
2011-01-04 08:48
(edited on: 2011-01-04 09:09) |
|
It looks like the attr interface you used does not work in other curses versions. Our nightly builds barfed on it:
QNX:
frm_driver.c:878:49: error: macro "wattr_get" passed 4 arguments, but takes just 1
Sun:
"frm_driver.c", line 858: undefined symbol: attr_t The identifier "attr_t" is undefined.
SGI:
attr_t fwinAttrs;
^
1 error detected in the compilation of "frm_driver.c".
|
|
|
|
(0024386)
|
|
Brad King
|
|
2011-01-04 08:54
|
|
|
|
|
(0024387)
|
|
Brad King
|
|
2011-01-04 08:55
|
|
|
|
|
(0024417)
|
|
Brad King
|
|
2011-01-05 11:01
|
|
HP:
ld: Unsatisfied symbol "getmaxyx" in file libcmForm.a[frm_post.o]
Why is it that interfaces like getattrs and getmax[xy] are available on every ancient unix system and have worked in CMake for 10 years on all our supported platforms but are not part of a modern Linux? |
|
|
|
(0024424)
|
|
Brad King
|
|
2011-01-05 11:12
|
|
|
|
|
(0024443)
|
|
Craig Scott
|
|
2011-01-05 17:19
|
|
|
|
|
(0024630)
|
|
Brad King
|
|
2011-01-12 13:57
|
|
|
|
|
(0024670)
|
|
Craig Scott
|
|
2011-01-13 17:05
|
|
|
Yep, that change works for me with the LSB compilers. |
|
|
|
(0024675)
|
|
Brad King
|
|
2011-01-14 08:56
|
|
|
|
|
(0024849)
|
|
Brad King
|
|
2011-01-18 07:29
|
|
|
I'm closing this issue since CMake now builds with the LSB tools. However, as mentioned in 0011648:0024675 there is no guarantee this will continue to be the case unless someone contributes a nightly build to our dashboard. |
|
|
|
(0024896)
|
|
Craig Scott
|
|
2011-01-18 16:19
|
|
|
Sorry, it would appear that I have to re-open the bug to add another comment. I'm intending to set up 32-bit and 64-bit LSB 4.0 builds and have them submit to the nightly dashboard. It may take a few weeks for me to get this in place while I deal with some other priorities. |
|
|
|
(0024897)
|
|
Brad King
|
|
2011-01-18 16:25
|
|
|
|
|
(0025306)
|
|
Craig Scott
|
|
2011-02-06 23:46
|
|
Looks like the libarchive code might have been updated from upstream. I'm in the process of setting up the dashboard for LSB 4.0 (32- and 64-bit) and I'm seeing similar errors to before but in a different file (included below). For reference, the dashboards are for SLED11-i686 and SLED11-x86-64. Both have LSB4.0 in the build name. Error output from a typical failure follows:
Linking CXX executable ../bin/cmake
../Utilities/cmlibarchive/libarchive/libcmlibarchive.a(archive_entry.c.o): In function `archive_entry_dev':
/PkgBuild/Tools/CMake-Nightly/My Tests/CMake/Utilities/cmlibarchive/libarchive/archive_entry.c:511: undefined reference to `makedev'
../Utilities/cmlibarchive/libarchive/libcmlibarchive.a(archive_entry.c.o): In function `archive_entry_devmajor':
/PkgBuild/Tools/CMake-Nightly/My Tests/CMake/Utilities/cmlibarchive/libarchive/archive_entry.c:523: undefined reference to `major'
../Utilities/cmlibarchive/libarchive/libcmlibarchive.a(archive_entry.c.o): In function `archive_entry_devminor':
/PkgBuild/Tools/CMake-Nightly/My Tests/CMake/Utilities/cmlibarchive/libarchive/archive_entry.c:532: undefined reference to `minor'
../Utilities/cmlibarchive/libarchive/libcmlibarchive.a(archive_entry.c.o): In function `archive_entry_rdev':
/PkgBuild/Tools/CMake-Nightly/My Tests/CMake/Utilities/cmlibarchive/libarchive/archive_entry.c:673: undefined reference to `makedev'
../Utilities/cmlibarchive/libarchive/libcmlibarchive.a(archive_entry.c.o): In function `archive_entry_rdevmajor':
/PkgBuild/Tools/CMake-Nightly/My Tests/CMake/Utilities/cmlibarchive/libarchive/archive_entry.c:685: undefined reference to `major'
../Utilities/cmlibarchive/libarchive/libcmlibarchive.a(archive_entry.c.o): In function `archive_entry_rdevminor':
/PkgBuild/Tools/CMake-Nightly/My Tests/CMake/Utilities/cmlibarchive/libarchive/archive_entry.c:694: undefined reference to `minor'
collect2: ld returned 1 exit status |
|
|
|
(0025310)
|
|
Brad King
|
|
2011-02-07 09:00
|
|
0011648:0025306: Thanks for setting up the dashboard build!
It looks like CMake's archive_entry.c has not been updated with the same change from upstream that defines the makedev/major/minor macros locally if they are not available. I'll port the change. |
|
|
|
(0025311)
|
|
Brad King
|
|
2011-02-07 10:11
|
|
|
SystemInformation.cxx.patch (469) 2010-12-31 06:54
frm_driver.c.patch.2 (1,419) 2010-12-31 19:20