This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, v3] Potential solution to librt issue.
Hi again,
> Anyway, what we really want is playing a bit with Paolo's
> draft, nothing is going to wrong,
I meant *work* of course.
otherwise, because nothing
> in the compiler + library takes care of linking librt on demand.
> If the compiler bits are ok, then the library bits, which you
> have essentially ready, are very simple.
To be clear, repeating myself: at the moment, I'm not at all sure that Paolo's compiler bits + the weakref thing in chrono.cc work well together. I would suggest, therefore, also experimenting with the basic idea, discussed much earlier today with Paolo: compiler bits + system_clock::now completely inline, in <chrono>, that should work decently well, modulo minor tweaks to Paolo Bonzini work. Then, if that works, we should consider also trying to move the library game inside chrono.cc, with the weakref mechanism or something similar, I hope it works. If everything fails, I would consider a decent step forward *only* the library changes the way Martin proposed.
Paolo.
- References:
- Re: [PATCH, v3] Potential solution to librt issue.
- Re: [PATCH, v3] Potential solution to librt issue.
- Re: [PATCH, v3] Potential solution to librt issue.
- Re: [PATCH, v3] Potential solution to librt issue.
- Re: [PATCH, v3] Potential solution to librt issue.
- Re: [PATCH, v3] Potential solution to librt issue.
- Re: [PATCH, v3] Potential solution to librt issue.
- Re: [PATCH, v3] Potential solution to librt issue.
- Re: [PATCH, v3] Potential solution to librt issue.
- Re: [PATCH, v3] Potential solution to librt issue.
- Re: [PATCH, v3] Potential solution to librt issue.
- Re: [PATCH, v3] Potential solution to librt issue.