On Fri, Jul 09, 2021 at 10:06:18AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Sat, Jul 03, 2021 at 06:44:20PM -0400, Tom Lane wrote:
> >> That'd require buildfarm owner intervention, as well as intervention
> >> by users. Which seems like exporting our problems onto them. I'd
> >>
Noah Misch writes:
> On Sat, Jul 03, 2021 at 06:44:20PM -0400, Tom Lane wrote:
>> That'd require buildfarm owner intervention, as well as intervention
>> by users. Which seems like exporting our problems onto them. I'd
>> really rather not go that way if we can avoid it.
> I like that goal,
On Sat, Jul 03, 2021 at 06:44:20PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Sat, Jul 03, 2021 at 10:45:59AM -0400, Tom Lane wrote:
> >> What I'm now thinking about is restricting the test to only be run on
> >> platforms where use of foo.a libraries is deprecated, so that we can
> >> be
Noah Misch writes:
> On Sat, Jul 03, 2021 at 10:45:59AM -0400, Tom Lane wrote:
>> What I'm now thinking about is restricting the test to only be run on
>> platforms where use of foo.a libraries is deprecated, so that we can
>> be pretty sure that we won't hit this situation. Even if we only
>>
On Sat, Jul 03, 2021 at 10:45:59AM -0400, Tom Lane wrote:
> I'd imagined leaving, e.g., psprintf.c out of libpgcommon_shlib.a.
> But if someone mistakenly introduced a psprintf call into libpq,
> it'd still compile just fine; the symbol would be resolved against
> psprintf in the calling
I wrote:
> Hmmm ... mine is 8.4.1.
> I'm about to go out to dinner, but will check into this with some
> newer gcc versions later.
Tried --enable-coverage on Fedora 34 (with gcc 11.1.1) and sure
enough there's an exit() call being inserted. I've pushed a fix
to just disable the check altogether
I wrote:
> I'm now wondering about applying the test to *.o in libpq,
> as well as libpgport_shlib.a and libpgcommon_shlib.a.
> The latter would require some code changes, and it would make
> the prohibition extend further than libpq alone. On the bright
> side, we could reinstate the check for
Noah Misch writes:
> On Fri, Jul 02, 2021 at 11:20:17AM -0400, Tom Lane wrote:
>> Ugh. What in the world is producing those references?
> Those come from a statically-linked libldap_r:
Blech! I wonder if there is some way to avoid counting that.
It's not really hard to imagine that such a
On Fri, Jul 02, 2021 at 11:20:17AM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > Now it's hoverfly:
> > ! nm -A -u libpq.so.5 2>/dev/null | grep -v __cxa_atexit | grep exit
> > libpq.so.5: atexit U -
> > libpq.so.5: pthread_exit U -
>
> Ugh. What
"alvhe...@alvh.no-ip.org" writes:
> gcc here is 8.3.0.
Hmmm ... mine is 8.4.1.
I'm about to go out to dinner, but will check into this with some
newer gcc versions later.
regards, tom lane
On 2021-Jul-02, Jacob Champion wrote:
> Only src/common:
>
> controldata_utils_shlib.o:
> U close
> U __errno_location
> U exit
Actually, I do see these in the .o files as well, but they don't make it
to the .a file.
gcc here is 8.3.0.
--
On Fri, 2021-07-02 at 18:45 -0400, Tom Lane wrote:
> Jacob Champion writes:
> > On Fri, 2021-07-02 at 18:20 -0400, Tom Lane wrote:
> > > What configure options are you using?
> > Just `./configure --enable-coverage`, nothing else. I distclean'd right
> > before for good measure.
>
> Hmph.
Jacob Champion writes:
> On Fri, 2021-07-02 at 18:20 -0400, Tom Lane wrote:
>> What configure options are you using?
> Just `./configure --enable-coverage`, nothing else. I distclean'd right
> before for good measure.
Hmph. There's *something* different about your setup from what
either Alvaro
On Fri, 2021-07-02 at 18:20 -0400, Tom Lane wrote:
> What configure options are you using?
Just `./configure --enable-coverage`, nothing else. I distclean'd right
before for good measure.
> Does "nm -u" report "exit" being referenced from any *.o in libpq,
> or from any *_shlib.o in src/port/ or
Jacob Champion writes:
> With latest HEAD, building with --enable-coverage still fails on my
> Ubuntu 20.04:
> ! nm -A -u libpq.so.5.15 2>/dev/null | grep -v __cxa_atexit | grep exit
> libpq.so.5.15: U exit@@GLIBC_2.2.5
Hm, weird. I don't see that here on RHEL8, and
On Wed, 2021-06-30 at 10:42 -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2021-Jun-30, Tom Lane wrote:
> > > You mentioned __gcov_exit, but I'm not sure if we need an
> > > exception for that. I see it referenced by the individual .o
> > > files, but the completed .so has no such
Alvaro Herrera writes:
> Now it's hoverfly:
> ! nm -A -u libpq.so.5 2>/dev/null | grep -v __cxa_atexit | grep exit
> libpq.so.5: atexit U -
> libpq.so.5: pthread_exit U -
Ugh. What in the world is producing those references?
(As I mentioned upthread,
Now it's hoverfly:
! nm -A -u libpq.so.5 2>/dev/null | grep -v __cxa_atexit | grep exit
libpq.so.5: atexit U -
libpq.so.5: pthread_exit U -
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hoverfly=2021-07-02%2010%3A10%3A29
--
Álvaro Herrera
Peter Eisentraut writes:
> On 01.07.21 20:14, Tom Lane wrote:
>> The problem then is, what happens when the extra action fails?
>> Without .DELETE_ON_ERROR, the shlib is still there and the next
>> make run will think everything's good.
> Right. .DELETE_ON_ERROR is already set in
On 01.07.21 20:14, Tom Lane wrote:
The variant of this I'd been thinking of was
$(shlib): $(OBJS) | $(SHLIB_PREREQS)
$(LINK.shared) -o $@ $(OBJS) $(LDFLAGS) $(LDFLAGS_SL) $(SHLIB_LINK)
+ifneq (,$(SHLIB_EXTRA_ACTION))
+ $(SHLIB_EXTRA_ACTION)
+endif
(and similarly in several
On Thu, 2021-07-01 at 14:14 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > Somewhere in the $(shlib) rule would seem most appropriate. But I don't
> > understand the rest: What ifeq, and why .DELETE_ON_ERROR?
>
> The variant of this I'd been thinking of was
>
> $(shlib): $(OBJS) |
Peter Eisentraut writes:
> On 01.07.21 00:41, Jacob Champion wrote:
>> Spitballing -- if you don't like the stamp file, you could add the
>> check to the end of the $(shlib) rule, surrounded by an ifeq check.
>> Then .DELETE_ON_ERROR should take care of the rest, I think.
> Somewhere in the
On 01.07.21 00:41, Jacob Champion wrote:
On Wed, 2021-06-30 at 18:29 -0400, Tom Lane wrote:
I wrote:
Peter Eisentraut writes:
Could we set this rule up a little bit differently so that it is only
run when the library is built.
Right now, make world on a built tree makes 17 calls to this "nm"
Alvaro Herrera writes:
> I think this means the rule should use $(GREP), which is /usr/bin/ggrep
> in wrasse,
I didn't install this change, because it isn't actually needed at the
moment, and we aren't using $(GREP) anywhere else. Might be a bridge
to cross in future.
Noah Misch writes:
> On Thu, Jul 01, 2021 at 01:20:48AM -0400, Tom Lane wrote:
>> I've just re-read the POSIX spec for "nm", and I do not see anything there
>> that would support that interpretation.
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/nm.html says:
> nm [-APv] [-g|-u]
On Thu, Jul 01, 2021 at 01:20:48AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Wed, Jun 30, 2021 at 11:45:10PM -0400, Tom Lane wrote:
> >> we're still left with the question of why
> >> Solaris' "nm" doesn't support the POSIX-required options.
>
> > In POSIX, -g and -u are mutually
Noah Misch writes:
> On Wed, Jun 30, 2021 at 11:45:10PM -0400, Tom Lane wrote:
>> we're still left with the question of why
>> Solaris' "nm" doesn't support the POSIX-required options.
> In POSIX, -g and -u are mutually exclusive. Solaris ignores all but the first
> of these in a command:
I've
On Wed, Jun 30, 2021 at 11:45:10PM -0400, Tom Lane wrote:
> we're still left with the question of why
> Solaris' "nm" doesn't support the POSIX-required options.
In POSIX, -g and -u are mutually exclusive. Solaris ignores all but the first
of these in a command:
[nm@gcc-solaris11 5:0
Alvaro Herrera writes:
> On 2021-Jun-30, Noah Misch wrote:
>> No, and wrasse still succeeds at "git checkout e45b0df^". Solaris
>> /usr/bin/grep doesn't support "-e":
> I think this means the rule should use $(GREP), which is /usr/bin/ggrep
> in wrasse,
Ah, my mistake. Although we're still
On 2021-Jun-30, Noah Misch wrote:
> No, and wrasse still succeeds at "git checkout e45b0df^". Solaris
> /usr/bin/grep doesn't support "-e":
I think this means the rule should use $(GREP), which is /usr/bin/ggrep
in wrasse,
checking for grep that handles long lines and -e... /usr/bin/ggrep
--
On Wed, Jun 30, 2021 at 12:06:47PM -0400, Tom Lane wrote:
> I wrote:
> > OK, thanks, will push a fix momentarily.
>
> Did so, and look what popped up on wrasse [1]:
>
> ! nm -A -g -u libpq.so.5.15 2>/dev/null | grep -v __cxa_atexit | grep exit
> libpq.so.5.15: [765] | 232544|
On Wed, 2021-06-30 at 18:56 -0400, Tom Lane wrote:
> Jacob Champion writes:
> > On Wed, 2021-06-30 at 18:29 -0400, Tom Lane wrote:
> > > Looks like we'd have to make use of a dummy stamp-file, more or less
> > > as attached. Any objections?
> > Spitballing -- if you don't like the stamp file,
Jacob Champion writes:
> On Wed, 2021-06-30 at 18:29 -0400, Tom Lane wrote:
>> Looks like we'd have to make use of a dummy stamp-file, more or less
>> as attached. Any objections?
> Spitballing -- if you don't like the stamp file, you could add the
> check to the end of the $(shlib) rule,
On Wed, 2021-06-30 at 18:29 -0400, Tom Lane wrote:
> I wrote:
> > Peter Eisentraut writes:
> > > Could we set this rule up a little bit differently so that it is only
> > > run when the library is built.
> > > Right now, make world on a built tree makes 17 calls to this "nm" line,
> > > and
I wrote:
> Peter Eisentraut writes:
>> Could we set this rule up a little bit differently so that it is only
>> run when the library is built.
>> Right now, make world on a built tree makes 17 calls to this "nm" line,
>> and make check-world calls it 81 times. I think once would be enough. ;-)
Peter Eisentraut writes:
> Could we set this rule up a little bit differently so that it is only
> run when the library is built.
> Right now, make world on a built tree makes 17 calls to this "nm" line,
> and make check-world calls it 81 times. I think once would be enough. ;-)
Hmm, didn't
On 26.06.21 23:29, Tom Lane wrote:
After some thought I propose that what we really want is to prevent
any calls of abort() or exit() from inside libpq. Attached is a
draft patch to do that.
Could we set this rule up a little bit differently so that it is only
run when the library is built.
I wrote:
> OK, thanks, will push a fix momentarily.
Did so, and look what popped up on wrasse [1]:
! nm -A -g -u libpq.so.5.15 2>/dev/null | grep -v __cxa_atexit | grep exit
libpq.so.5.15: [765]| 232544| 248|FUNC |GLOB
|3|14 |PQexitPipelineMode
This
Alvaro Herrera writes:
> (BTW since the _eprintf.o stuff comes from _abort, I suppose you're
> going to remove that grep -v too?)
Right, I did that.
regards, tom lane
On 2021-Jun-30, Tom Lane wrote:
> OK, thanks, will push a fix momentarily.
(BTW since the _eprintf.o stuff comes from _abort, I suppose you're
going to remove that grep -v too?)
--
Álvaro Herrera39°49'30"S 73°17'W
Alvaro Herrera writes:
> On 2021-Jun-30, Tom Lane wrote:
>> You mentioned __gcov_exit, but I'm not sure if we need an
>> exception for that. I see it referenced by the individual .o
>> files, but the completed .so has no such reference, so at least
>> on RHEL8 it's apparently satisfied during
On 2021-Jun-30, Tom Lane wrote:
> Alvaro Herrera writes:
> > Maybe there's something about the linker flags being used.
> > ... ah yeah, if I configure with coverage enabled on my machine, it fails
> > in the same way.
>
> Ah-hah, yeah, I see it too if I enable profiling. I can confirm
> that
Alvaro Herrera writes:
> Maybe there's something about the linker flags being used.
> ... ah yeah, if I configure with coverage enabled on my machine, it fails in
> the same way.
Ah-hah, yeah, I see it too if I enable profiling. I can confirm
that it's not from the abort() call in path.c,
On 2021-Jun-30, Alvaro Herrera wrote:
> If I remove -fprofile-arcs from CFLAGS, then abort is no longer present,
> but we still get a fail because of __gcov_exit. I suppose if you'd add
> an exception for __cxa_atexit, the same place could use one for
> __gcov_exit.
I tried the attached patch,
On 2021-Jun-30, Alvaro Herrera wrote:
> On 2021-Jun-29, Tom Lane wrote:
>
> > Alvaro Herrera writes:
> > > Ah, I nm'd all files in src/interfaces/libpq and got no hits for abort.
> > > But I did get one in libpgport_shlib.a:
> >
> > > path_shlib.o:
> > > U abort
> >
> > Yeah,
On 2021-Jun-29, Tom Lane wrote:
> Alvaro Herrera writes:
> > Ah, I nm'd all files in src/interfaces/libpq and got no hits for abort.
> > But I did get one in libpgport_shlib.a:
>
> > path_shlib.o:
> > U abort
>
> Yeah, there is one in get_progname(). But path.o shouldn't be
Alvaro Herrera writes:
> Ah, I nm'd all files in src/interfaces/libpq and got no hits for abort.
> But I did get one in libpgport_shlib.a:
> path_shlib.o:
> U abort
Yeah, there is one in get_progname(). But path.o shouldn't be getting
pulled into libpq ... else why aren't all
Ah, I nm'd all files in src/interfaces/libpq and got no hits for abort.
But I did get one in libpgport_shlib.a:
path_shlib.o:
U abort
0320 T canonicalize_path
0197 T cleanup_path
09e3 t
On 2021-Jun-29, Tom Lane wrote:
> More troublingly, fossa reports this:
>
> ! nm -A -g -u libpq.so.5.15 2>/dev/null | grep -v '_eprintf\\.o:' | grep -e
> abort -e exit
> libpq.so.5.15: U abort@@GLIBC_2.2.5
>
> Where is that coming from? hippopotamus and jay, which seem to
> be
I wrote:
> So I pushed that, and not very surprisingly, it's run into some
> portability problems. gombessa (recent OpenBSD) reports
> ! nm -A -g -u libpq.so.5.15 2>/dev/null | grep -v '_eprintf\\.o:' | grep -e
> abort -e exit
> libpq.so.5.15:__cxa_atexit
After a few more hours, all of our
I wrote:
>> This relies on "nm" being able to work on shlibs, which it's not
>> required to by POSIX. However, it seems to behave as desired even
>> on my oldest dinosaurs. In any case, if "nm" doesn't work then
>> we'll just not detect such problems on that platform, which should
>> be OK as
I wrote:
> This relies on "nm" being able to work on shlibs, which it's not
> required to by POSIX. However, it seems to behave as desired even
> on my oldest dinosaurs. In any case, if "nm" doesn't work then
> we'll just not detect such problems on that platform, which should
> be OK as long as
Fabien COELHO writes:
> A possible trick is to add ccp flags such as: -Dexit=exit_BAD
> -Dabort=abort_BAD.
Not really going to work, at least not without a lot of fragile
kluges, because the main problem here is to prevent libpq from
*indirectly* calling those functions via stuff it imports
Michael Paquier writes:
> On Sat, Jun 26, 2021 at 05:29:29PM -0400, Tom Lane wrote:
>> I'll stick this into the CF list to see if the cfbot agrees that
>> it finds the abort() problems...
> The CF Bot is finding those problems.
>> +# Check for functions that libpq must not call.
>> +# (If nm
+# Check for functions that libpq must not call.
+# (If nm doesn't exist or doesn't work on shlibs, this test will silently
+# do nothing, which is fine.)
+.PHONY: check-libpq-refs
+check-libpq-refs: $(shlib)
+ @! nm -A -g -u $< 2>/dev/null | grep -e abort -e exit
"abort" and "exit"
On Sat, Jun 26, 2021 at 05:29:29PM -0400, Tom Lane wrote:
> I'll stick this into the CF list to see if the cfbot agrees that
> it finds the abort() problems...
The CF Bot is finding those problems.
> +# Check for functions that libpq must not call.
> +# (If nm doesn't exist or doesn't work on
[ starting a new thread so as not to confuse the cfbot ]
I wrote:
> Michael Paquier writes:
>> Good point. That's worse than just pfree() which is just a plain call
>> to free() in the frontend. We could have more policies here, but my
>> take is that we'd better move fe_memutils.o to
57 matches
Mail list logo
