Thread: LDFLAGS overriding
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
I think your 'override' fix is correct. Personally I think override should be used in most cases in our code because we are usually careful to add to any flags already supplied by the user. --------------------------------------------------------------------------- Neil Conway wrote: > 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, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
[ CC'ing Peter since this is usually his area ] On Wed, 2004-09-29 at 02:10, Bruce Momjian wrote: > I think your 'override' fix is correct. Personally I think override > should be used in most cases in our code because we are usually careful > to add to any flags already supplied by the user. Ok, I think 'override' is definitely correct for the instance the patch fixes, since the build breaks otherwise. Therefore I intend to apply the patch I posted earlier to HEAD shortly, barring any objections. In addition, we modify LDFLAGS in the following places: (1) src/Makefile.global.in -- adding rpath flags (2) src/Makefile.global.in -- adding LDFLAGS due to COPT/PROFILE (3) src/makefiles/Makefile.hpux (4) src/makefiles/Makefile.irix (5) src/makefiles/Makefile.qnx4 (6) src/makefiles/Makefile.svr4 What do folks think about using override in these situations? -Neil
Neil Conway schrieb: > [ CC'ing Peter since this is usually his area ] > On Wed, 2004-09-29 at 02:10, Bruce Momjian wrote: > >>I think your 'override' fix is correct. Personally I think override >>should be used in most cases in our code because we are usually careful >>to add to any flags already supplied by the user. > > Ok, I think 'override' is definitely correct for the instance the patch > fixes, since the build breaks otherwise. Therefore I intend to apply the > patch I posted earlier to HEAD shortly, barring any objections. > > In addition, we modify LDFLAGS in the following places: > > (1) src/Makefile.global.in -- adding rpath flags > > (2) src/Makefile.global.in -- adding LDFLAGS due to COPT/PROFILE > > (3) src/makefiles/Makefile.hpux > > (4) src/makefiles/Makefile.irix > > (5) src/makefiles/Makefile.qnx4 > > (6) src/makefiles/Makefile.svr4 > > What do folks think about using override in these situations? I think that LDFLAGS overriding is in some situations bad for newer libtool, as it is used with some postgresql contrib makefiles and interfaces. LIBS are added to LDFLAGS where they really should be added to LIBS, not LDFLAGS. This causes incorrect order in the linker command-line, which fails in building shared libs. A similar problem as with building php. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/
On Thu, 2004-09-30 at 17:20, Neil Conway wrote: > Ok, I think 'override' is definitely correct for the instance the patch > fixes, since the build breaks otherwise. Therefore I intend to apply the > patch I posted earlier to HEAD shortly, barring any objections. Patch applied. I haven't changed the other assignments to LDFLAGS; that can be done by anyone who's interested. -Neil
Reini Urban wrote: > I think that LDFLAGS overriding is in some situations bad for newer > libtool, as it is used with some postgresql contrib makefiles and > interfaces. We're not using libtool. > LIBS are added to LDFLAGS where they really should be added to > LIBS, not LDFLAGS. > This causes incorrect order in the linker command-line, which fails > in building shared libs. A similar problem as with building php. Please point out where that happens so it can be corrected. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut schrieb:
> Reini Urban wrote:
>>I think that LDFLAGS overriding is in some situations bad for newer
>>libtool, as it is used with some postgresql contrib makefiles and
>>interfaces.
>
> We're not using libtool.
sorry. it conflicts with gnu ld.
>>LIBS are added to LDFLAGS where they really should be added to
>>LIBS, not LDFLAGS.
>>This causes incorrect order in the linker command-line, which fails
>>in building shared libs. A similar problem as with building php.
>
>
> Please point out where that happens so it can be corrected.
Something like this (against an older cvs snap), but I don't believe
that this is the best way to solve it. It just solved building under cygwin.
(sorry for the linewrap's)
--- postgresql-8.0.0cvs/src/Makefile.shlib.orig 2004-07-13
01:06:46.000000000 +0100
+++ postgresql-8.0.0cvs/src/Makefile.shlib 2004-09-03 14:44:14.436032500
+0100
@@ -212,6 +212,7 @@
ifeq ($(PORTNAME), cygwin)
shlib = $(NAME)$(DLSUFFIX)
+ SHLIB_LINK += $(LDFLAGS)
endif
ifeq ($(PORTNAME), win32)
@@ -224,9 +225,13 @@
SHLIB_LINK += -ltermcap -lstdc++.r4 -lbind -lsocket
-L/boot/develop/lib/x86
endif
-SHLIB_LINK := $(filter -L%, $(LDFLAGS)) $(SHLIB_LINK)
+ifeq ($(PORTNAME), cygwin)
+ SHLIB_LINK := $(LDFLAGS) $(LIBS) $(SHLIB_LINK)
+else
+ SHLIB_LINK := $(filter -L%, $(LDFLAGS)) $(SHLIB_LINK)
+endif
ifeq ($(enable_rpath), yes)
-SHLIB_LINK += $(rpath)
+ SHLIB_LINK += $(rpath)
endif
endif # enable_shared
--- postgresql-8.0.0cvs/src/makefiles/pgxs.mk.orig 2004-07-30
13:26:40.000000000 +0100
+++ postgresql-8.0.0cvs/src/makefiles/pgxs.mk 2004-09-03
14:53:00.569922900 +0100
@@ -63,7 +63,11 @@
ifdef MODULES
override CFLAGS += $(CFLAGS_SL)
-SHLIB_LINK += $(BE_DLLLIBS)
+ifeq ($(PORTNAME), cygwin)
+ SHLIB_LINK += $(BE_DLLLIBS) $(LDFLAGS) $(LIBS)
+else
+ SHLIB_LINK += $(BE_DLLLIBS)
+endif
endif
ifdef PG_CPPFLAGS
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
Reini Urban <rurban@x-ray.at> writes:
> Peter Eisentraut schrieb:
>> Please point out where that happens so it can be corrected.
> Something like this (against an older cvs snap), but I don't believe
> that this is the best way to solve it. It just solved building under cygwin.
Peter asked to know where the problem is, not what your proposed
solution is (especially if you admit the solution needs work).
What happens exactly when you try to build without this patch?
regards, tom lane
Tom Lane schrieb:
> Reini Urban <rurban@x-ray.at> writes:
>>Peter Eisentraut schrieb:
>>
>>>Please point out where that happens so it can be corrected.
>
>>Something like this (against an older cvs snap), but I don't believe
>>that this is the best way to solve it. It just solved building under cygwin.
>
> Peter asked to know where the problem is, not what your proposed
> solution is (especially if you admit the solution needs work).
>
> What happens exactly when you try to build without this patch?
rurban@reini /usr/src/postgresql/postgresql-8.0.0cvs/contrib/spi
$ make
gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
-Wmissing-declarations -DREFINT_VERBOSE -I.
-I../../src/include -c -o timetravel.o timetravel.c
dlltool --export-all --output-def timetravel.def timetravel.o
dllwrap -o timetravel.dll --def timetravel.def timetravel.o
../../src/utils/dllinit.o -L../../src/backend -lpostgres
timetravel.o(.text+0x231):timetravel.c: undefined reference to
`_pg_strcasecmp'
collect2: ld gab 1 als Ende-Status zur"uck
dllwrap: gcc exited with status 1
make: *** [timetravel.dll] Fehler 1
rm timetravel.o
Analysis:
-lpgport missing in SHLIB_LINK
-L$(top_builddir)/src/port not added from LDFLAGS to SHLIB_LINK
make -p gives:
%.dll: %.o
# Auszuf"uhrende Kommandos (aus >>../../src/Makefile.port<<, Zeile 16):
$(DLLTOOL) --export-all --output-def $*.def $<
$(DLLWRAP) -o $@ --def $*.def $< $(DLLINIT) $(SHLIB_LINK)
rm -f $*.def
# >>override<<-Anweisung (from `../../src/Makefile.global', line 366)
LDFLAGS := -L../../src/port -L/usr/local/lib