Re: Rethinking -L switch handling and construction of LDFLAGS

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Rethinking -L switch handling and construction of LDFLAGS
Дата
Msg-id 20180401174338.dgwcclz3ljiumaeq@alap3.anarazel.de
обсуждение исходный текст
Ответ на Rethinking -L switch handling and construction of LDFLAGS  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Rethinking -L switch handling and construction of LDFLAGS  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Rethinking -L switch handling and construction of LDFLAGS
Следующее
От: Yura Sokolov
Дата:
Сообщение: Re: [HACKERS] Lazy hash table for XidInMVCCSnapshot (helps Zipfian abit)