LDFLAGS overriding - Mailing list pgsql-patches

From Neil Conway
Subject LDFLAGS overriding
Date
Msg-id 1096366112.28946.98.camel@localhost.localdomain
Whole thread Raw
Responses Re: LDFLAGS overriding
List pgsql-patches
Overriding the value of LDFLAGS breaks the build:

$ make LDFLAGS=-g
gcc-3.4 -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
-Wmissing-declarations -DFRONTEND -I../../src/include
-I/home/neilc/build-pgsql/src/../../pgsql/src/include -D_GNU_SOURCE   -c
-o dirmod.o dirmod.c -MMD
gcc-3.4 -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
-Wmissing-declarations zic.o ialloc.o scheck.o localtime.o dirmod.o -g
-lpgport -lz -lreadline -lcrypt -lresolv -lnsl -ldl -lm  -o zic
/usr/bin/ld: cannot find -lpgport
collect2: ld returned 1 exit status
make[2]: *** [zic] Error 1
make[2]: Leaving directory `/home/neilc/build-pgsql/src/timezone'
make[1]: *** [all] Error 2

(The "-g" flag is just for example.)

IMHO we ought to let users override LDFLAGS, just like we let them
override CFLAGS. When we need to modify LDFLAGS unconditionally (i.e.
regardless of whether the user has already defined it), the "override"
directive should be used. Attached is a trivial patch that fixes the
build for me.

There are a few other assignments/concatenations to LDFLAGS that are
going to be skipped if there is a user-defined LDFLAGS (e.g. enabling
rpath in src/Makefile.global.in, and some HPUX port-specific stuff). I
wasn't sure if this should also ignore user-defined LDFLAGS, so I didn't
modify it.

Comments? (I won't claim to be a make expert, so it's entirely possible
this change is off the mark.)

-Neil


Attachment

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: 8.0.0beta3 duration logging patch
Next
From: "Dave Page"
Date:
Subject: Re: [pgsql-hackers-win32] VC++ psql build broken