Re: Rethinking -L switch handling and construction of LDFLAGS

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Rethinking -L switch handling and construction of LDFLAGS
Date: 2018-04-01 17:43:38
Message-ID: 20180401174338.dgwcclz3ljiumaeq@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

Hi,

On 2018-04-01 13:38:15 -0400, Tom Lane wrote:
> In short, we need to deal more honestly with the positioning of -L
> switches in link commands. Somebody's idea that we could embed
> both -L and -l into $(libpq), and then pay basically no attention to
> where that ends up in the final link command, is just too simplistic.

Sounds right.

> I don't have a concrete patch to propose yet, but the design idea
> I have in mind is to split LDFLAGS into two or more parts, so that
> -L switches for the build tree are supposed to be put in the first
> part and external -L switches in the second. It'd be sufficient
> to have Makefile.global do something like
>
> ifdef PGXS
> LDFLAGS_INTERNAL = -L$(libdir)
> else
> LDFLAGS_INTERNAL = -L$(top_builddir)/src/port -L$(top_builddir)/src/common
> endif
> LDFLAGS = $(LDFLAGS_INTERNAL) @LDFLAGS@

I'm not sure I like doing this in Makefile.global. We've various files
that extend LDFLAGS in other places, and that's going to be hard if it's
already mushed together again. We end up re-building it from parts in
those files too.

Why don't we change the link commands to reference LDFLAGS_INTERNAL
explicitly? That seems like it'd be cleaner.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yura Sokolov 2018-04-01 17:53:06 Re: [HACKERS] Lazy hash table for XidInMVCCSnapshot (helps Zipfian a bit)
Previous Message Tom Lane 2018-04-01 17:38:15 Rethinking -L switch handling and construction of LDFLAGS