Move DLSUFFIX from makefiles into header files for all platforms.
Move the DLSUFFIX assignment from src/makefiles/ to src/templates/,
have configure read it, and then substitute it into Makefile.global
and pg_config.h. This avoids the need for all makefile rules that
need it to locally set CPPFLAGS. It also resolves an inconsistent
setup between the two Windows build systems.
Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: https://www.postgresql.org/message-id/2f9861fb-8969-9005-7518-b8e60f2bead9@enterprisedb.com
Rather than define ld_library_path_ver with a big nested $(if), just
put the overriding values in the makefiles for the relevant ports.
Also add a variable for port makefiles to append their own stuff to
with_temp_install, and use it to set LD_LIBRARY_PATH_RPATH=1 on
FreeBSD which is needed to make LD_LIBRARY_PATH override DT_RPATH
if DT_RUNPATH is not set (which seems to depend in unpredictable ways
on the choice of compiler, at least on my system).
Backpatch for the benefit of anyone doing regression tests on FreeBSD.
(For other platforms there should be no functional change.)
It's important for link commands to list *.o input files before -l
switches for libraries, as library code may not get pulled into the link
unless referenced by an earlier command-line entry. This is certainly
necessary for static libraries (.a style). Apparently on some platforms
it is also necessary for shared libraries, as reported by Donald Dong.
We often put -l switches for within-tree libraries into LDFLAGS, meaning
that link commands that list *.o files after LDFLAGS are hazardous.
Most of our link commands got this right, but a few did not. In
particular, places that relied on gmake's default implicit link rule
failed, because that puts LDFLAGS first. Fix that by overriding the
built-in rule with our own. The implicit link rules in
src/makefiles/Makefile.* for single-.o-file shared libraries mostly
got this wrong too, so fix them. I also changed the link rules for the
backend and a couple of other places for consistency, even though they
are not (currently) at risk because they aren't adding any -l switches
to LDFLAGS.
Arguably, the real problem here is that we're abusing LDFLAGS by
putting -l switches in it and we should stop doing that. But changing
that would be quite invasive, so I'm not eager to do so.
Perhaps this is a candidate for back-patching, but so far it seems
that problems can only be exhibited in test code we don't normally
build, and at least some of the problems are new in HEAD anyway.
So I'll refrain for now.
Donald Dong and Tom Lane
Discussion: https://postgr.es/m/CAKABAquXn-BF-vBeRZxhzvPyfMqgGuc74p8BmQZyCFDpyROBJQ@mail.gmail.com
Building a shlib on AIX requires use of the mkldexport.sh script, but we
failed to install that, preventing its use from non-source-tree contexts.
Also, Makefile.aix had the wrong idea about where to find the installed
copy of the postgres.imp symbol file used by AIX.
Per report from John Pierce. Patch all the way back, since this has been
broken since the beginning of PGXS.
Per recommendation from Peter. Neither choice is bulletproof, but this
is the existing style and it does help prevent unexpected environment
variable substitution.
supposing that they should set SHLIB_LINK rather than LDFLAGS_SL. Since these
don't go through Makefile.shlib that was a no-op on most platforms. Also
regularize the few platform-specific Makefiles that did pay attention to
SHLIB_LINK: it seems that the real value of that is to pull in BE_DLLLIBS,
so do that instead. Per buildfarm failures on cygwin.
linking both executables and shared libraries, and we add on LDFLAGS_EX when
linking executables or LDFLAGS_SL when linking shared libraries. This
provides a significantly cleaner way of dealing with link-time switches than
the former behavior. Also, make sure that the various platform-specific
%.so: %.o rules incorporate LDFLAGS and LDFLAGS_SL; most of them missed that
before. (I did not add these variables for the platforms that invoke $(LD)
directly, however. It's not clear if we can do that safely, since for the
most part we assume these variables use CC command-line syntax.)
Per gripe from Aaron Swenson and subsequent investigation.
another section if required by the platform (instead of the old way of
building them in section "l" and always transforming them to the
platform-specific section).
This speeds up the installation on common platforms, and it avoids some
funny business with the man page tools and build process.
has been reinvented about four different times throughout history (aix,
cygwin, win32, darwin/linux) and a lot of the concepts are actually shared,
which the code now shows better.
no evidence that any currently-supported platform needs this, and good
reason to think that any platform that did need it couldn't use the static
libraries anyway --- libpq, at least, has circular references. Removing
the code shuts up tsort warnings about the circular references on some
platforms.
of postgres.imp file into BE_DLLLIBS macro. This makes the AIX build
work more like the Windows and Darwin builds, which have similar requirements
to mention a backend library when linking shared libraries that will be
dynamically loaded into the backend.
> > > > found in the postmaster and not included from elsewhere)
> >
> > shared libs on AIX need to be able to resolve all symbols at linkage time.
> > Those two symbols are in backend/utils/SUBSYS.o but not in the postgres
> > executable.
>
> They are defined in backend/utils/mb/conv.c and declared in
> include/mb/pg_wchar.h. They're also linked into the
> postmaster. I don't see anything unusual.
Attached is a patch to fix the mb linking problems on AIX. As a nice side effect
it reduces the duplicate symbol warnings to linking libpq.so and libecpg.so
(all shlibs that are not postmaster loadable modules).
Please apply to current (only affects AIX).
The _LARGE_FILES problem is unfortunately still open, unless Peter
has fixed it per his recent idea.
Zeugswetter Andreas SB SD
patch is low risc, thus could be applied now, but can also wait for 7.3
Old Makefile shows, that -bnoentry is available since 4.1 .
Andreas Zeugswetter
system. Some systems did not understand the 'l' section, and in general
it wasn't entirely appropriate.
On SCO OpenServer, the man pages won't be installed at all until someone
figures out their man system.
$(CC) $(CFLAGS) $(LDFLAGS) <object files> <extra-libraries> $(LIBS) -o $@
This form seemed to be the most portable, readable, and logical, but in any
case it's better than having a dozen different ones in the tree.
that installs into a different path than is configured.
With this applied both postmaster and the shared libs are location
independent
for AIX 4.2 and up.
Thanks
Andreas
Makefile.port, since they are of no use to configure and much of the
library magic happens in Makefile.port anyway.
Use __alpha, not __alpha__, since the former is universally available.
Remove -DNOFIXADE from the compile command line and put it in the port
include file.
and the fmgr redesign.
It makes the homebrewn dl*() functions for more recent Versions of AIX
obsolete
by using the system dl*() functions instead.
It also fixes the expected file for the horology regression test.
Please regenerate configure from configure.in, I don't have the
environment/time.
Andreas
It does work with the following patch applied and gcc 2.95.2 .
Use --with-template=aix_gcc to compile the whole lot with gcc.
The geometry regression test produces different precision.
With optimization I run into regression failures starting at oidjoins,
thus no -O2. Anybody else try gcc 2.95.2 and -O2 on beta4 ?
This is an important patch, since recent versions of the IBM compiler
are not for free, and thus most questions I get concern gcc.
Andreas
PS.: I am testing with beta4
This patch will...
1. Remove the "-Wall" option from the ecpg/lib and ecpg/preproc Makefile.
2. Remove the addition of $(SRCDIR)/include and-or $(SRCDIR)/backend from
ecpg/lib, ecpg/preproc, libpq and utils Makefiles. Already in CFLAGS...
3. Set MK_NO_LORDER and RANLIB in Makefile.aix to avoid a couple of extra
steps taken care of by the 'ld' command anyways.
Makefile.global and move them to seperate 'include' makefiles
Over time, should become even more port specific:
ie. Makefile.BSD44_derived should be broken down into netbsd/freebsd
specific ports
