et @6.0.5: error: call to 'clock_gettime' is ambiguous

[ryandesign (Ryan Schmidt)]

et failed to build on 10.6 because it used getline. So I added the legacysupport portgroup. That fixed the getline problem, but now it still ​fails to build because apparently et has a built-in compatibility version of clock_gettime but it is different from the one provided by legacysupport:

/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_net_et/et/work/EternalTerminal-6.0.5/src/base/sole.hpp:457:3: error: call to 'clock_gettime' is ambiguous
  clock_gettime(0 /*CLOCK_REALTIME*/, &tp);
  ^~~~~~~~~~~~~
/opt/local/include/LegacySupport/time.h:39:12: note: candidate function
extern int clock_gettime( clockid_t clk_id, struct timespec *ts );
           ^
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_net_et/et/work/EternalTerminal-6.0.5/src/base/sole.hpp:442:16: note: candidate function
    inline int clock_gettime(int /*clk_id*/, struct timespec *t) {
               ^

Ken, do you know what the best way is to deal with this?

[kencu (Ken)]

We haven't come across this much yet.

It would occasionally be desirable to be able to choose just the parts of legacysupport we want to use by manipulating #defines, for example ​this one. We haven't really crossed that bridge to make that work yet though.

I will have to see if the easiest thing would be to patch in getline, or disable the internal compat function.

[ryandesign (Ryan Schmidt)]

This still happens.

It seems to me that et should be able to tell that clock_gettime is available (from legacy support) and that it should therefore not attempt to provide its own implementation. I haven't looked at et's code to see what it's doing.

[ryandesign (Ryan Schmidt)]

et's use of clock_gettime comes from a bundled copy of sole. ​I filed a bug report with sole and they suggested adding static to the clock_gettime declaration. I haven't tried that yet.