LDFLAGS overriding

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