Bruce Momjian wrote:
OK, thanks. Next question --- are the installed file locations the same
for a MinGW install and a pginstaller install? I don't think
pginstaller does a MinGW install because it doesn't have the build
environment in the tarball.
However, the big difference seems to be t
Bruce Momjian wrote:
> Andrew Dunstan wrote:
> >
> >
> > Bruce Momjian wrote:
> >
> > >
> > >Could this be related to the fact that pre-8.2 makefiles were not
> > >space-safe? I am unsure how pgxs worked on Win32 without being
> > >space-safe.
> > >
> > >
> > >
> >
> > I don't see how. In fa
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
>
> >
> >Could this be related to the fact that pre-8.2 makefiles were not
> >space-safe? I am unsure how pgxs worked on Win32 without being
> >space-safe.
> >
> >
> >
>
> I don't see how. In fact, pgxs seems to use short form paths anyway.
Bruce Momjian wrote:
Could this be related to the fact that pre-8.2 makefiles were not
space-safe? I am unsure how pgxs worked on Win32 without being
space-safe.
I don't see how. In fact, pgxs seems to use short form paths anyway.
Example (from previous email):
dllwrap -o rainbow.
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>
> >Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >
> >
> >>dllwrap doesn't seem to get given LDFLAGS, and maybe doesn't honor it
> >>either.
> >>
> >>
> >
> >I wouldn't expect it to handle everything that might appear in LDFLAGS,
> >but maybe i
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What's confusing me at the moment is that it seems to work for Magnus.
> Also, he might be working from a later toolset - I have gcc3.2.4 while
> gcc 3.4.2 is the latest mingw release - some other tools might also be
> mildly out of
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
dllwrap doesn't seem to get given LDFLAGS, and maybe doesn't honor it
either.
I wouldn't expect it to handle everything that might appear in LDFLAGS,
but maybe it ought to be given the -L items from LDFLAGS (compare the
way
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> dllwrap doesn't seem to get given LDFLAGS, and maybe doesn't honor it
> either.
I wouldn't expect it to handle everything that might appear in LDFLAGS,
but maybe it ought to be given the -L items from LDFLAGS (compare the
way we copy just those items i
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
So we should probably change $(DESTDIR)$(bindir) to $(libdir) in the
following places:
For the cygwin/win32 cases, shouldn't we just remove the -L flag from
BE_DLLLIBS altogether? It seems redundant given what Makefile.glob
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> So we should probably change $(DESTDIR)$(bindir) to $(libdir) in the
> following places:
For the cygwin/win32 cases, shouldn't we just remove the -L flag from
BE_DLLLIBS altogether? It seems redundant given what Makefile.global
is doing.
In the Darwi
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I doubt DESTDIR is having an effect. From what I can see we hardly use
it so it will mostly be blank:
Yes, it is often an empty string, which doubtless explains how an error
of this sort could sneak in. But I think there's
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I doubt DESTDIR is having an effect. From what I can see we hardly use
> it so it will mostly be blank:
Yes, it is often an empty string, which doubtless explains how an error
of this sort could sneak in. But I think there's no doubt that one or
the o
Tom Lane wrote:
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
As you see, it adds both bin and lib.
Is the bin part even necessary?
It looks to me like the -L for libdir is coming from Makefile.global.in:
# add location of libpgport.a to LDFLAGS
ifdef PGXS
override LDFLAGS := -L$(
Tom Lane wrote:
In general you are supposed to use the same compiler as the installation
was built with. We are not going to try to support other cases ---
CFLAGS are barely the tip of the iceberg of the issues that would arise.
Right down to the version? I kno
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> As you see, it adds both bin and lib.
Is the bin part even necessary?
It looks to me like the -L for libdir is coming from Makefile.global.in:
# add location of libpgport.a to LDFLAGS
ifdef PGXS
override LDFLAGS := -L$(libdir) $(LDFLAGS)
else
overr
Magnus Hagander wrote:
However, libpostgres.a isn't in $(DESTDIR)/$(bindir), it's in
$(DESTDIR)/$(libdir) and when I make that change in the installed
makefile my module builds happily.
My question is: if I make this change will anything else break?
Offhand that seems like it m
> > However, libpostgres.a isn't in $(DESTDIR)/$(bindir), it's in
> > $(DESTDIR)/$(libdir) and when I make that change in the installed
> > makefile my module builds happily.
>
> > My question is: if I make this change will anything else break?
>
> Offhand that seems like it may just be a think
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> However, libpostgres.a isn't in $(DESTDIR)/$(bindir), it's in
> $(DESTDIR)/$(libdir) and when I make that change in the installed
> makefile my module builds happily.
> My question is: if I make this change will anything else break?
Offhand that see
SOme time ago I wrote:
... seems to be behaving oddly:
dllwrap -o rainbow.dll --def rainbow.def rainbow.o
c:/PROGRA~1/POSTGR~1/8.1/lib/pgxs/src/MAKEFI~1/../../src/utils/dllinit.o
-Lc:/PROGRA~1/POSTGR~1/8.1/bin -lpostgres
c:\mingw\bin\..\lib\gcc-lib\mingw32\3.2.3\..\..\..\..\mingw32\bin\ld.exe:
... seems to be behaving oddly:
dllwrap -o rainbow.dll --def rainbow.def rainbow.o
c:/PROGRA~1/POSTGR~1/8.1/lib/pgxs/src/MAKEFI~1/../../src/utils/dllinit.o
-Lc:/PROGRA~1/POSTGR~1/8.1/bin -lpostgres
c:\mingw\bin\..\lib\gcc-lib\mingw32\3.2.3\..\..\..\..\mingw32\bin\ld.exe:
cannot find -lpostgres
s
20 matches
Mail list logo
