Hi,
On Mon, Dec 12, 2011 at 12:41 PM, Paolo Carlini
<paolo.carl...@oracle.com> wrote:
On 12/12/2011 09:37 PM, Easwaran Raman wrote:
Thanks for the comments Paolo. I have attached the new patch. I have
bumped the version to 3.4.18
You shouldn't: 4.7 is not out yet, thus no reason to increase the minor
version beyond the current 17.
Ok, I then don't understand your comment
"Note that backporting the patch as-is to 4_6-branch would be very
wrong in terms of ABI (in mainline we already have a 3.4.17)".
My original patch added the new symbol in version 3.4.17. Since we
don't want to add the symbol to 3.4.16 (if we have a situation where
the new runtime is not available when running a program compiled with
-fsized-delete) and you said I shouldn't be using 3.4.17, I assumed
I had to bump up the version.
Note this is going to be an academic discussion, because it's too late
for 4.7 anyway, and I'm not even sure it's conforming to add overloads
like this for operators.
Anyway.
For 4.6 branch at this point the situation would be very difficult. We
could have a small time window before 4.7 is out to move **all** its new
symbols vs 4.6, currently in 3.4.17, to a new 3.4.18 and then we could
bump 4.6 to 3.4.17. You see, after a minor is delivered you cannot add
anything to it, and also you have the general requirement that the minor
version is the minor ersion, thus irrespective whether we are talking
about gcc4.6 or gcc4.7, a specific minor version number defines which
symbols are exported. I hope now the issues are more clear.You must be
always very careful.
and used _ZdlPv[jmy] in gnu.ver. I have
also added the symbol to baseline_symbols.txt of other targets.
You should not, just read again what I wrote. And you don't have to believe
me: just browse the libstdc++ ChangeLogs and see if somebody ever does that
when the linker map is touched.
Sorry, I again misunderstood this as well (and still don't have a good
picture). Is the part which adds _ZdlPv[jmy] in gnu.ver ok?
Looks fine yes. But I didn't really check the letters. General rule of
thumb when fiddling with linker scripts: double check what you are doing
with a multilib system, like x86_64, at least you can catch errors when
you are mistakenly not accounting for the 32-bit version of the symbols.
In the case at issue, size_t can boil down be unsigned int, unsigned
long, unsigned long long, make sure the pattern includes all three.
I added
that by mimicking the symbol _Znw[jmy] found in the same file. From
the log, it looks like the baseline_symbols.txt seems to be generated,
but I am not sure how that is to be done. For example, r145437 says a
bunch of these baseline_symbols.txt are regenerated, but I don't see
any other change from which this might be generated.
General rule of thumb: normally, if you aren't a release manager, or a
maintainer, **never** regenerate the baseline_symbols files. Just add
symbols to the linker script, that is normally fine, doesn't break
anything per se, adding is fine (subtracting/changing is not, of course).
Paolo.
