This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Thu, Jul 24, 2008 at 5:18 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote: > Hi, > >> > Would it work *not* including <time.h> in chrono.cc, >> >> chrono.cc includes sys/time.h for gettimeofday not clock_gettime. >> The clock_gettime comes through <time.h> in <ctime>. > > Sure, I know that. But my next messages clearly explain what I had in mind, the idea basically was that I wanted to hide the declaration of clock_gettime (available in <time.h> or <ctime>) to chrono.cc and replace it with one decorated with the weakref attribute. In fact, I discovered lately, that is not necessary, chrono.cc can certainly see the declarations in <time.h> and add a declaration of __clock_gettime on top, with weakref attribute and alias. Then use only the latter everywhere. > > The doubt now is the following: whether this structure in chrono.cc, which is OK for safely delivering runtime error messages to the user, explaining which library is missing, as suggested by Martin, already a great improvement, would be still able to trigger the --as-needed mechanism in the specs of the compiler, which we want anyway in order to have the automatic on-demand linking. > > Paolo. > > Ok. I'm a little in the dark here but I attached is a preliminary patch anyway. I'm getting some unexpected behavior though. I've removed the GLIBCXX_LIBS bits thus preventing the unconditional inclusion of -lrt, BUT, when I compile a trivial app: #include <chrono> #include <iostream> using namespace std; int main() { chrono::system_clock::time_point t = chrono::system_clock::now(); cout << chrono::system_clock::period::den << endl; return 0; } with g++44 -O0 -std=gnu++0x -o test test.cpp And its output is 1000000000 indicating nanosecond resolution which means clock_gettime is being used. However "ldd test" shows: libstdc++.so.6 => lib64/libstdc++.so.6 libm.so.6 => /lib64/tls/libm.so.6 libgcc_s.so.1 => lib64/libgcc_s.so.1 libc.so.6 => /lib64/tls/libc.so.6 /lib64/ld-linux-x86-64.so.2 So it works on my arch (x86_64) w/o librt and pthread... I must be missing something. Chris
Attachment:
Changelog_librt2.txt
Description: Text document
Attachment:
librt_patch.txt
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |