Thread: psqlODBC 08.02.0300 doesn't compile
Looks like a header file is missing from the tarball?
gcc -DHAVE_CONFIG_H -I. -I. -I. -I/home/tgl/testversion/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector--param=ssp-buffer-size=4 -m64 -mtune=generic -MT loadlib.lo -MD -MP -MF .deps/loadlib.Tpo -c
loadlib.c -fPIC -DPIC -o .libs/loadlib.o
loadlib.c:19:22: error: pgenlist.h: No such file or directory
make[1]: *** [loadlib.lo] Error 1
regards, tom lane
From: "Tom Lane" <tgl@sss.pgh.pa.us> To: <pgsql-odbc@postgreSQL.org> Sent: Wednesday, April 25, 2007 4:30 AM Subject: [ODBC] psqlODBC 08.02.0300 doesn't compile > Looks like a header file is missing from the tarball? > > gcc -DHAVE_CONFIG_H -I. -I. -I. -I/home/tgl/testversion/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -MT loadlib.lo -MD -MP -MF .deps/loadlib.Tpo -c > loadlib.c -fPIC -DPIC -o .libs/loadlib.o > loadlib.c:19:22: error: pgenlist.h: No such file or directory > make[1]: *** [loadlib.lo] Error 1 Uga.. It is my mistake...I seemed to take the submitted library foolishly and to be different. <sigh..>
Hi Dave... /home/*/psqlODBC08020300 -rw-r--r-- 1 hiroshi users 691861 Apr 24 20:05 psqlodbc-08.02.0300.tar.gz -rw-r--r-- 1 hiroshi users 54396 Apr 24 20:05 psqlodbc-08.02.0300.tar.gz-LOG.txt -rw-r--r-- 1 hiroshi users 65 Apr 24 20:05 psqlodbc-08.02.0300.tar.gz.sig this is gpg detach-sign and make log.. Ahh... Sorry.. It is necessary to renew the library. Should the name do the number in the increment? Regards, Hiroshi Saito ----- Original Message ----- From: "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> To: <pgsql-odbc@postgreSQL.org>; "Tom Lane" <tgl@sss.pgh.pa.us> Sent: Wednesday, April 25, 2007 4:49 AM Subject: Re: [ODBC] psqlODBC 08.02.0300 doesn't compile > From: "Tom Lane" <tgl@sss.pgh.pa.us> > To: <pgsql-odbc@postgreSQL.org> > Sent: Wednesday, April 25, 2007 4:30 AM > Subject: [ODBC] psqlODBC 08.02.0300 doesn't compile > > >> Looks like a header file is missing from the tarball? >> >> gcc -DHAVE_CONFIG_H -I. -I. -I. -I/home/tgl/testversion/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >> -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -MT loadlib.lo -MD -MP -MF .deps/loadlib.Tpo -c >> loadlib.c -fPIC -DPIC -o .libs/loadlib.o >> loadlib.c:19:22: error: pgenlist.h: No such file or directory >> make[1]: *** [loadlib.lo] Error 1 > > Uga.. It is my mistake...I seemed to take the submitted library foolishly and to be different. > <sigh..> > > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly
Hiroshi Saito wrote: > Hi Dave... > > /home/*/psqlODBC08020300 > > -rw-r--r-- 1 hiroshi users 691861 Apr 24 20:05 > psqlodbc-08.02.0300.tar.gz > -rw-r--r-- 1 hiroshi users 54396 Apr 24 20:05 > psqlodbc-08.02.0300.tar.gz-LOG.txt > -rw-r--r-- 1 hiroshi users 65 Apr 24 20:05 > psqlodbc-08.02.0300.tar.gz.sig > > this is gpg detach-sign and make log.. > Ahh... Sorry.. It is necessary to renew the library. > Should the name do the number in the increment? Yes, because the release was announced, I think we should produce 08.02.0400. Don't forget the release notes! BTW; use 'make distcheck' when you build the tarball. That will build it, and then test it to make sure it compiles OK. Regards, Dave.
From: "Dave Page" <dpage@postgresql.org> >> this is gpg detach-sign and make log.. >> Ahh... Sorry.. It is necessary to renew the library. >> Should the name do the number in the increment? > > Yes, because the release was announced, I think we should produce > 08.02.0400. Don't forget the release notes! Thanks!, I apologizes for having publicly caused the trouble due to my failure.:-( However, I firmly continue working. I want to straighten the preparation soon. Then, surely.! > > BTW; use 'make distcheck' when you build the tarball. That will build > it, and then test it to make sure it compiles OK. Yea, Thanks! Regards, Hiroshi Saito
There's another issue with the psqlodbc tarball, which has been there
awhile but I only just realized what it is: you are shipping aclocal.m4,
which is a derived file, without providing the upstream files needed to
recreate it. Specifically, there's no sign of a source file for the
PGAC_xxx macros needed by configure.ac.
This makes life difficult for packagers who need to re-run aclocal
(in my case, because Red Hat ships a different automake version than
you guys are using). I believe it's also a violation of the LGPL.
regards, tom lane
Tom Lane wrote: > There's another issue with the psqlodbc tarball, which has been there > awhile but I only just realized what it is: you are shipping aclocal.m4, > which is a derived file, without providing the upstream files needed to > recreate it. Specifically, there's no sign of a source file for the > PGAC_xxx macros needed by configure.ac. > > This makes life difficult for packagers who need to re-run aclocal > (in my case, because Red Hat ships a different automake version than > you guys are using). I believe it's also a violation of the LGPL. Hmm, thats how Peter designed it for us so we didn't have to have our own copies of all the PG macros iirc. I don't have enough autoconf foo to know how best to fix it though. Peter? Regards, Dave
Dave Page <dpage@postgresql.org> writes:
> Tom Lane wrote:
>> This makes life difficult for packagers who need to re-run aclocal
>> (in my case, because Red Hat ships a different automake version than
>> you guys are using). I believe it's also a violation of the LGPL.
> Hmm, thats how Peter designed it for us so we didn't have to have our
> own copies of all the PG macros iirc. I don't have enough autoconf foo
> to know how best to fix it though. Peter?
Hm, so you're pulling those macros directly from the underlying Postgres
installation? I didn't think they got installed anywhere --- I could do
the same if they are, but not if running aclocal requires access to a
Postgres source tree.
regards, tom lane
Tom Lane wrote: > Dave Page <dpage@postgresql.org> writes: >> Tom Lane wrote: >>> This makes life difficult for packagers who need to re-run aclocal >>> (in my case, because Red Hat ships a different automake version than >>> you guys are using). I believe it's also a violation of the LGPL. > >> Hmm, thats how Peter designed it for us so we didn't have to have our >> own copies of all the PG macros iirc. I don't have enough autoconf foo >> to know how best to fix it though. Peter? > > Hm, so you're pulling those macros directly from the underlying Postgres > installation? I didn't think they got installed anywhere --- I could do > the same if they are, but not if running aclocal requires access to a > Postgres source tree. No, it's built in a pre-configured source tree under src/interfaces. See http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/~checkout~/psqlodbc/psqlodbc/docs/unix-compilation.html?rev=1.4 - the 'Building a distribution' section is the set of instructions that Peter wrote. Regards, Dave.
Dave Page <dpage@postgresql.org> writes: > Tom Lane wrote: >> Hm, so you're pulling those macros directly from the underlying Postgres >> installation? I didn't think they got installed anywhere --- I could do >> the same if they are, but not if running aclocal requires access to a >> Postgres source tree. > No, it's built in a pre-configured source tree under src/interfaces. See > http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/~checkout~/psqlodbc/psqlodbc/docs/unix-compilation.html?rev=1.4 > - the 'Building a distribution' section is the set of instructions that > Peter wrote. Well, this is exactly the problem: the psqlodbc distribution is missing files needed to build from source, ie, the reference to $PGSRC/config in the directions. Since $PGSRC/config is also not installed by Postgres packages, this leaves RPM packagers unable to build psqlodbc according to the rules. The whole thing seems like bad practice anyway, since it's unclear which version of the Postgres sources needs to be used to build any particular psqlodbc release. regards, tom lane
Tom Lane wrote: > Well, this is exactly the problem: the psqlodbc distribution is missing > files needed to build from source, ie, the reference to $PGSRC/config > in the directions. Since $PGSRC/config is also not installed by > Postgres packages, this leaves RPM packagers unable to build psqlodbc > according to the rules. I don't know about the RPM packaging rules, but you can build from source just fine as long as you don't try to regenerate any of the autoconf/automake stuff. The lack of complaints since it started being packaged this way indicate it's not been an issue for the users. > The whole thing seems like bad practice anyway, > since it's unclear which version of the Postgres sources needs to be > used to build any particular psqlodbc release. I've always used whatever is current without any problems, though the docs say to use 7.3 (which, iirc, was about to be released when this was all written). I'm not experienced enough with this stuff to comment on whether it's good or bad practice though; I'll have to leave you and Peter to fight that one out. It can be a pita sometimes though, and it would be nice to have something more self contained. Regards, Dave.
Dave Page <dpage@postgresql.org> writes:
> I don't know about the RPM packaging rules, but you can build from
> source just fine as long as you don't try to regenerate any of the
> autoconf/automake stuff.
Not really an option for me, since I need to insert the same libtool
version that is used on whichever Red Hat distribution I'm building for.
In any case, the other point is that you're failing to distribute the
complete source code as defined by the LGPL license you're using
(ie, the "preferred form of the work for making modifications" ---
derived files ain't it).
Being the authors, you can of course do whatever you want, but it's
arguably illegal for Red Hat or other packagers to redistribute this
package, since we are likewise failing to provide the complete source
code.
regards, tom lane
Tom Lane wrote: > Dave Page <dpage@postgresql.org> writes: >> I don't know about the RPM packaging rules, but you can build from >> source just fine as long as you don't try to regenerate any of the >> autoconf/automake stuff. > > Not really an option for me, since I need to insert the same libtool > version that is used on whichever Red Hat distribution I'm building for. > > In any case, the other point is that you're failing to distribute the > complete source code as defined by the LGPL license you're using > (ie, the "preferred form of the work for making modifications" --- > derived files ain't it). > > Being the authors, you can of course do whatever you want, but it's > arguably illegal for Red Hat or other packagers to redistribute this > package, since we are likewise failing to provide the complete source > code. That's only an issue if we (as copyright holders) should take action of course - which would be a pretty stupid thing to do - but I see your point, and can imagine the nervous ticks your lawyers would probably develop :-) Regards, Dav e.
Am Mittwoch, 25. April 2007 17:16 schrieb Tom Lane: > There's another issue with the psqlodbc tarball, which has been there > awhile but I only just realized what it is: you are shipping aclocal.m4, > which is a derived file, without providing the upstream files needed to > recreate it. Specifically, there's no sign of a source file for the > PGAC_xxx macros needed by configure.ac. It appears that 08.02.0400 doesn't use PGAC macros anymore. However, the configure.ac file looks like a disaster now. -- Peter Eisentraut http://developer.postgresql.org/~petere/