(0024343)
Craig Scott (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
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 (manager)
2011-01-03 12:23

For reference:

http://en.wikipedia.org/wiki/Linux_Standard_Base [^]
http://wiki.debian.org/DebianLsb [^]

(0024364)
Brad King (manager)
2011-01-03 12:23

Thanks for the patches.

SystemInformation fix:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a67fd726 [^]

Curses fix:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7d691cab [^]

(0024367)
Brad King (manager)
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 (reporter)
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 (developer)
2011-01-04 02:22

Yes libarchive is an external project initially made for FreeBSD
http://code.google.com/p/libarchive/ [^]

I don't really know how many projects are using it.
There is an official debian package for it:
http://packages.debian.org/source/squeeze/libarchive [^]

And you can find many RPM for RPM based distro too.

(0024382)
Craig Scott (reporter)
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 (manager)
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 (manager)
2011-01-04 08:54

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a3de30ee [^]

(0024387)
Brad King (manager)
2011-01-04 08:55

> http://code.google.com/p/libarchive/issues/detail?id=125 [^]

FYI, the project is called "libarchive". The name "cmlibarchive" is in our source to distinguish it from the upstream version.

(0024417)
Brad King (manager)
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 (manager)
2011-01-05 11:12

I'm now treating these changes as a workaround for missing entries in the LSB specification:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dde0c89c [^]

(0024443)
Craig Scott (reporter)
2011-01-05 17:19

"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?"

See response to this on the lsb-discuss mailing list:

https://lists.linux-foundation.org/pipermail/lsb-discuss/2011-January/006616.html [^]

(0024630)
Brad King (manager)
2011-01-12 13:57

Based on the upstream libarchive change I've made this change:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cf5ad183 [^]

With this, does CMake now build on LSB 4.0?

(0024670)
Craig Scott (reporter)
2011-01-13 17:05

Yep, that change works for me with the LSB compilers.

(0024675)
Brad King (manager)
2011-01-14 08:56

Great. Our policy for maintaining support for a given platform is that someone must contribute a nightly build to our dashboard:

  http://www.cdash.org/CDash/index.php?project=CMake [^]

Only platforms with submissions here can be known to continue working in the future.

Please see instructions here to set one up:

  http://www.cmake.org/Wiki/CMake/Git#Dashboard [^]
  http://cmake.org/gitweb?p=cmake.git;a=blob;f=cmake_common.cmake;hb=dashboard [^]

(0024849)
Brad King (manager)
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 (reporter)
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 (manager)
2011-01-18 16:25

Great, thanks.

(0025306)
Craig Scott (reporter)
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 (manager)
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 (manager)
2011-02-07 10:11

This commit ports the change from upstream libarchive:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=41b7b3ef [^]

Now that a nightly dashboard is being submitted we can keep watch on its status.

Notes
(0024343) Craig Scott (reporter) 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 (reporter) 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 (reporter) 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 (reporter) 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 (reporter) 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 (reporter) 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 (manager) 2011-01-03 12:23	For reference: http://en.wikipedia.org/wiki/Linux_Standard_Base [^] http://wiki.debian.org/DebianLsb [^]

(0024364) Brad King (manager) 2011-01-03 12:23	Thanks for the patches. SystemInformation fix: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a67fd726 [^] Curses fix: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7d691cab [^]

(0024367) Brad King (manager) 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 (reporter) 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 (developer) 2011-01-04 02:22	Yes libarchive is an external project initially made for FreeBSD http://code.google.com/p/libarchive/ [^] I don't really know how many projects are using it. There is an official debian package for it: http://packages.debian.org/source/squeeze/libarchive [^] And you can find many RPM for RPM based distro too.

(0024382) Craig Scott (reporter) 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 (manager) 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 (manager) 2011-01-04 08:54	http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a3de30ee [^]

(0024387) Brad King (manager) 2011-01-04 08:55	> http://code.google.com/p/libarchive/issues/detail?id=125 [^] FYI, the project is called "libarchive". The name "cmlibarchive" is in our source to distinguish it from the upstream version.

(0024417) Brad King (manager) 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 (manager) 2011-01-05 11:12	I'm now treating these changes as a workaround for missing entries in the LSB specification: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dde0c89c [^]

(0024443) Craig Scott (reporter) 2011-01-05 17:19	"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?" See response to this on the lsb-discuss mailing list: https://lists.linux-foundation.org/pipermail/lsb-discuss/2011-January/006616.html [^]

(0024630) Brad King (manager) 2011-01-12 13:57	Based on the upstream libarchive change I've made this change: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cf5ad183 [^] With this, does CMake now build on LSB 4.0?

(0024670) Craig Scott (reporter) 2011-01-13 17:05	Yep, that change works for me with the LSB compilers.

(0024675) Brad King (manager) 2011-01-14 08:56	Great. Our policy for maintaining support for a given platform is that someone must contribute a nightly build to our dashboard: http://www.cdash.org/CDash/index.php?project=CMake [^] Only platforms with submissions here can be known to continue working in the future. Please see instructions here to set one up: http://www.cmake.org/Wiki/CMake/Git#Dashboard [^] http://cmake.org/gitweb?p=cmake.git;a=blob;f=cmake_common.cmake;hb=dashboard [^]

(0024849) Brad King (manager) 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 (reporter) 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 (manager) 2011-01-18 16:25	Great, thanks.

(0025306) Craig Scott (reporter) 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 (manager) 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 (manager) 2011-02-07 10:11	This commit ports the change from upstream libarchive: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=41b7b3ef [^] Now that a nightly dashboard is being submitted we can keep watch on its status.

Issue History
Date Modified	Username	Field	Change
2010-12-31 06:53	Craig Scott	New Issue
2010-12-31 06:54	Craig Scott	File Added: SystemInformation.cxx.patch
2010-12-31 06:55	Craig Scott	Note Added: 0024343
2010-12-31 07:06	Craig Scott	File Added: frm_driver.c.patch
2010-12-31 07:07	Craig Scott	File Added: frm_post.c.patch
2010-12-31 07:08	Craig Scott	Note Added: 0024344
2010-12-31 07:12	Craig Scott	Note Edited: 0024344
2010-12-31 19:20	Craig Scott	Note Added: 0024347
2010-12-31 19:20	Craig Scott	File Added: frm_driver.c.patch.2
2010-12-31 19:21	Craig Scott	File Added: frm_post.c.patch.2
2010-12-31 19:26	Craig Scott	Note Added: 0024348
2010-12-31 19:42	Craig Scott	Note Edited: 0024348
2010-12-31 21:33	Craig Scott	File Added: cmlibarchive.patches
2010-12-31 21:37	Craig Scott	Note Added: 0024349
2011-01-01 00:12	Craig Scott	Note Added: 0024350
2011-01-03 12:22	Brad King	Assigned To	=> Brad King
2011-01-03 12:22	Brad King	Status	new => assigned
2011-01-03 12:23	Brad King	Note Added: 0024363
2011-01-03 12:23	Brad King	Note Added: 0024364
2011-01-03 16:26	Brad King	Note Added: 0024367
2011-01-03 19:02	Craig Scott	Note Added: 0024378
2011-01-04 02:22	Eric NOULARD	Note Added: 0024381
2011-01-04 03:50	Craig Scott	Note Added: 0024382
2011-01-04 08:48	Brad King	Note Added: 0024383
2011-01-04 08:54	Brad King	Note Added: 0024386
2011-01-04 08:55	Brad King	Note Added: 0024387
2011-01-04 09:09	Brad King	Note Edited: 0024383
2011-01-05 11:01	Brad King	Note Added: 0024417
2011-01-05 11:12	Brad King	Note Added: 0024424
2011-01-05 17:19	Craig Scott	Note Added: 0024443
2011-01-12 13:57	Brad King	Note Added: 0024630
2011-01-13 17:05	Craig Scott	Note Added: 0024670
2011-01-14 08:56	Brad King	Note Added: 0024675
2011-01-18 07:29	Brad King	Note Added: 0024849
2011-01-18 07:29	Brad King	Status	assigned => closed
2011-01-18 07:29	Brad King	Resolution	open => fixed
2011-01-18 16:19	Craig Scott	Note Added: 0024896
2011-01-18 16:19	Craig Scott	Status	closed => feedback
2011-01-18 16:19	Craig Scott	Resolution	fixed => reopened
2011-01-18 16:25	Brad King	Note Added: 0024897
2011-01-18 16:25	Brad King	Status	feedback => closed
2011-01-18 16:25	Brad King	Resolution	reopened => fixed
2011-01-31 16:04	David Cole	Fixed in Version	=> CMake 2.8.4
2011-01-31 16:04	David Cole	Target Version	=> CMake 2.8.4
2011-02-06 23:46	Craig Scott	Note Added: 0025306
2011-02-06 23:46	Craig Scott	Status	closed => feedback
2011-02-06 23:46	Craig Scott	Resolution	fixed => reopened
2011-02-07 09:00	Brad King	Note Added: 0025310
2011-02-07 10:11	Brad King	Note Added: 0025311
2011-02-07 10:11	Brad King	Status	feedback => closed
2011-02-07 10:11	Brad King	Resolution	reopened => fixed
2011-02-07 10:11	Brad King	Fixed in Version	CMake 2.8.4 =>
2011-02-08 14:09	Brad King	Relationship added	related to 0011815