Thread: PORTNAME and LINUX_ELF defines in interface Makefiles

I have had problems with LINUX_ELF and/or PORTNAME *not* being defined
and shared libraries *not* being compiled. I would like to make the
following observations, based on the Makefiles generated for a linux
system, with elf, and with glibc v2.06.

The configure command line was:

[/usr/src/postgresql-6.3.2/src]$ ./configure  --host=i586-pc-linux
--prefix=/usr/local/pgsql --enable-locale --with-tcl --with-perl
--with-x --enable-hba

Using the following command, executed from the src directory:

[/usr/src/postgresql-6.3.2/src]$ grep -l "\(PORTNAME\)\|\(LINUX_ELF\)"
`find -regex ".*/.*Makefile\(.custom\|.global\)?"`

I found that the only Makefiles that mention the PORTNAME or LINUX_ELF
defines were the following:

./interfaces/ecpg/lib/Makefile
./interfaces/libpgtcl/Makefile
./interfaces/libpq/Makefile
./interfaces/libpq++/Makefile
./Makefile.custom

Since I created Makefile.custom myself, the other four Makefiles are the
ones to be investigated.

Of the four Makefiles, three of them (libpgtcl, ecpg, libpq) used the
following lines to determine whether a shared library should be build.
(under Linux)

ifeq ($(PORTNAME), linux)
  ifdef LINUX_ELF
    install-shlib-dep := install-shlib
    shlib := libpq.so.$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)
    LDFLAGS_SL = -shared -soname libpq.so.$(SO_MAJOR_VERSION)
    CFLAGS += $(CFLAGS_SL)
  endif
endif

while the other Makefile (libpq++), had the following lines:

ifeq ($(PORTNAME), linux)
  INSTALL-SHLIB-DEP := install-shlib
  SHLIB := libpq++.so.1
  LDFLAGS_SL = -shared -soname $(SHLIB)
  CFLAGS += $(CFLAGS_SL)
endif

The key thing to note is that all four Makefiles require PORTNAME to be
set to 'linux' to compile a shared library, and three of them,
(libpgtcl, ecpg, libpq), also requre LINUX_ELF to be defined, whereas
the other Makefile (libpq++) does not check for this.

In addition, the following define appeared in only three out of the four
Makefiles, the same three that checked for LINUX_ELF to be defined,
(libpq, libpgtcl, ecpg). (Coincidence? I think not.)

PORTNAME=linux

In the Makefile for libpq++, PORTNAME was never defined.

So what this boils down to is, compiling out of the box, libpgtcl.so,
libecpg.so, and libpq.so, will *not* be made because LINUX_ELF is *not*
defined anywhere. However, libpq++.so will *not* be made because
PORTNAME is *not* defined or equal to 'linux'.

As a quick fix, create the file Makefile.custom in the src directory,
(place where Makefile.global lives), and put the following two lines in
it.

LINUX_ELF=true
PORTNAME='linux'

Since Makefile.custom is included by Makefile.global, and thus by every
Makefile in the tree, the interface Makefiles will be happy and make
their shared libraries.

In the future, I would suggest the these two defines be placed into
Makefile.global by the configure program (autoconf). Furthermore, the
Makefiles for libpgtcl, libecpg, and libpq should *not* define PORTNAME,
rather they should rely on PORTNAME being defined in Makefile.global.
The Makefile for libpq++ should to be changed to check for LINUX_ELF
being defined in addition to checking PORTNAME='linux'.

The checks for LINUX_ELF are probably a hold over to the days when
people compiled PostGreSQL on a.out linux boxes with funky, gnarly
shared library support. Perhaps people still do, and if they do,
LINUX_ELF should stay.

I have not played around with autoconf, so I don't know off hand what
would have to be changed to fix this, although I'll take a look if no
one else wants to.

Anyways, if you made it here, I hope you've found something entertaining
and useful. :)

- Kris

PS - I don't know if the other ports have similar Makefile problems, I
have noticed that for BSD libecpg, libpgtcl, and libpq are built shared,
but not libpq++.

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...

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

Kristofer Peterson makes an excellent point.
There seem to be three issues for linux...
  Does the system have ELF capability?  (ld -V or cpp -dM will tell you)
  Is this intended to be an elf build?  (could be compiled for a.out)
  Does the builder want shared (or static, for that matter) libraries?

automake and libtool are intended to solve such problems, but
they present a license conflict.  Or do they, if the tools aren't
included with the public distribution?

Michael
csf@moscow.com


 :}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.
...