speed tables doesn't work with clang and other non-GCC compilers
smkelly opened this issue · comments
In FreeBSD 10, the default compiler was switched from GNU gcc to clang. As a result, the g++ command is gone and has been replaced by the c++ command.
This project is using autoconf, but none of the results from that are being used to tune what compiler commands are launched from the Tcl code. For example, ctables/config.log shows:
configure:5027: checking for g++
configure:5057: result: no
configure:5027: checking for c++
configure:5043: found /usr/bin/c++
configure:5054: result: c++
but, ctables/sysconfig.tcl has:
sysconfig.tcl:set sysconfig(cxx) {g++}
sysconfig.tcl:set sysconfig(cxxld) {g++ -shared}
As a result, this does not work on any system that uses something other than gcc/g++.
The generation of sysconfig.tcl uses tclConfig.sh to get the compiler command used to build Tcl.
If you built Tcl while still on FreeBSD 9, then upgraded to FreeBSD 10, it's possible that tclConfig.sh still contains TCL_CC='g++' and this might be the cause for g++ to appear in sysconfig.tcl.
Is this your situation?
You should rebuild all ports when doing a major-version upgrade of FreeBSD.
Hope this helps.
Relatedly, I get an error when trying to compile a ctable due to what (I think) is a bug in gentable.tcl:
cc: warning: argument unused during compilation: '-R/usr/local/lib/pgtcl1.9'
while executing
"exec cc -shared -o stobj/plugcraft/libplugcraft.so stobj/plugcraft/plugcraft-1.0.o -R/usr/local/lib/pgtcl1.9 -L/usr/local/lib/pgtcl1.9 -lpgtcl1.9 -L/..."
("eval" body line 1)
invoked from within
"eval exec $command"
(procedure "myexec" line 9)
invoked from within
"myexec $ld_cmd"
(procedure "compile" line 112)
invoked from within
"compile
(procedure "::ctable::EndExtension" line 26)
invoked from within
"::ctable::EndExtension"
(procedure "_speedtables" line 35)
invoked from within
"_speedtables plugcraft 1.0 {
CTable Aircraft {
double latitude
double longitude
short shadowsize
short airplaneangle
short priori..."
("uplevel" body line 1)
invoked from within
"uplevel 1 [list _speedtables $name $version $code]"
(procedure "CExtension" line 2)
invoked from within
"CExtension plugcraft 1.0 {
CTable Aircraft {
double latitude
double longitude
short shadowsize
short airplaneangle
short priority..."
(file "plugcraft.ct" line 8)
*** Error code 1
Stop.
I think lines 5819-5821 need to be changed to use a flag that is appropriate for the system based on autoconf. After some testing, it appears that append ld_cmd " -Wl,-rpath,$dir" is what should be on line 5820 of gentable.tcl for freebsd 10 systems.
After some testing, it appears that append ld_cmd " -Wl,-rpath,$dir" is what should be on line 5820 of gentable.tcl for freebsd 10 systems.
Your ld_cmd is correct. That's what's supposed to be used on any supported FreeBSD version. However, it looks like the constructed paths are wrong. I have created #41 . Could you please test that patch?
I think this needs to be re-opened. I just installed a fresh FreeBSD 10.1 and cloned speedtables and got the same problem:
TCL_LIBRARY=echo /usr/local/include/tcl8.6/library LD_LIBRARY_PATH="/usr/local/lib/tcl8.6:" PATH="/usr/local/lib/tcl8.6:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/home/peter/bin" TCLLIBPATH=".." /usr/local/bin/tclsh8.6 speedtable.tcl
couldn't execute "g++": no such file or directory
while executing
"exec g++ -O2 -fPIC -DPACKAGE_NAME="tcl" -DPACKAGE_TARNAME="tcl" -DPACKAGE_VERSION="8.6" -DPACKAGE_STRING="tcl\ 8.6" -DPACKAGE_BUGREPORT="..."
("eval" body line 1)
invoked from within
"eval exec $command"
(procedure "myexec" line 9)
invoked from within
"myexec "$sysconfig(cxx) $sysString $optflag $dbgflag $sysconfig(ldflags) $sysconfig(ccflags) -I$include $sysconfig(warn) $pgString $stubString $memDeb..."
(procedure "compile" line 85)
"cd speedtables/ctables/tests; make" falls completely apart even after switching to c++, speedtables really does need g++.
@resuna Do you think you can figure out what remaining places need to change to be compatible with clang?
OK, the problem seems to be that the original ctable row definition created this dummy "ctable_BaseRow" that matched the start of the defined row:
// This must start off as a copy of the start of the generated ctable
typedef struct ctable_baseRowStruct {
// hashEntry absolutely must be the first thing defined in the base row
ctable_HashEntry hashEntry;
#ifdef WITH_SHARED_TABLES
cell_t _row_cycle;
#endif
// _ll_nodes absolutely must be the last thing defined in the base row
ctable_LinkedListNode _ll_nodes[];
} ctable_BaseRow;
The generated ctable looks the same, except that the nodes are an array, and are followed by the ctable data:
struct top_brands {
ctable_HashEntry hashEntry;
#ifdef WITH_SHARED_TABLES
cell_t _row_cycle;
#endif
ctable_LinkedListNode _ll_nodes[TOP_BRANDS_NLINKED_LISTS];
...
};
In the C++ code, the ctable_BaseRow is substantially the same:
// This must start off as a copy of the start of the generated ctable
struct ctable_BaseRow {
// hashEntry absolutely must be the first thing defined in the base row
ctable_HashEntry hashEntry;
#ifdef WITH_SHARED_TABLES
cell_t _row_cycle;
#endif
// _ll_nodes absolutely must be the last thing defined in the base row
ctable_LinkedListNode _ll_nodes[];
};
But the generated ctable references and I assume appends to the BaseRow:
struct top_brands : public ctable_BaseRow {
ctable_LinkedListNode _ll_nodes[TOP_BRANDS_NLINKED_LISTS];
...
}
G++ doesn't seem to care about the overlap (it seems to treat "ctable_LinkedListNode _ll_nodes[]" as a null). clang does:
stobj/Topbrands/Topbrands-1.0.cpp:102:28: error: base class 'ctable_BaseRow' has a flexible array member
struct top_brands : public ctable_BaseRow {
^
Then everything falls apart and you get a world class error cascade.
I don't know if the solution is to go back to the blind overlays of the C code, or if there's something subtle that you can do in C++ to make it do the right thing.
The "flexible array member" (_ll_nodes[], which technically has 0-size) that is the last thing in ctable_BaseRow is indeed used as a kind of array-access hack that is intentionally designed to access the storage that is allocated in top_brands (same name _ll_nodes that happens to intentionally shadow naming access to the base object).
http://comments.gmane.org/gmane.comp.compilers.clang.devel/38961 suggests that it may be possible to use syntax in place of the flexible array member:
ctable_LinkedListNode _ll_nodes[0];
However, that may be only a short-term workaround, since it looks like Clang/LLVM are considering a patch that would make both syntaxes be rejected identically: http://reviews.llvm.org/D5478