|
Notes |
|
|
(0020152)
|
|
Bill Hoffman
|
|
2010-04-13 08:39
|
|
This is quite a list of options: +w2 +w -i -misalign -mt -xarch=v9 -xcrossfile -xO5
Does CMake build with the default options? Can you run a dashboard? |
|
|
|
(0020157)
|
|
Daniel Richard G.
|
|
2010-04-13 14:10
|
|
The build gets farther if you drop -xcrossfile. Multiply-defined symbols, however, are a bug in and of themselves---like accidentally putting "int i;" in a header file instead of "extern int i;" (GCC will tolerate this unless you specify -fno-common).
Is that the case here, or do you suspect this is just a compiler artifact? |
|
|
|
(0020161)
|
|
Bill Hoffman
|
|
2010-04-13 14:33
|
|
|
I don't think we have any of those types of bugs. We build with lots more than gcc. See here:http://www.cdash.org/CDash/index.php?project=CMake [^] We even build with solaris compilers. You must be using a newer/different one. Those look like template instantiation issues with STL that you are seeing. |
|
|
|
(0020169)
|
|
Daniel Richard G.
|
|
2010-04-13 16:09
|
|
I would characterize this compiler as an older one, but otherwise standard ("cc -V" yields "cc: Sun WorkShop 6 2000/06/19 C 5.1 Patch 109491-02")
Would it be possible to try building with -xcrossfile on your end? This is one of the extra-strength optimization options, that makes the linker stricter on what it will accept. |
|
|
|
(0020378)
|
|
Daniel Richard G.
|
|
2010-04-23 13:16
|
|
I've done some further testing on a Solaris 10 system here. 2.8.1 compiles successfully with -xcrossfile, with nary a linker warning, using the newer Sun compiler.
I'm close to chalking this up as a bug in the older compiler, but in rebuilding CMake on an HP-UX Itanium system, I noticed some interesting warnings of the form
----
Warning (suggestion) 655: "/path/to/source/file.h", line NNN # class FooBarBaz does not have any non-inline, non-pure virtual member functions. Please define at least one non-inline, non-pure virtual member function, so that the compiler knows where to emit the virtual function table. Otherwise multiple copies of the virtual function table may be emitted.
----
Here are all the source files, line numbers, and classes for which this warning was reported:
cmake-2.8.1/Source/CTest/cmCTestCommand.h:27 (cmCTestCommand)
cmake-2.8.1/Source/CursesDialog/cmCursesFilePathWidget.h:17 (cmCursesFilePathWidget)
cmake-2.8.1/Source/cmCommand.h:30 (cmCommand)
cmake-2.8.1/Source/cmCommandArgumentsHelper.h:42 (cmCommandArgument)
cmake-2.8.1/Source/cmCoreTryCompile.h:23 (cmCoreTryCompile)
cmake-2.8.1/Source/cmData.h:26 (cmData)
cmake-2.8.1/Source/cmExecutionStatus.h:22 (cmExecutionStatus)
cmake-2.8.1/Source/cmExportFileGenerator.h:25 (cmExportFileGenerator)
cmake-2.8.1/Source/cmExternalMakefileProjectGenerator.h:33 (cmExternalMakefileProjectGenerator)
cmake-2.8.1/Source/cmFindFileCommand.h:25 (cmFindFileCommand)
cmake-2.8.1/Source/cmFindPackageCommand.cxx:1599 (cmFileListGeneratorBase)
cmake-2.8.1/Source/cmFindPackageCommand.cxx:1614 (cmFileList)
cmake-2.8.1/Source/cmFindPackageCommand.cxx:1647 (cmFindPackageFileList)
cmake-2.8.1/Source/cmFindPackageCommand.cxx:1694 (cmFileListGeneratorFixed)
cmake-2.8.1/Source/cmFindPackageCommand.cxx:1716 (cmFileListGeneratorEnumerate)
cmake-2.8.1/Source/cmFindPackageCommand.cxx:1745 (cmFileListGeneratorProject)
cmake-2.8.1/Source/cmFindPackageCommand.cxx:1797 (cmFileListGeneratorMacProject)
cmake-2.8.1/Source/cmFindPackageCommand.cxx:1852 (cmFileListGeneratorCaseInsensitive)
cmake-2.8.1/Source/cmFindPackageCommand.cxx:1894 (cmFileListGeneratorGlob)
cmake-2.8.1/Source/cmFunctionBlocker.h:25 (cmFunctionBlocker)
cmake-2.8.1/Source/cmObject.h:23 (cmObject)
cmake-2.8.1/Source/cmStandardIncludes.h:240 (cmOStringStream)
cmake-2.8.1/Source/cmStandardIncludes.h:248 (cmIStringStream)
Do you suppose there's anything to this? |
|
|
|
(0020382)
|
|
Brad King
|
|
2010-04-23 17:03
|
|
The compiler is suggesting that it would be able to organize symbols in object files better if there were a non-inline, non-pure-virtual function in the class. This is because it chooses to put the vtable symbol in the one and only .o file that contains the implementation of the first non-inline, non-pure-virtual function. When no such method exists, it has no choice but to generate it in all translation units that need it.
The "suggestion" warning level seems a bit like Intel's "remark" level which gives lots of ideas. Nothing is really wrong. Multiple copies of an identical vtable are okay, especially since we always use static linking. Doing what the compiler is asking would make the code unnecessarily verbose.
What warning level/flags did you use to get that? |
|
|
|
(0020388)
|
|
Daniel Richard G.
|
|
2010-04-25 00:55
|
|
I just used the +w "more warnings" switch, with HP-UX's aCC(1).
Thanks for the explanation. I suppose it's plausible that the older Solaris linker is choking on multiple identical vtable definitions, even though this should produce warnings at most.
The intent here was not to say that there's anything wrong with CMake's code, but to see if there was an easy way for it to accommodate this quirk of Sun's older, pre-standardization C++ compiler. Not because it's necessary here (I can build CMake fine on this system if I don't use -xcrossfile) but to make the C++ code that much more friendly to non-conforming compilers. Helpful if CMake is going to run on all the platforms Autotools supports :-)
Anyway, if working around this is too much of a hassle, then feel free to close as "wont fix". Sun's 2000-vintage toolchain can still build CMake, and I don't have anything older/fussier to throw at it. |
|
|
|
(0020399)
|
|
Brad King
|
|
2010-04-26 10:38
|
|
|
Ah, so the HP warnings actually point at the exact places that cause trouble for the Sun linker? |
|
|
|
(0020400)
|
|
Daniel Richard G.
|
|
2010-04-26 12:34
|
|
|
That's only a guess, given how constructs that cause warnings on one platform sometimes cause errors on another. (I already had all warnings turned on with the Solaris compiler, using "+w2 +w", and it didn't yield anything apropos at compile time.) |
|
|
|
(0020406)
|
|
Brad King
|
|
2010-04-26 17:14
|
|
|
Please try 0001-Help-old-C-compilers-place-vtable-symbols.patch on top of CMake master (at least 6e1b51031). |
|
|
|
(0020421)
|
|
Daniel Richard G.
|
|
2010-04-26 20:15
|
|
|
Brad, I'll be very happy to do that. Since this patch is against Git/CVS, however, I'm going to need a bit of time to work through issues building libarchive. (So far, C++ comments in C code, non-disabled "inline" keywords, and a mismatched prototype... this code doesn't seem to ever have been built on Solaris before. I'm thinking an upstream patch is the way to go.) |
|
|
|
(0020425)
|
|
Bill Hoffman
|
|
2010-04-27 08:53
|
|
|
It was built with our solaris compiler, and is every night. Please send patches, libarchieve is going into the CMake release very soon. I can manage the upstream changes, but I would like to see the problems now. Can you submit an experimental dashboard with git master CMake? |
|
|
|
(0020446)
|
|
Daniel Richard G.
|
|
2010-04-27 17:05
|
|
The attached patch against libarchive SVN allows it to build on both this Solaris system, and my old Tru64 system. A walk-through of the changes is at the top. More work is needed; some of the changes are just brute-force hacks. If you could push this upstream for me, I would be very grateful.
I have the dashboard set up on Solaris (already submitted a couple times as "solaris8.teragram"). But for some reason, it fails at the configuration stage when it's looking for a 16-bit integer type, and this failure does not occur when I configure the master tree manually (using the same CMake build, and the same compiler/flags). Any idea what may be going on there? |
|
|
|
(0020447)
|
|
Brad King
|
|
2010-04-27 17:21
|
|
Try this patch in libarchive. It is one we made to CMake that never made it upstream. I think it helps with "getgrgid_r" and related functions.
diff --git a/libarchive/archive_platform.h b/libarchive/archive_platform.h
index dba530e..4d5e4f2 100644
--- a/libarchive/archive_platform.h
+++ b/libarchive/archive_platform.h
@@ -52,6 +52,13 @@
#error Oops: No config.h and no pre-built configuration in archive_platform.h.
#endif
+/* Request "Single Unix Specification" API. */
+#if defined(__hpux) || defined(__sun)
+# ifndef _XOPEN_SOURCE
+# define _XOPEN_SOURCE 500
+# endif
+#endif
+
/* It should be possible to get rid of this by extending the feature-test
* macros to cover Windows API functions, probably along with non-trivial
* refactoring of code to find structures that sit more cleanly on top of |
|
|
|
(0020448)
|
|
Daniel Richard G.
|
|
2010-04-27 17:48
|
|
Not quite so simple as that, I'm afraid...
[ 0%] Building C object libarchive/CMakeFiles/archive.dir/archive_entry_copy_stat.c.o
"/tmp/libarchive/libarchive/archive_entry_copy_stat.c", line 44: improper member use: tv_nsec
"/tmp/libarchive/libarchive/archive_entry_copy_stat.c", line 45: improper member use: tv_nsec
"/tmp/libarchive/libarchive/archive_entry_copy_stat.c", line 46: improper member use: tv_nsec
cc: acomp failed for /tmp/libarchive/libarchive/archive_entry_copy_stat.c
*** Error code 2
/usr/include/sys/stat.h has a bunch of crazy macro magic for st_atime et al., and #defining _XOPEN_SOURCE kicks up the hornets' nest :-(
There's a fair amount of examination of struct stat's time-related fields in the configuration stage (e.g. HAVE_STRUCT_STAT_ST_MTIM_TV_NSEC), and setting feature-test macros in the code sort of changes the environment from what was configured originally. This is why I've felt that feature macros should either be left to the user to mess with, or brought in early enough so that they can affect the configuration process appropriately. |
|
|
|
(0020449)
|
|
Bill Hoffman
|
|
2010-04-27 17:48
|
|
|
I just tried to remove all the // comments in CMake master, can you pull and try again? |
|
|
|
(0020450)
|
|
Brad King
|
|
2010-04-27 17:53
|
|
|
|
|
(0020455)
|
|
Daniel Richard G.
|
|
2010-04-27 20:01
|
|
Does the CVS repository reflect up-to-the-minute changes in master? I'm still seeing C++ comments in there:
/home/cport/Dashboards/My Tests/CMake/Utilities/cmlibarchive/libarchive/archive_read.c", line 1156: syntax error before or at: / |
|
|
|
(0020456)
|
|
Bill Hoffman
|
|
2010-04-27 21:29
|
|
|
Missed that one, try again, just did a new commit. |
|
|
|
(0020458)
|
|
Daniel Richard G.
|
|
2010-04-27 23:11
|
|
First off, there's one minor bit that somehow didn't find its way into my patch:
--- Utilities/cmlibarchive/libarchive/archive_read_support_compression_program.c revision 1.1
+++ Utilities/cmlibarchive/libarchive/archive_read_support_compression_program.c working copy
@@ -72,7 +72,7 @@
*/
int
archive_read_support_compression_program_signature(struct archive *_a,
- const char *cmd, void *signature, size_t signature_len)
+ const char *cmd, const void *signature, size_t signature_len)
{
(void)_a; /* UNUSED */
(void)cmd; /* UNUSED */
(This is needed to make the prototype consistent with the one at libarchive/archive.h:317, and thus the compiler happy.)
That aside, I can build more of cmlibarchive now; now it's the inline-keyword business that's the problem. |
|
|
|
(0020459)
|
|
Bill Hoffman
|
|
2010-04-27 23:38
|
|
archive_endian.h
/*
* Disabling inline keyword for compilers known to choke on it:
* - Watcom C++ in C code. (For any version?)
* - SGI MIPSpro
* - Microsoft Visual C++ 6.0 (supposedly newer versions too)
*/
#if defined(__WATCOMC__) || defined(__sgi) || defined(__hpux) || defined(__BORLANDC__)
#define inline
#elif defined(_MSC_VER)
#define inline __inline
#endif
What if you add a sun in there? That should fix it? |
|
|
|
(0020460)
|
|
Daniel Richard G.
|
|
2010-04-28 01:36
|
|
Well, yeah, but (1) it's not necessarily all Sun compilers that can't do "inline", and (2) "__sun" is also #defined when you're building with GCC. This is why I said a configure-time test is needed; you really don't want to rely on the preprocessor for this.
Otherwise, if I extend the conditional, and make that change to archive_read_support_compression_program.c (I suspect this was already fixed in libarchive SVN, which is why my big patch didn't include it), then yes, all of cmlibarchive builds.
(I don't remember now; was that the immediate goal, or building CMake master with your patch? Because now, I'm seeing the _stl_prime_list bug again. I don't want to come across as pushy, but is there anything holding you up from committing the various patch-fixes I've submitted?) |
|
|
|
(0020470)
|
|
Daniel Richard G.
|
|
2010-04-28 21:45
|
|
CMake master builds on my Solaris system, now with the following exceptions:
* Utilities/cmzlib/deflate.c: C++ comments
* Utilities/cmlibarchive/libarchive/archive_read_support_compression_program.c:76: prototype inconsistency
* Utilities/cmlibarchive/libarchive/archive_read_support_format_iso9660.c: "inline" not supported
* Utilities/cmlibarchive/libarchive/archive_read_support_format_zip.c: "inline" not supported
* Utilities/cmlibarchive/libarchive/archive_write_set_format_zip.c: "inline" not supported
(Note: This is building from an unmodified master; I took out my local changes to cmlibarchive.) |
|
|
|
(0020542)
|
|
Bill Hoffman
|
|
2010-05-04 14:54
|
|
|
OK, I have pushed those fixes to the git master, can you please try now? |
|
|
|
(0020564)
|
|
Daniel Richard G.
|
|
2010-05-04 17:31
|
|
|
Still need the fix for Utilities/cmlibarchive/libarchive/archive_read_support_compression_program.c (see comment 0020458). |
|
|
|
(0020580)
|
|
Bill Hoffman
|
|
2010-05-05 09:38
|
|
|
OK, that should be fixed now. |
|
|
|
(0020605)
|
|
Daniel Richard G.
|
|
2010-05-05 17:25
|
|
Excellent! All of CMake master builds now on Solaris, sans -xcrossfile. I will try the vtable patch shortly.
Just one nit: When libarchive is looking for the zlib library, it should do a link check. I have a 32-bit libz.so under /usr/local/lib, which gave me link errors when the build tried to pull it into a 64-bit binary. It's not clear how to disable libarchive's use of zlib from the top level of the CMake build, so this should be covered by the library's configure logic. (I ended up manually editing link.txt files and libarchive's config.h.) |
|
|
|
(0020611)
|
|
Daniel Richard G.
|
|
2010-05-06 03:03
|
|
With the vtable patch, I still get link errors on Solaris (with -xcrossfile). Building on HP-UX, I get the "Please define at least one non-inline, non-pure virtual member function" warnings in the following places:
CMake/Source/cmFindPackageCommand.cxx:1599 (cmFileListGeneratorBase)
CMake/Source/cmFindPackageCommand.cxx:1614 (cmFileList)
CMake/Source/cmFindPackageCommand.cxx:1647 (cmFindPackageFileList)
CMake/Source/cmFindPackageCommand.cxx:1694 (cmFileListGeneratorFixed)
CMake/Source/cmFindPackageCommand.cxx:1716 (cmFileListGeneratorEnumerate)
CMake/Source/cmFindPackageCommand.cxx:1745 (cmFileListGeneratorProject)
CMake/Source/cmFindPackageCommand.cxx:1797 (cmFileListGeneratorMacProject)
CMake/Source/cmFindPackageCommand.cxx:1852 (cmFileListGeneratorCaseInsensitive)
CMake/Source/cmFindPackageCommand.cxx:1894 (cmFileListGeneratorGlob)
The count's gone down... you're clearly doing something right. |
|
|
|
(0030025)
|
|
Daniel Richard G.
|
|
2012-07-10 12:44
|
|
CMake (git master) builds correctly on the same Solaris system without -xcrossfile, and with that flag, I get an assembler error:
[ 63%] Building CXX object Source/CMakeFiles/CMakeLib.dir/cmDocumentationFormatterDocbook.cxx.o
[several warnings elided]
28 Warning(s) detected.
cg error (as) : "/tmp/ccfe.09273.1.s", line 122 : redefinition of symbol "$XBckVGsS81_PmOk.__1NbFcmDocumentationFormatterDocbookMPrintSection6MrnDstdNbasic_ostream4Ccn0BLchar_traits4Cc____rknWcmDocumentationSection_pkc_v_.i"
*** Error code 1
The following command caused the error:
cd /tmp/cmake-build/Source && /opt/SUNWspro/bin/CC -DCURL_STATICLIB -DLIBARCHIVE_STATIC -DCMAKE_BUILD_WITH_CMAKE -DCMAKE_USE_NINJA +w2 +w -i -mt -noex -xarch=v9 -xcrossfile -xO5 -I/tmp/cmake-build/Utilities -I/export/home/cport/Dashboards/MyTests/CMake/Utilities -I/tmp/cmake-build/Source -I/export/home/cport/Dashboards/MyTests/CMake/Source -I/tmp/cmake-build/Utilities/cmcompress -I/export/home/cport/Dashboards/MyTests/CMake/Source/CTest -I/export/home/cport/Dashboards/MyTests/CMake/Source/CursesDialog/form -I/tmp/cmake-build/Source/CursesDialog/form -o CMakeFiles/CMakeLib.dir/cmDocumentationFormatterDocbook.cxx.o -c /export/home/cport/Dashboards/MyTests/CMake/Source/cmDocumentationFormatterDocbook.cxx
make: Fatal error: Command failed for target `Source/CMakeFiles/CMakeLib.dir/cmDocumentationFormatterDocbook.cxx.o'
Current working directory /tmp/cmake-build
*** Error code 1
The following command caused the error:
/usr/ccs/bin/make -f Source/CMakeFiles/CMakeLib.dir/build.make Source/CMakeFiles/CMakeLib.dir/build
make: Fatal error: Command failed for target `Source/CMakeFiles/CMakeLib.dir/all'
Current working directory /tmp/cmake-build
*** Error code 1
The following command caused the error:
/usr/ccs/bin/make -f CMakeFiles/Makefile2 all
make: Fatal error: Command failed for target `all'
Same deal with -xO4. I don't think this represents an issue in CMake anymore, as much as a compiler that probably needs patching. Unless there's anything more to be done here, I think this bug can be marked as resolved. |
|
|
|
(0031807)
|
|
David Cole
|
|
2012-12-03 07:46
|
|
|
Closing resolved issues that have not been updated in more than 4 months. |
|
0001-Help-old-C-compilers-place-vtable-symbols.patch (19,402) 2010-04-26 17:13