FYI, it seems that recent string-related optimizations in Click cause some problems when the code is compiled with GCC 4.2.1 - which is a rather old compiler, but is still used as the default compiler in some systems (e.g. in FreeBSD 8 and 9). Of course, some other versions of GCC might also have the same problem.
The code gets compiled (without errors etc.), but segmentation faults may occur when Click is started. With other, newer compilers that I tried (e.g. GCC 4.6), the code seems to work as it should. Some more details: It seems that commit "String, StringAccum: Call strlen() early when the result's a constant" (8b94ae6) causes problems for GCC 4.2.1, at least based on my observations on FreeBSD and Mac OS X. E.g. in String::String(const char *cstr), the code based on __builtin_constant_p(strlen(cstr)) and inlining doesn't get compiled correctly for some reason, so assign(cstr, strlen(cstr), false) gets called instead of assign(cstr, -1, false) at runtime. Possibly this is what always happens. If then cstr is NULL (for example), calling strlen(NULL) obviously causes a segmentation fault. This error is very easy to produce: Running "click" without any arguments results in a segmentation fault in the string constructor. This happens before starting to read a configuration from stdin. Apparently this error also occurs if a configuration file given as input starts with require(...), for instance. The current code works if I compile Click e.g. with GCC 4.6 in FreeBSD or LLVM-GCC 4.2.1 in OS X - and that's OK for me. Possibly some other workarounds, such as giving suitable options to the old compiler, might also work - but I haven't tried any. And I'm not sure whether this error occurs on all platforms. - Jimmy _______________________________________________ click mailing list click@amsterdam.lcs.mit.edu https://amsterdam.lcs.mit.edu/mailman/listinfo/click
