Re: static libpq (and other libraries) overwritten on aix

From: Andres Freund <andres(at)anarazel(dot)de>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, robertmhaas(at)gmail(dot)com
Subject: Re: static libpq (and other libraries) overwritten on aix
Date: 2022-08-20 08:35:22
Message-ID: 20220820083522.i5wocl3xugarzxcn@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2022-08-18 22:56:43 -0700, Noah Misch wrote:
> > On 2022-08-17 21:59:29 -0700, Noah Misch wrote:
> > > Along the lines of Robert's comment, it could be a nice code beautification to
> > > use a different suffix for the short-lived .a file. Perhaps _so_inputs.a.
> >
> > Agreed, it'd be an improvement.
> >
> > Afaict we could just stop building the intermediary static lib. Afaict the
> > MKLDEXPORT path isn't needed for libraries without an exports.txt because the
> > linker defaults to exporting "most" symbols
>
> If that works, great.

I looked at that. It's not too hard to make it work. But while doing so I
encountered some funny bits.

As far as I can tell the way we build shared libraries on aix with gcc isn't
correct:

Without -shared gcc won't know that it's building a shared library, which
afaict will prevent gcc from generating correct unwind info and we end up with
a statically linked copy of libgcc each time.

The naive thing of just adding -shared fails, but that's our fault:

ldd pgoutput.so
pgoutput.so needs:
Cannot find libgcc_s.a(shr.o)
/usr/lib/libc.a(shr_64.o)
/unix
/usr/lib/libcrypt.a(shr_64.o)

Makefile.aix has:
# -blibpath must contain ALL directories where we should look for libraries
libpath := $(shell echo $(subst -L,:,$(filter -L/%,$(LDFLAGS))) | sed -e's/ //g'):/usr/lib:/lib

but that's insufficient for gcc, because it won't find gcc's runtime lib. We
could force a build of the statically linked libgcc, but once it knows it's
generating with a shared library, a static libgcc unfortunately blows up the
size of the output considerably.

So I think we need something like

ifeq ($(GCC), yes)
libpath := $(libpath):$(dir $(shell gcc -print-libgcc-file-name))
endif

although deferring the computation of that would be nicer, but would require
some cleanup before.

With that libraries do shrink a bit. E.g. cube.so goes from 140k to 96k.

Afaict there's no reason to generate lib<name>.a for extension .so's, right?

We have plenty of detritus that's vaguely AIX related. The common.mk rule to
generate SUBSYS.o isn't used (mea culpa), and backend/Makefile's postgres.o
rule hasn't been used for well over 20 years.

I'll send in a patch series tomorrow, too tired for today.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2022-08-20 09:17:41 Re: shadow variables - pg15 edition
Previous Message Peter Eisentraut 2022-08-20 07:47:15 Re: Proposal: CREATE/ALTER DOMAIN ... STORAGE/COMPRESSION = ...