Re: Unify DLSUFFIX on Darwin
От | Andrew Dunstan |
---|---|
Тема | Re: Unify DLSUFFIX on Darwin |
Дата | |
Msg-id | 129f1cb2-62cd-cd4e-8c0a-ad9b56924d50@dunslane.net обсуждение исходный текст |
Ответ на | Re: Unify DLSUFFIX on Darwin (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 2022-06-24 Fr 10:13, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes: >> On 22.06.22 15:45, Tom Lane wrote: >>> Doesn't this amount to a fundamental ABI break for extensions? >>> Yesterday they had to ship foo.so, today they have to ship foo.dylib. >> Extensions generally only load the module files using the extension-free >> base name. And if they do specify the extension, they should use the >> provided DLSUFFIX variable and not hardcode it. So I don't see how this >> would be a problem. > Hm. Since we force people to recompile extensions for new major versions > anyway, maybe it'd be all right. I'm sure there is *somebody* out there > who will have to adjust their build scripts, but it does seem like it > shouldn't be much worse than other routine API changes. > > [ thinks for a bit... ] Might be worth double-checking that pg_upgrade > doesn't get confused in a cross-version upgrade. A quick grep doesn't > find that it refers to DLSUFFIX anywhere, but it definitely does pay > attention to extensions' shared library names. > > The buildfarm client uses `make show_dl_suffix` to determine filenames to look for when seeing if an installation is complete. It looks like that will continue to work. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: