This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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]

Re: [PATCH, v3] Potential solution to librt issue.


Paolo Carlini wrote:
Replying to myself... ;)

I'm still wondering if we could somehow
have a mechanism working *inside* the .so, like having
clock_gettime considered weak (Martin ;) inside the .so, and
then the linking of librt triggering at the end of the linking
process if the symbol is actually referenced somewhere in the
user code and remained undefined. Is that vague idea clear,
does it make sense (I'm asking the experts)?

Would it work *not* including <time.h> in chrono.cc, instead declaring it "by hand" decorated with the "famous" weakref attribute. Then the .so would export a __clock_gettime symbol, which essentially would wrap everything is now in the body of definition of system_clock::now. In the header, the inline definition of system_clock::now just forwards to __clock_gettime.

IIUC, what you're suggesting is:


Declare in chrono.cc (part of libstdc++.so):

    static int __clock_gettime (clockid_t, struct timespec*)
        __attribute__((weakref ("clock_gettime")));

and change all references to clock_gettime() to something like

    if (__clock_gettime)
        __clock_gettime(clk_id, &tspec);
    else
        perror("must link with librt.so")

Then users of chrono would get a runtime error unless they
linked with librt.so.

Is this close to what you have in mind?

Martin


The above, + Paolo's mechanism in the specs, - the unconditional linking of librt (added a few days ago).


Paolo.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]