(0020151)
Bill Hoffman (manager)
2010-04-13 08:37

Would you be able to run a Tru64 nightly dashboard if I helped you get this working? CMake used to support this platform, but the dashboard stopped running and at some point support was broken. I don't like spending time on something that will not be tested.

(0020159)
Daniel Richard G. (reporter)
2010-04-13 14:16

I think that can be arranged, provided that it runs as a pull-only process (i.e. no firewall reconfiguration). How would I go about setting this up?

(0020160)
Bill Hoffman (manager)
2010-04-13 14:31

First you have to pull this:

http://www.cmake.org/Wiki/CMake/Git#Dashboard [^]

Then look at the instructions in cmake_common.cmake.

See if you can submit an experimental dashboard with that script.

Just add this to your my_dashboard.cmake file:

set(dashboard_model Experimental)

(0020165)
Daniel Richard G. (reporter)
2010-04-13 15:06

Okay, I think I've got all that ready... except for the actual ctest binary to run it on Tru64 :-]

(0020167)
Bill Hoffman (manager)
2010-04-13 15:11

That would be a problem... :)

OK, lets try adding a destructor for cmOStringStream, since the compiler generated one seems to be duplicated....

Add an inline one into cmStadardIncludes.h, in the fork of the #ifdef that is being used.

(0020171)
Daniel Richard G. (reporter)
2010-04-13 16:48

My C++ is a little rusty, but I think I got this right; I tried with this:

// Define cmOStringStream and cmIStringStream wrappers to hide
// differences between std::stringstream and the old strstream.
#if !defined(CMAKE_NO_ANSI_STRING_STREAM)
class cmOStringStream: public std::ostringstream
{
public:
  cmOStringStream() {}
  ~cmOStringStream() {} // newly added destructor
private:
  cmOStringStream(const cmOStringStream&);
  void operator=(const cmOStringStream&);
};

Unfortunately, still the same link errors :-(

Incidentally, if you look at nm(1) output on a couple of the object files...

> nm -P cmCommandArgumentParserHelper.o | grep OString
$_ZN15cmOStringStreamD0Ev..ng N 0x00000000000000 0x00000000000000
$_ZN15cmOStringStreamD1Ev..ng N 0x00000000000000 0x00000000000000
$_ZTv0_n24_N15cmOStringStreamD0Ev..ng N 0x00000000000000 0x00000000000000
$_ZTv0_n24_N15cmOStringStreamD1Ev..ng N 0x00000000000000 0x00000000000000
_ZN15cmOStringStreamD0Ev T 0x00000000000fa0 0x00000000000008
_ZN15cmOStringStreamD1Ev T 0x00000000000900 0x00000000000008
_ZTC15cmOStringStream0_So R 0x00000000003810 0x00000000000000
_ZTC15cmOStringStream0_St19basic_ostringstreamIcSt11char_traitsIcESaIcEE R 0x000000000037c0 0x00000000000000
_ZTI15cmOStringStream R 0x00000000003860 0x00000000000000
_ZTS15cmOStringStream R 0x00000000003878 0x00000000000000
_ZTT15cmOStringStream R 0x00000000003740 0x00000000000000
_ZTV15cmOStringStream R 0x00000000003770 0x00000000000000
_ZTv0_n24_N15cmOStringStreamD0Ev T 0x00000000000f80 0x00000000000008
_ZTv0_n24_N15cmOStringStreamD1Ev T 0x000000000008e0 0x00000000000008

> nm -P cmDepends.o | grep OString
$_ZN15cmOStringStreamC1Ev..ng N 0x00000000000000 0x00000000000000
$_ZN15cmOStringStreamD0Ev..ng N 0x00000000000000 0x00000000000000
$_ZN15cmOStringStreamD1Ev..ng N 0x00000000000000 0x00000000000000
$_ZTv0_n24_N15cmOStringStreamD0Ev..ng N 0x00000000000000 0x00000000000000
$_ZTv0_n24_N15cmOStringStreamD1Ev..ng N 0x00000000000000 0x00000000000000
_ZN15cmOStringStreamC1Ev T 0x00000000000620 0x00000000000008
_ZN15cmOStringStreamD0Ev T 0x00000000002920 0x00000000000008
_ZN15cmOStringStreamD1Ev T 0x00000000002a70 0x00000000000008
_ZTC15cmOStringStream0_So R 0x00000000005e68 0x00000000000000
_ZTC15cmOStringStream0_St19basic_ostringstreamIcSt11char_traitsIcESaIcEE R 0x00000000005e18 0x00000000000000
_ZTI15cmOStringStream R 0x00000000005eb8 0x00000000000000
_ZTS15cmOStringStream R 0x00000000005ed0 0x00000000000000
_ZTT15cmOStringStream R 0x00000000005d98 0x00000000000000
_ZTV15cmOStringStream R 0x00000000005dc8 0x00000000000000
_ZTv0_n24_N15cmOStringStreamD0Ev T 0x00000000002900 0x00000000000008
_ZTv0_n24_N15cmOStringStreamD1Ev T 0x00000000002a50 0x00000000000008

...do you see anything amiss in "_ZN15cmOStringStreamD0Ev" and "_ZN15cmOStringStreamD1Ev" (the destructors, I'm guessing... this is g++-built code, so no demangling from /usr/bin/nm) being defined in each?

(0020173)
Bill Hoffman (manager)
2010-04-13 17:42

You can pipe the output of nm into c++filt.

What version of gcc are you using to build with?

(0020175)
Daniel Richard G. (reporter)
2010-04-13 17:50

Ah, yes, thanks for reminding me of that. "virtual thunk to cmOStringStream::~cmOStringStream()" ... if I still remembered my compiler theory, I'd know what the heck that means.

Anyway, I'm building with GCC 4.4.2, on both the C and C++ side. (The vendor C compiler is available to me, but I don't have one for C++.)

(0020176)
Brad King (manager)
2010-04-13 17:52

IIRC gcc puts the vtable (and method thunks) symbol in the object file that contains the implementation of the first non-virtual method of a class. When the implementation is fully inline this ends up in all object files, but normally as a weak symbol.

Let's try making sure the first non-virtual method is implemented in only one object file. Try taking out the inline implementation of the constructor:

class cmOStringStream: public std::ostringstream
{
public:
  cmOStringStream(); // no inline impl
  // no destructor
private:
  cmOStringStream(const cmOStringStream&);
  void operator=(const cmOStringStream&);
};

and add a new source file to define it:

// cmStandardIncludes.cxx
#include "cmStadardIncludes.h"
#if !defined(CMAKE_NO_ANSI_STRING_STREAM)
cmOStringStream::cmOStringStream() {}
#endif

(0020178)
Daniel Richard G. (reporter)
2010-04-13 20:25

Doing things that way, I still get the link errors as before. But when I do the same thing with the destructor (declare it in the header, define it in the .cxx file), the link succeeds.

(I wonder if this is related to http://gcc.gnu.org/ml/gcc/2009-01/msg00043.html [^] ...)

(0020180)
Bill Hoffman (manager)
2010-04-14 11:25

OK, so with a the destructor in the .h and a .cxx it works? Can you build CMake now?

(0020181)
Daniel Richard G. (reporter)
2010-04-14 13:10

Yes, with that change, plus the workaround for usleep(), everything builds. Now I'm trying to build Git on Tru64....

(0020183)
Bill Hoffman (manager)
2010-04-14 14:45

Can you send me a diff patch with the changes you made? Also, can you try submitting a dashboard? You can also use cvs to submit the dashbaord if you do not have a git client on Tru64.

(0020187)
Daniel Richard G. (reporter)
2010-04-14 17:21

I've attached the patch. The changes to SystemTools.cxx are, of course, not intended to be general. (I think the select() fallback for usleep() is going to be needed in any event.)

(0020221)
Daniel Richard G. (reporter)
2010-04-16 12:04

I managed to build git, and have the dashboard up and running. If it's not too big a deal, I'll set it up to build using the Tru64 C compiler (with g++, since I don't have the native C++ compiler). This will be a bit more strict, but will get the code to a better place portability-wise.

This should run nightly, then? Once everything is building, would it be okay to run it only on weekends?

(0020223)
Bill Hoffman (manager)
2010-04-16 12:40

Nightly would be best if possible. That way we get feedback sooner when we break things, and it is easier to figure out how to fix it.

Looks like it fails to configure:

http://www.cdash.org/CDash/viewConfigure.php?buildid=587437 [^]

(0020225)
Daniel Richard G. (reporter)
2010-04-16 13:22

That is due to an unusual quirk of the system make(1) in how include paths are resolved. I'll file a bug on that shortly.

(0020229)
Bill Hoffman (manager)
2010-04-16 15:37

Can you use gmake for the dashboard?

(0020234)
Daniel Richard G. (reporter)
2010-04-16 16:03

Yes, of course. (I have a dashboard running right now with gmake.)

I'll switch it back to the native make(1) once a new CMake release, sans bug 0010569, comes out.

(0020983)
Brad King (manager)
2010-06-10 15:28

I've applied the patch (except for the Source/kwsys/SystemTools.cxx hunk which is not related to cmOStringStream) and pushed to 'next':

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

(0020987)
Daniel Richard G. (reporter)
2010-06-10 17:38
edited on: 2010-06-11 10:08

Sorry to trouble you for this, but I'm still new to Git, and my branch-fu is yet rudimentary. What clones and merges should I do to get a tree with this fix and the one for 0010569?

(0020989)
Brad King (manager)
2010-06-11 10:10

$ git clone git://cmake.org/cmake.git [^] CMake
$ cd CMake
$ git checkout -b try-tru64-fixes origin/next
$ git pull git://gitorious.org/~bradking/cmake/bradkings-cmake.git [^] tru64-make-includes

(0041681)
Kitware Robot (administrator)
2016-06-10 14:27

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Notes
(0020151) Bill Hoffman (manager) 2010-04-13 08:37	Would you be able to run a Tru64 nightly dashboard if I helped you get this working? CMake used to support this platform, but the dashboard stopped running and at some point support was broken. I don't like spending time on something that will not be tested.

(0020159) Daniel Richard G. (reporter) 2010-04-13 14:16	I think that can be arranged, provided that it runs as a pull-only process (i.e. no firewall reconfiguration). How would I go about setting this up?

(0020160) Bill Hoffman (manager) 2010-04-13 14:31	First you have to pull this: http://www.cmake.org/Wiki/CMake/Git#Dashboard [^] Then look at the instructions in cmake_common.cmake. See if you can submit an experimental dashboard with that script. Just add this to your my_dashboard.cmake file: set(dashboard_model Experimental)

(0020165) Daniel Richard G. (reporter) 2010-04-13 15:06	Okay, I think I've got all that ready... except for the actual ctest binary to run it on Tru64 :-]

(0020167) Bill Hoffman (manager) 2010-04-13 15:11	That would be a problem... :) OK, lets try adding a destructor for cmOStringStream, since the compiler generated one seems to be duplicated.... Add an inline one into cmStadardIncludes.h, in the fork of the #ifdef that is being used.

(0020171) Daniel Richard G. (reporter) 2010-04-13 16:48	My C++ is a little rusty, but I think I got this right; I tried with this: // Define cmOStringStream and cmIStringStream wrappers to hide // differences between std::stringstream and the old strstream. #if !defined(CMAKE_NO_ANSI_STRING_STREAM) class cmOStringStream: public std::ostringstream { public: cmOStringStream() {} ~cmOStringStream() {} // newly added destructor private: cmOStringStream(const cmOStringStream&); void operator=(const cmOStringStream&); }; Unfortunately, still the same link errors :-( Incidentally, if you look at nm(1) output on a couple of the object files... > nm -P cmCommandArgumentParserHelper.o \| grep OString $_ZN15cmOStringStreamD0Ev..ng N 0x00000000000000 0x00000000000000 $_ZN15cmOStringStreamD1Ev..ng N 0x00000000000000 0x00000000000000 $_ZTv0_n24_N15cmOStringStreamD0Ev..ng N 0x00000000000000 0x00000000000000 $_ZTv0_n24_N15cmOStringStreamD1Ev..ng N 0x00000000000000 0x00000000000000 _ZN15cmOStringStreamD0Ev T 0x00000000000fa0 0x00000000000008 _ZN15cmOStringStreamD1Ev T 0x00000000000900 0x00000000000008 _ZTC15cmOStringStream0_So R 0x00000000003810 0x00000000000000 _ZTC15cmOStringStream0_St19basic_ostringstreamIcSt11char_traitsIcESaIcEE R 0x000000000037c0 0x00000000000000 _ZTI15cmOStringStream R 0x00000000003860 0x00000000000000 _ZTS15cmOStringStream R 0x00000000003878 0x00000000000000 _ZTT15cmOStringStream R 0x00000000003740 0x00000000000000 _ZTV15cmOStringStream R 0x00000000003770 0x00000000000000 _ZTv0_n24_N15cmOStringStreamD0Ev T 0x00000000000f80 0x00000000000008 _ZTv0_n24_N15cmOStringStreamD1Ev T 0x000000000008e0 0x00000000000008 > nm -P cmDepends.o \| grep OString $_ZN15cmOStringStreamC1Ev..ng N 0x00000000000000 0x00000000000000 $_ZN15cmOStringStreamD0Ev..ng N 0x00000000000000 0x00000000000000 $_ZN15cmOStringStreamD1Ev..ng N 0x00000000000000 0x00000000000000 $_ZTv0_n24_N15cmOStringStreamD0Ev..ng N 0x00000000000000 0x00000000000000 $_ZTv0_n24_N15cmOStringStreamD1Ev..ng N 0x00000000000000 0x00000000000000 _ZN15cmOStringStreamC1Ev T 0x00000000000620 0x00000000000008 _ZN15cmOStringStreamD0Ev T 0x00000000002920 0x00000000000008 _ZN15cmOStringStreamD1Ev T 0x00000000002a70 0x00000000000008 _ZTC15cmOStringStream0_So R 0x00000000005e68 0x00000000000000 _ZTC15cmOStringStream0_St19basic_ostringstreamIcSt11char_traitsIcESaIcEE R 0x00000000005e18 0x00000000000000 _ZTI15cmOStringStream R 0x00000000005eb8 0x00000000000000 _ZTS15cmOStringStream R 0x00000000005ed0 0x00000000000000 _ZTT15cmOStringStream R 0x00000000005d98 0x00000000000000 _ZTV15cmOStringStream R 0x00000000005dc8 0x00000000000000 _ZTv0_n24_N15cmOStringStreamD0Ev T 0x00000000002900 0x00000000000008 _ZTv0_n24_N15cmOStringStreamD1Ev T 0x00000000002a50 0x00000000000008 ...do you see anything amiss in "_ZN15cmOStringStreamD0Ev" and "_ZN15cmOStringStreamD1Ev" (the destructors, I'm guessing... this is g++-built code, so no demangling from /usr/bin/nm) being defined in each?

(0020173) Bill Hoffman (manager) 2010-04-13 17:42	You can pipe the output of nm into c++filt. What version of gcc are you using to build with?

(0020175) Daniel Richard G. (reporter) 2010-04-13 17:50	Ah, yes, thanks for reminding me of that. "virtual thunk to cmOStringStream::~cmOStringStream()" ... if I still remembered my compiler theory, I'd know what the heck that means. Anyway, I'm building with GCC 4.4.2, on both the C and C++ side. (The vendor C compiler is available to me, but I don't have one for C++.)

(0020176) Brad King (manager) 2010-04-13 17:52	IIRC gcc puts the vtable (and method thunks) symbol in the object file that contains the implementation of the first non-virtual method of a class. When the implementation is fully inline this ends up in all object files, but normally as a weak symbol. Let's try making sure the first non-virtual method is implemented in only one object file. Try taking out the inline implementation of the constructor: class cmOStringStream: public std::ostringstream { public: cmOStringStream(); // no inline impl // no destructor private: cmOStringStream(const cmOStringStream&); void operator=(const cmOStringStream&); }; and add a new source file to define it: // cmStandardIncludes.cxx #include "cmStadardIncludes.h" #if !defined(CMAKE_NO_ANSI_STRING_STREAM) cmOStringStream::cmOStringStream() {} #endif

(0020178) Daniel Richard G. (reporter) 2010-04-13 20:25	Doing things that way, I still get the link errors as before. But when I do the same thing with the destructor (declare it in the header, define it in the .cxx file), the link succeeds. (I wonder if this is related to http://gcc.gnu.org/ml/gcc/2009-01/msg00043.html [^] ...)

(0020180) Bill Hoffman (manager) 2010-04-14 11:25	OK, so with a the destructor in the .h and a .cxx it works? Can you build CMake now?

(0020181) Daniel Richard G. (reporter) 2010-04-14 13:10	Yes, with that change, plus the workaround for usleep(), everything builds. Now I'm trying to build Git on Tru64....

(0020183) Bill Hoffman (manager) 2010-04-14 14:45	Can you send me a diff patch with the changes you made? Also, can you try submitting a dashboard? You can also use cvs to submit the dashbaord if you do not have a git client on Tru64.

(0020187) Daniel Richard G. (reporter) 2010-04-14 17:21	I've attached the patch. The changes to SystemTools.cxx are, of course, not intended to be general. (I think the select() fallback for usleep() is going to be needed in any event.)

(0020221) Daniel Richard G. (reporter) 2010-04-16 12:04	I managed to build git, and have the dashboard up and running. If it's not too big a deal, I'll set it up to build using the Tru64 C compiler (with g++, since I don't have the native C++ compiler). This will be a bit more strict, but will get the code to a better place portability-wise. This should run nightly, then? Once everything is building, would it be okay to run it only on weekends?

(0020223) Bill Hoffman (manager) 2010-04-16 12:40	Nightly would be best if possible. That way we get feedback sooner when we break things, and it is easier to figure out how to fix it. Looks like it fails to configure: http://www.cdash.org/CDash/viewConfigure.php?buildid=587437 [^]

(0020225) Daniel Richard G. (reporter) 2010-04-16 13:22	That is due to an unusual quirk of the system make(1) in how include paths are resolved. I'll file a bug on that shortly.

(0020229) Bill Hoffman (manager) 2010-04-16 15:37	Can you use gmake for the dashboard?

(0020234) Daniel Richard G. (reporter) 2010-04-16 16:03	Yes, of course. (I have a dashboard running right now with gmake.) I'll switch it back to the native make(1) once a new CMake release, sans bug 0010569, comes out.

(0020983) Brad King (manager) 2010-06-10 15:28	I've applied the patch (except for the Source/kwsys/SystemTools.cxx hunk which is not related to cmOStringStream) and pushed to 'next': http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f20d091a [^] http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bf445ae6 [^]

(0020987) Daniel Richard G. (reporter) 2010-06-10 17:38 edited on: 2010-06-11 10:08	Sorry to trouble you for this, but I'm still new to Git, and my branch-fu is yet rudimentary. What clones and merges should I do to get a tree with this fix and the one for 0010569?

(0020989) Brad King (manager) 2010-06-11 10:10	$ git clone git://cmake.org/cmake.git [^] CMake $ cd CMake $ git checkout -b try-tru64-fixes origin/next $ git pull git://gitorious.org/~bradking/cmake/bradkings-cmake.git [^] tru64-make-includes

(0041681) Kitware Robot (administrator) 2016-06-10 14:27	Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Issue History
Date Modified	Username	Field	Change
2010-04-12 19:52	Daniel Richard G.	New Issue
2010-04-13 08:37	Bill Hoffman	Note Added: 0020151
2010-04-13 08:37	Bill Hoffman	Status	new => assigned
2010-04-13 08:37	Bill Hoffman	Assigned To	=> Bill Hoffman
2010-04-13 08:38	Bill Hoffman	Relationship added	has duplicate 0010542
2010-04-13 14:16	Daniel Richard G.	Note Added: 0020159
2010-04-13 14:31	Bill Hoffman	Note Added: 0020160
2010-04-13 15:06	Daniel Richard G.	Note Added: 0020165
2010-04-13 15:11	Bill Hoffman	Note Added: 0020167
2010-04-13 16:48	Daniel Richard G.	Note Added: 0020171
2010-04-13 17:42	Bill Hoffman	Note Added: 0020173
2010-04-13 17:50	Daniel Richard G.	Note Added: 0020175
2010-04-13 17:52	Brad King	Note Added: 0020176
2010-04-13 20:25	Daniel Richard G.	Note Added: 0020178
2010-04-14 11:25	Bill Hoffman	Note Added: 0020180
2010-04-14 13:10	Daniel Richard G.	Note Added: 0020181
2010-04-14 14:45	Bill Hoffman	Note Added: 0020183
2010-04-14 17:19	Daniel Richard G.	File Added: cmake-2.8.1-tru64-fixes.patch
2010-04-14 17:21	Daniel Richard G.	Note Added: 0020187
2010-04-16 12:04	Daniel Richard G.	Note Added: 0020221
2010-04-16 12:40	Bill Hoffman	Note Added: 0020223
2010-04-16 13:22	Daniel Richard G.	Note Added: 0020225
2010-04-16 15:37	Bill Hoffman	Note Added: 0020229
2010-04-16 16:03	Daniel Richard G.	Note Added: 0020234
2010-06-10 15:28	Brad King	Note Added: 0020983
2010-06-10 17:38	Daniel Richard G.	Note Added: 0020987
2010-06-11 10:08	Brad King	Note Edited: 0020987
2010-06-11 10:10	Brad King	Note Added: 0020989
2016-06-10 14:27	Kitware Robot	Note Added: 0041681
2016-06-10 14:27	Kitware Robot	Status	assigned => resolved
2016-06-10 14:27	Kitware Robot	Resolution	open => moved
2016-06-10 14:31	Kitware Robot	Status	resolved => closed