Re: [HACKERS] PORTNAME and LINUX_ELF defines in interface Makefiles - Mailing list pgsql-hackers

From Kristofer A. E. Peterson
Subject Re: [HACKERS] PORTNAME and LINUX_ELF defines in interface Makefiles
Date
Msg-id 353D1792.9A791B03@taconic.net
Whole thread Raw
In response to Re: [HACKERS] PORTNAME and LINUX_ELF defines in interface Makefiles  (The Hermit Hacker <scrappy@hub.org>)
Responses Re: [HACKERS] PORTNAME and LINUX_ELF defines in interface Makefiles
List pgsql-hackers
I realize that this post is long, so I'll sum it up. My original post
was not meant as a request for help, I have gotten used to kludging the
Makefiles for 6.2.1, 6.3.0, 6.3.1, and now 6.3.2. I want to help clean
up the Makefiles/configure so linux users don't have to kludge the
Makefiles to get shared library versions of libpgtcl, libpq, libpq++,
and libecpg. I just want to offer a perspective on the building process
from outside point of view.

By the way, postgresql-6.3.2 is a *great* program, good work guys! I
usually do not bother posting bugs, fixes, etc to projects I am not
involved in, but I hope these comments are useful, and help make
postgresql-6.3.2 a better package.

The Hermit Hacker wrote:
>
> On Tue, 21 Apr 1998, Kristofer A. E. Peterson wrote:
>
> > I have had problems with LINUX_ELF and/or PORTNAME *not* being defined
>
>         PORTNAME was removed months ago and shouldn't be used except for
> in *very* few specialized places...
>
>         LINUX_ELF has been fixed in v6.3.2, using the patch available at
> ftp://ftp.postgresql.org/pub/patches/linux_elf.patch-980421.gz, which has
> been confirmed by Constantin...

That file is *not* a patch, that is a *kludge*. Of course, it is a step
in the right direction. This is what it did to
postgresql-6.3.2/src/configure (line 661):

------
 # Check whether --with-template or --without-template was given.
 if test "${with_template+set}" = set; then
   withval="$with_template"
     TEMPLATE=template/$withval
 else
     TEMPLATE=template/`uname -s | tr A-Z a-z`
 fi
*
 echo "$ac_t""$TEMPLATE" 1>&6
>
>if test "$TEMPLATE" = "linux-elf"; then
>        LINUX_ELF=yes
>else
>        LINUX_ELF=no
>fi
>

 export TEMPLATE
------

Why bother checking what $TEMPLATE is set too? It will *never* equal
'linux-elf', if anything it would be set to 'template/linux-elf`.
Secondly, $TEMPLATE will only equal 'linux-elf' if you specify it with
the --with-template option, since

'uname -s | tr A-Z a-z` will be 'linux', regardless of elf-capability.

One way of check for elf capability is to see if ld supports the
elf_i386
emulation, although there might be better ways of doing this. At least
with this, configure will figure out you have an elf system, and set
LINUX_ELF=yes, not =no.

------
 # Check whether --with-template or --without-template was given.
 if test "${with_template+set}" = set; then
   withval="$with_template"
     TEMPLATE=template/$withval
 else
     TEMPLATE=template/`uname -s | tr A-Z a-z`
 fi

*if test "$TEMPLATE" = "template/linux"; then
*        ld -V | grep -i "elf" >/dev/null 2>/dev/null
*        if test $? -eq 0; then
*                TEMPLATE=${TEMPLATE}-elf
*             LINUX_ELF=yes
*     else
*              LINUX_ELF=no
*        fi
*fi
*
 echo "$ac_t""$TEMPLATE" 1>&6

 export TEMPLATE
------

And here is the patched
postgresql-6.3.2/src/interfaces/libpgtcl/Makefile, after applying
linux_elf.patch-980421.gz, but before hand changing configure as above.

------
ifeq ($(PORTNAME), linux)
  LINUX_ELF=no
  ifdef LINUX_ELF
    install-shlib-dep   := install-shlib
    shlib               := libpgtcl.so.1
    CFLAGS              += $(CFLAGS_SL)
    LDFLAGS_SL          = -shared
  endif
endif
------

LINUX_ELF=no, make a shared library? Does it matter if LINUX_ELF is yes
or no? If we should make a shared library if LINUX_ELF=yes, and yes
only, then this piece should be:

------
ifeq ($(PORTNAME), linux)
  LINUX_ELF=no
  ifeq ($(LINUX_ELF), yes)
    install-shlib-dep   := install-shlib
    shlib               := libpgtcl.so.1
    CFLAGS              += $(CFLAGS_SL)
    LDFLAGS_SL          = -shared
  endif
endif
------

Furthermore, the original patch did *not* correct, (or even attempt to
correct) src/interfaces/libecpg/lib/Makefile(.in), which right now will
not compile a shared library due to LINUX_ELF not being compiled.

As for libpq++, there isn't even a Makefile.in. However, by just copying
postgresql-6.3.2/src/interfaces/libpq++/Makefile to Makefile.in and
patching it like this:

------
20a21,22
> PORTNAME=@PORTNAME@
>
46,49c48,54
<   INSTALL-SHLIB-DEP := install-shlib
<   SHLIB := libpq++.so.1
<   LDFLAGS_SL = -G -z text -shared -soname $(SHLIB)
<   CFLAGS += $(CFLAGS_SL)
---
>   LINUX_ELF=@LINUX_ELF@
>   ifeq ($(LINUX_ELF), yes)
>     INSTALL-SHLIB-DEP := install-shlib
>     SHLIB := libpq++.so.1
>     LDFLAGS_SL = -G -z text -shared -soname $(SHLIB)
>     CFLAGS += $(CFLAGS_SL)
>   endif
------

"src/interfaces/libpq++/Makefile" also needs to be added to the
CONFIG_FILES=... line on line 5937 in configure (patched with the
linux_elf patch). In configure.in it needs to be added to the AC_OUTPUT
(...) line at the end of the file.

This helps me reduce the Makefile mayhem on my system.

- Kris

pgsql-hackers by date:

Previous
From: Jan Vicherek
Date:
Subject: Re: Proposal for async support in libpq
Next
From: Ralph
Date:
Subject: unsubscribe