Re: [HACKERS] narwhal and PGDLLIMPORT
(2014/02/12 3:03), Tom Lane wrote: > Hiroshi Inoue writes: >> (2014/02/09 8:06), Andrew Dunstan wrote: >>> Yeah. Incidentally, we didn't quite get rid of dlltool for Cygwin. We >>> did get rid of dllwrap. But I agree this is worth trying for Mingw. > >> I tried MINGW port with the attached change and successfully built >> src and contrib and all pararell regression tests were OK. > > I cleaned this up a bit (the if-nesting in Makefile.shlib was making > my head hurt, not to mention that it left a bunch of dead code) and > committed it. Thanks. > By my count, the only remaining usage of dlltool is in plpython's > Makefile. Can we get rid of that? Maybe this is one of the few use cases of dlltool. Because python doesn't ship with its MINGW import library, the Makefile uses dlltool to generate an import library from the python DLL. > Also, the only remaining usage of dllwrap is in src/bin/pgevent/Makefile. > Do we need that either? Maybe this can be removed. I would make a patch later. regards, Hiroshi Inoue -- I am using the free version of SPAMfighter. SPAMfighter has removed 3597 of my spam emails to date. Get the free SPAMfighter here: http://www.spamfighter.com/len Do you have a slow PC? Try a Free scan http://www.spamfighter.com/SLOW-PCfighter?cid=sigen -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] narwhal and PGDLLIMPORT
(2014/02/12 8:30), Tom Lane wrote: > I wrote: >> Hiroshi Inoue writes: >>> I tried MINGW port with the attached change and successfully built >>> src and contrib and all pararell regression tests were OK. > >> I cleaned this up a bit (the if-nesting in Makefile.shlib was making >> my head hurt, not to mention that it left a bunch of dead code) and >> committed it. > > Hm ... according to buildfarm member narwhal, this doesn't work so well > for plperl: > > gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith > -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute > -Wformat-security -fno-strict-aliasing -fwrapv -g -Wno-comment -shared -o > plperl.dll plperl.o SPI.o Util.o -L../../../src/port -L../../../src/common > -Wl,--allow-multiple-definition -L/mingw/lib -Wl,--as-needed > -LC:/Perl/lib/CORE -lperl58 -L../../../src/backend -lpostgres -lpgcommon > -lpgport -lintl -lxslt -lxml2 -lssleay32 -leay32 -lz -lm -lws2_32 -lshfolder > -Wl,--export-all-symbols -Wl,--out-implib=libplperl.a > Cannot export .idata$4: symbol not found > Cannot export .idata$5: symbol not found > Cannot export .idata$6: symbol not found > Cannot export .text: symbol not found > Cannot export perl58_NULL_THUNK_DATA: symbol not found > Creating library file: libplperl.a > collect2: ld returned 1 exit status > make[3]: *** [plperl.dll] Error 1 Oops I forgot to inclule plperl, tcl or python, sorry. I would retry build operations with them. Unfortunately it would take pretty long time because build operations are pretty (or veeery in an old machine) slow. > Not very clear what's going on there; could this be a problem in > narwhal's admittedly-ancient toolchain? > > BTW, now that I look at this ... why are we bothering to build static > libraries (.a files) for DLLs? They have no possible use AFAICS. They are import libraries though I doubt such plugins need them. regards, Hiroshi Inoue -- I am using the free version of SPAMfighter. SPAMfighter has removed 3592 of my spam emails to date. Get the free SPAMfighter here: http://www.spamfighter.com/len Do you have a slow PC? Try a Free scan http://www.spamfighter.com/SLOW-PCfighter?cid=sigen -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] narwhal and PGDLLIMPORT
(2014/02/10 22:42), Hiroshi Inoue wrote: (2014/02/09 8:06), Andrew Dunstan wrote: On 02/08/2014 05:34 PM, Tom Lane wrote: Hiroshi Inoue writes: Though I'm not a MINGW expert at all, I know dllwrap is a deprecated tool and dlltool is almost a deprecated tool. Cygwin port is removing the use of dllwrap and dlltool now. Isn't it better for MINGW port to follow it? Only way to make that happen is to prepare and test a patch ... Yeah. Incidentally, we didn't quite get rid of dlltool for Cygwin. We did get rid of dllwrap. But I agree this is worth trying for Mingw. I tried MINGW port with the attached change and successfully built src and contrib and all pararell regression tests were OK. I forgot to mention the environment. I tried the change in 2 machines and both worked. 1. 32bit Windows7 GCC 4.6.1 2. 32bit Windows Vista GCC 3.4.5 I didn't test 64bit platform. regards, Hiroshi Inoue -- I am using the free version of SPAMfighter. SPAMfighter has removed 3567 of my spam emails to date. Get the free SPAMfighter here: http://www.spamfighter.com/len Do you have a slow PC? Try a Free scan http://www.spamfighter.com/SLOW-PCfighter?cid=sigen -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [ODBC] getting rid of SnapshotNow
(2013/07/18 23:54), Robert Haas wrote: On Thu, Jul 18, 2013 at 10:34 AM, Tom Lane wrote: Robert Haas writes: 1. snapshot-error-v1.patch introduces a new special snapshot, called SnapshotError. In the cases where we set SnapshotNow as a sort of default snapshot, this patch changes the code to use SnapshotError instead. This affects scan->xs_snapshot in genam.c and estate->es_snapshot in execUtils.c. This passes make check-world, so apparently there is no code in the core distribution that does this. However, this is safer for third-party code, which will ERROR instead of seg faulting. The alternative approach would be to use InvalidSnapshot, which I think would be OK too if people dislike this approach. FWIW, I think using InvalidSnapshot would be preferable to introducing a new concept for what's pretty much the same thing. Andres voted the other way on the previous thread. I'll wait and see if there are any other opinions. The SnapshotError concept seemed attractive to me initially, but I'm not as excited about it after seeing how it turned out, so maybe it's best to do it as you suggest. With that done, the only remaining uses of SnapshotNow in our code base will be in currtid_byreloid() and currtid_byrelname(). So far no one on this list has been able to understand clearly what the purpose of those functions is, so I'm copying this email to pgsql-odbc in case someone there can provide more insight. I had the idea they were used for a client-side implementation of WHERE CURRENT OF. Perhaps that's dead code and could be removed entirely? It's been reported that ODBC still uses them. Though PostgreSQL's TID is similar to Orale's ROWID, it is transient and changed after update operations unfortunately. I implemented the currtid_xx functions to supplement the difference. For example currtid(relname, original tid) (hopefully) returns the current tid of the original row when it is updated. regards, Hiroshi Inoue -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] setlocale() and gettext on Windows revisited
HI all, (2011/09/01 4:30), Heikki Linnakangas wrote: Back in January/February, a patch was committed to avoid using libintl's version of setlocale: http://archives.postgresql.org/pgsql-hackers/2011-01/msg02628.php The comment says it was about a problem with printf() and friends, so I wonder, why was that "#undef setlocale" line put inside the larger "#ifdef USE_REPL_SNPRINTF" block? If I understand the problem correctly, it has nothing to do with our replacement snprintf() function. Fortunately, we always use the replacement snprintf() code on Windows, so there's no user-visible bug here, but if you imagine that we didn't USE_REPL_SNPRINTF on Windows, we would still want the "#undef setlocale" to take effect, right? I think that block is misplaced. Yes you are right. I didn't notice "#ifdef USE_REPL_SNPRINTF" unfortunately. The "#undef setlocale" line should be placed outside the "ifdef USE_REPL_SNPRINTF" block. regards, Hiroshi Inoue -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
