From boris at codesynthesis.com Tue Mar 1 08:33:53 2022 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Mar 1 08:30:40 2022 Subject: [odb-users] ODB for C++20 In-Reply-To: References: Message-ID: Abdalla Ahmed writes: > Are there any future plans for such support? We've added[1] support for --std=c++20 for the next beta. I can show you how to get it using the staging package repository if you are keen to start using it (but see below). > If not , Do I have to Completely refactor the source code so it > can be used along with C++20 ? The current beta[2] supports --std=c++17. Have you tried to run the ODB compiler in this mode on your headers? Chances are no refactoring will be necessary unless you use something C++20-only (in which case the staged version mentioned above would probably be your best option). [1] https://git.codesynthesis.com/cgit/odb/odb/commit/?id=a3592b51221a614de21aad20eeed69d8d13e83a8 [2] https://codesynthesis.com/products/odb/doc/install-build2.xhtml From phillip.shelton at cardno.com.au Fri Mar 11 17:47:56 2022 From: phillip.shelton at cardno.com.au (Phillip Shelton) Date: Mon Mar 14 09:05:39 2022 Subject: [odb-users] compiling odb library In-Reply-To: References: Message-ID: Hi, Thank you for your time. I now have a working version of build2. >C:\compilers\odb_build>bpkg --version >bpkg 0.14.0 >libbpkg 0.14.0 >libbutl 0.14.0 >Copyright (c) 2014-2021 the build2 authors. >This is free software released under the MIT license. I have now tried to follow your last email about odb, and I get the following >C:\compilers\odb_build\obd-mingw>bpkg build odb-2.5.0-b.21.tar.gz libcutl-1.11.0-b.9.tar.gz libstudxml-1.1.0-b.10.tar.gz >error: unknown dependency libstudxml ^1.1.0- of package odb >info: while satisfying odb/2.5.0-b.21 Am I using the wrong libstudxml? Have I misread the supplied links? Phillip Shelton Senior Transport Modeller Cardno Phone +61 7 3877 6991 Address Level 11, 515 St Paul's Terrace, Fortitude Valley, 4006 Queensland Australia Postal Locked Bag 4006, Fortitude Valley 4006 Email phillip.shelton@cardno.com.au Web www.cardno.com Cardno operates a quality management system that has been certified to ISO 9001. This email and its attachments may contain confidential and/or privileged information for the sole use of the intended recipient(s). All electronically supplied data must be checked against an applicable hardcopy version which shall be the only document for which Cardno warrants accuracy. If you are not the intended recipient, any use, distribution or copying of the information contained in this email and its attachments is strictly prohibited. If you have received this email in error, please email the sender by replying to this message and immediately delete and destroy any copies of this email and any attachments. The views or opinions expressed are the author's own and may not reflect the views or opinions of Cardno. -----Original Message----- From: Boris Kolpackov Sent: Friday, 25 February 2022 2:12 AM To: Phillip Shelton Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] compiling odb library Phillip Shelton writes: > I am hoping to be able to use odb for a project on Windows 10 compiled > with MinGW. > > Do you have CMake or build2 recipes for building the odb and > odb-sqlite libs? Yes, you should be able to use the build2 instructions (Windows section): https://urldefense.com/v3/__https://codesynthesis.com/products/odb/doc/install-build2.xhtml__;!!PwxmruxY!LVGqHx5IL5zf3P52Ix5IORA5MRX1hVzvbmtOWJccYXAyUYI9cvqj0ahElbzQGuabE0Wc7t0$ Preempting the question about building without network access (based on our exchange on the build2 mailing list), you should be able to pre-download the archives (including dependencies) and build from that. For details, see: https://urldefense.com/v3/__https://www.codesynthesis.com/pipermail/odb-users/2021-October/004698.html__;!!PwxmruxY!LVGqHx5IL5zf3P52Ix5IORA5MRX1hVzvbmtOWJccYXAyUYI9cvqj0ahElbzQGuaba_3lzAU$ https://urldefense.com/v3/__https://www.codesynthesis.com/pipermail/odb-users/2021-October/004700.html__;!!PwxmruxY!LVGqHx5IL5zf3P52Ix5IORA5MRX1hVzvbmtOWJccYXAyUYI9cvqj0ahElbzQGuabV2AzfSg$ From boris at codesynthesis.com Mon Mar 14 09:24:54 2022 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Mar 14 09:21:29 2022 Subject: [odb-users] compiling odb library In-Reply-To: References: Message-ID: Phillip Shelton writes: > I now have a working version of build2. > > >C:\compilers\odb_build>bpkg --version > >bpkg 0.14.0 > >libbpkg 0.14.0 > >libbutl 0.14.0 Great! Thanks for sticking with it, wasn't exactly a smooth experience. > I have now tried to follow your last email about odb, and I get the > following > > >C:\compilers\odb_build\obd-mingw>bpkg build odb-2.5.0-b.21.tar.gz libcutl-1.11.0-b.9.tar.gz libstudxml-1.1.0-b.10.tar.gz > >error: unknown dependency libstudxml ^1.1.0- of package odb > >info: while satisfying odb/2.5.0-b.21 I tried this and I get the same error, which feels wrong. I've filed an issue[1] to look into this. As a work around, building them one by one in the correct order worked for me: $ bpkg build libstudxml-1.1.0-b.10.tar.gz $ bpkg build libcutl-1.11.0-b.9.tar.gz $ bpkg build odb-2.5.0-b.21.tar.gz [1] https://github.com/build2/build2/issues/183 From phillip.shelton at cardno.com.au Tue Mar 15 05:51:32 2022 From: phillip.shelton at cardno.com.au (Phillip Shelton) Date: Tue Mar 15 06:24:31 2022 Subject: [odb-users] compiling odb library In-Reply-To: References: Message-ID: Thanks. I now have a odb compiler installed. >C:\compilers\odb_build\obd-mingw>odb --version >ODB object-relational mapping (ORM) compiler for C++ 2.5.0-b.21 >Copyright (c) 2009-2021 Code Synthesis Tools CC. >This is free software; see the source for copying conditions. There is NO >warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. However I was not able to build either build2 or the odb compiler with the mingw from winlib.com. >C:\compilers\odb_build\obd-mingw>c:\compilers\mingw64\bin\g++ --version >g++ (MinGW-W64 x86_64-ucrt-posix-seh, built by Brecht Sanders) 11.2.0 Now to compile the libodb, libodb-sqlite and libsqlite3. I am really hopping I can compile with the the compiler from winlib.com. Phillip Shelton Senior Transport Modeller Cardno Phone +61 7 3877 6991 Address Level 11, 515 St Paul's Terrace, Fortitude Valley, 4006 Queensland Australia Postal Locked Bag 4006, Fortitude Valley 4006 Email phillip.shelton@cardno.com.au Web www.cardno.com Cardno operates a quality management system that has been certified to ISO 9001. This email and its attachments may contain confidential and/or privileged information for the sole use of the intended recipient(s). All electronically supplied data must be checked against an applicable hardcopy version which shall be the only document for which Cardno warrants accuracy. If you are not the intended recipient, any use, distribution or copying of the information contained in this email and its attachments is strictly prohibited. If you have received this email in error, please email the sender by replying to this message and immediately delete and destroy any copies of this email and any attachments. The views or opinions expressed are the author's own and may not reflect the views or opinions of Cardno. -----Original Message----- From: Boris Kolpackov Sent: Monday, 14 March 2022 11:25 PM To: Phillip Shelton Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] compiling odb library Phillip Shelton writes: > I now have a working version of build2. > > >C:\compilers\odb_build>bpkg --version bpkg 0.14.0 libbpkg 0.14.0 > >libbutl 0.14.0 Great! Thanks for sticking with it, wasn't exactly a smooth experience. > I have now tried to follow your last email about odb, and I get the > following > > >C:\compilers\odb_build\obd-mingw>bpkg build odb-2.5.0-b.21.tar.gz > >libcutl-1.11.0-b.9.tar.gz libstudxml-1.1.0-b.10.tar.gz > >error: unknown dependency libstudxml ^1.1.0- of package odb > >info: while satisfying odb/2.5.0-b.21 I tried this and I get the same error, which feels wrong. I've filed an issue[1] to look into this. As a work around, building them one by one in the correct order worked for me: $ bpkg build libstudxml-1.1.0-b.10.tar.gz $ bpkg build libcutl-1.11.0-b.9.tar.gz $ bpkg build odb-2.5.0-b.21.tar.gz [1] https://urldefense.com/v3/__https://github.com/build2/build2/issues/183__;!!PwxmruxY!LhphpOl2vbXwWOjIVxk61Pd-XL83ih3bOAfQxv5lFn-vvp-EOOGtUBMVwFiGLulq1wBo8vA$ From phillip.shelton at cardno.com.au Tue Mar 15 06:08:34 2022 From: phillip.shelton at cardno.com.au (Phillip Shelton) Date: Tue Mar 15 06:24:31 2022 Subject: [odb-users] compiling odb library In-Reply-To: References: Message-ID: Hmm. Not what I had hopped. C:\compilers\odb_build>where g++ c:\compilers\mingw64\bin\g++.exe c:\compilers\build2\bin\g++.exe C:\compilers\odb_build>bpkg create -d libodb-mingw-release cc config.cxx=g++ config.cc.coptions=-02 config.install.root=c:\compilers\odb\release --wipe terminate called after throwing an instance of 'butl::invalid_basic_path' what(): invalid filesystem path what should I do to help you track down my issue. Phillip Shelton Senior Transport Modeller Cardno Phone +61 7 3877 6991 Address Level 11, 515 St Paul's Terrace, Fortitude Valley, 4006 Queensland Australia Postal Locked Bag 4006, Fortitude Valley 4006 Email phillip.shelton@cardno.com.au Web www.cardno.com Cardno operates a quality management system that has been certified to ISO 9001. This email and its attachments may contain confidential and/or privileged information for the sole use of the intended recipient(s). All electronically supplied data must be checked against an applicable hardcopy version which shall be the only document for which Cardno warrants accuracy. If you are not the intended recipient, any use, distribution or copying of the information contained in this email and its attachments is strictly prohibited. If you have received this email in error, please email the sender by replying to this message and immediately delete and destroy any copies of this email and any attachments. The views or opinions expressed are the author's own and may not reflect the views or opinions of Cardno. -----Original Message----- From: Phillip Shelton Sent: Tuesday, 15 March 2022 7:52 PM To: odb-users@codesynthesis.com Subject: RE: [odb-users] compiling odb library Thanks. I now have a odb compiler installed. >C:\compilers\odb_build\obd-mingw>odb --version ODB object-relational >mapping (ORM) compiler for C++ 2.5.0-b.21 Copyright (c) 2009-2021 Code >Synthesis Tools CC. >This is free software; see the source for copying conditions. There is >NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. However I was not able to build either build2 or the odb compiler with the mingw from winlib.com. >C:\compilers\odb_build\obd-mingw>c:\compilers\mingw64\bin\g++ --version >g++ (MinGW-W64 x86_64-ucrt-posix-seh, built by Brecht Sanders) 11.2.0 Now to compile the libodb, libodb-sqlite and libsqlite3. I am really hopping I can compile with the the compiler from winlib.com. Phillip Shelton Senior Transport Modeller Cardno Phone +61 7 3877 6991 Address Level 11, 515 St Paul's Terrace, Fortitude Valley, 4006 Queensland Australia Postal Locked Bag 4006, Fortitude Valley 4006 Email phillip.shelton@cardno.com.au Web www.cardno.com Cardno operates a quality management system that has been certified to ISO 9001. This email and its attachments may contain confidential and/or privileged information for the sole use of the intended recipient(s). All electronically supplied data must be checked against an applicable hardcopy version which shall be the only document for which Cardno warrants accuracy. If you are not the intended recipient, any use, distribution or copying of the information contained in this email and its attachments is strictly prohibited. If you have received this email in error, please email the sender by replying to this message and immediately delete and destroy any copies of this email and any attachments. The views or opinions expressed are the author's own and may not reflect the views or opinions of Cardno. -----Original Message----- From: Boris Kolpackov Sent: Monday, 14 March 2022 11:25 PM To: Phillip Shelton Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] compiling odb library Phillip Shelton writes: > I now have a working version of build2. > > >C:\compilers\odb_build>bpkg --version bpkg 0.14.0 libbpkg 0.14.0 > >libbutl 0.14.0 Great! Thanks for sticking with it, wasn't exactly a smooth experience. > I have now tried to follow your last email about odb, and I get the > following > > >C:\compilers\odb_build\obd-mingw>bpkg build odb-2.5.0-b.21.tar.gz > >libcutl-1.11.0-b.9.tar.gz libstudxml-1.1.0-b.10.tar.gz > >error: unknown dependency libstudxml ^1.1.0- of package odb > >info: while satisfying odb/2.5.0-b.21 I tried this and I get the same error, which feels wrong. I've filed an issue[1] to look into this. As a work around, building them one by one in the correct order worked for me: $ bpkg build libstudxml-1.1.0-b.10.tar.gz $ bpkg build libcutl-1.11.0-b.9.tar.gz $ bpkg build odb-2.5.0-b.21.tar.gz [1] https://urldefense.com/v3/__https://github.com/build2/build2/issues/183__;!!PwxmruxY!LhphpOl2vbXwWOjIVxk61Pd-XL83ih3bOAfQxv5lFn-vvp-EOOGtUBMVwFiGLulq1wBo8vA$ From boris at codesynthesis.com Tue Mar 15 06:38:50 2022 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Mar 15 06:35:26 2022 Subject: [odb-users] compiling odb library In-Reply-To: References: Message-ID: Phillip Shelton writes: > C:\compilers\odb_build>where g++ > c:\compilers\mingw64\bin\g++.exe > c:\compilers\build2\bin\g++.exe > > C:\compilers\odb_build>bpkg create -d libodb-mingw-release cc config.cxx=g++ config.cc.coptions=-02 config.install.root=c:\compilers\odb\release --wipe This should work. > terminate called after throwing an instance of 'butl::invalid_basic_path' > what(): invalid filesystem path Hm, I wonder if it's something in the output of your MinGW GCC that trips build2 up. Can you try this in some temporary directory: > bdep new -t exe hello > b hello\ config.cxx=g++.exe If you get the same error, can you send the output of the following command (they are executed by build2 underneath to query various compiler properties): > g++ -v > g++ -print-multiarch > g++ -dumpmachine > echo // >dummy > g++ -x c++ -E - Hi, I have a db object with a member that is a set of strings and I like to create a odb::sqlite::database::query which given a string returns all objects that contains that string in there set. This is how my object looks like: #pragma db object struct person { #pragma db id auto unsigned id_; std::string name_; std::set emails_; } I can then easily query on name like this: db.query(odb::query::name == "John"); which return all the persons with name John. But is there a similar way to get all the persons with a specific email? I tried using odb::query:: emails but this is undefined. Thanks in advance, Stef From phillip.shelton at cardno.com.au Tue Mar 15 17:54:49 2022 From: phillip.shelton at cardno.com.au (Phillip Shelton) Date: Wed Mar 16 07:31:10 2022 Subject: [odb-users] compiling odb library In-Reply-To: References: Message-ID: Hi, Thank you for your continued help. Following the instructions in your last reply: I created a new empty directory >C:\compilers>md hello > >C:\compilers>cd hello >From within that directory, I created a new project and tried to set the config. >C:\compilers\hello>bdep new -t exe hello >created new executable project hello in C:\compilers\hello\hello\ > >C:\compilers\hello>b hello\ config.cxx=g++.exe >terminate called after throwing an instance of 'butl::invalid_basic_path' > what(): invalid filesystem path It failed with the same error. So I then ran the check commands. First it is the version information. >C:\compilers\hello>g++ -v >Using built-in specs. >COLLECT_GCC=g++ >COLLECT_LTO_WRAPPER=c:/compilers/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/11.2.0/lto-wrapper.exe >OFFLOAD_TARGET_NAMES=nvptx-none >Target: x86_64-w64-mingw32 >Configured with: ../configure --prefix=/R/winlibs64_stage/inst_gcc-11.2.0/share/gcc --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --enable-offload-targets=nvptx-none --with-pkgversion='MinGW-W64 x86_64-ucrt-posix-seh, built by Brecht Sanders' --with-tune=generic --enable-checking=release --enable-threads=posix --disable-sjlj-exceptions --disable-libunwind-exceptions --disable-serial-configure --disable-bootstrap --enable-host-shared --enable-plugin --disable-default-ssp --disable-rpath --enable-libstdcxx-pch --enable-libstdcxx-time=yes --disable-libstdcxx-debug --disable-version-specific-runtime-libs --with-stabs --disable-symvers --enable-languages=c,c++,fortran,lto,objc,obj-c++,d,jit --disable-gold --disable-nls --disable-stage1-checking --disable-win32-registry --disable-multilib --enable-ld --enable-libquadmath --enable-libada --enable-libssp --enable-libstdcxx --enable-lto --enable-fully-dynamic-string --enable-libgomp --enable-graphite --enable-mingw-wildcard --with-mpc=/d/Prog/winlibs64_stage/custombuilt --with-mpfr=/d/Prog/winlibs64_stage/custombuilt --with-gmp=/d/Prog/winlibs64_stage/custombuilt --with-isl=/d/Prog/winlibs64_stage/custombuilt --enable-install-libiberty --enable-__cxa_atexit --without-included-gettext --with-diagnostics-color=auto --enable-clocale=generic --with-libiconv --with-system-zlib --with-build-sysroot=/R/winlibs64_stage/gcc-11.2.0/build_mingw/mingw-w64 CFLAGS=-I/d/Prog/winlibs64_stage/custombuilt/include/libdl-win32 >Thread model: posix >Supported LTO compression algorithms: zlib zstd >gcc version 11.2.0 (MinGW-W64 x86_64-ucrt-posix-seh, built by Brecht Sanders) Then it was print-multiarch, which returned only a newline. (file paths on windows need to contain at least one non-white space character.) >C:\compilers\hello>g++ -print-multiarch > Then it was dumpmachine, and this returned the 'Target' from the version data. >C:\compilers\hello>g++ -dumpmachine >x86_64-w64-mingw32 Then I created a test file with an empty comment as its only contents. And tried to compile it as a c++ file, while asking the compiler to only run the pre-processor and write the processed output to the terminal. (I think that is what that set of parameters means) >C:\compilers\hello>echo // >dummy > >C:\compilers\hello>g++ -x c++ -E - cc1plus.exe: warning: is shorter than expected ># 0 "" ># 0 "" ># 0 "" ># 1 "" Should I run the same set of commands using the build2 gcc compiler? Phillip Shelton Senior Transport Modeller Cardno Phone +61 7 3877 6991 Address Level 11, 515 St Paul's Terrace, Fortitude Valley, 4006 Queensland Australia Postal Locked Bag 4006, Fortitude Valley 4006 Email phillip.shelton@cardno.com.au Web www.cardno.com Cardno operates a quality management system that has been certified to ISO 9001. This email and its attachments may contain confidential and/or privileged information for the sole use of the intended recipient(s). All electronically supplied data must be checked against an applicable hardcopy version which shall be the only document for which Cardno warrants accuracy. If you are not the intended recipient, any use, distribution or copying of the information contained in this email and its attachments is strictly prohibited. If you have received this email in error, please email the sender by replying to this message and immediately delete and destroy any copies of this email and any attachments. The views or opinions expressed are the author's own and may not reflect the views or opinions of Cardno. -----Original Message----- From: Boris Kolpackov Sent: Tuesday, 15 March 2022 8:39 PM To: Phillip Shelton Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] compiling odb library Phillip Shelton writes: > C:\compilers\odb_build>where g++ > c:\compilers\mingw64\bin\g++.exe > c:\compilers\build2\bin\g++.exe > > C:\compilers\odb_build>bpkg create -d libodb-mingw-release cc > config.cxx=g++ config.cc.coptions=-02 > config.install.root=c:\compilers\odb\release --wipe This should work. > terminate called after throwing an instance of 'butl::invalid_basic_path' > what(): invalid filesystem path Hm, I wonder if it's something in the output of your MinGW GCC that trips build2 up. Can you try this in some temporary directory: > bdep new -t exe hello > b hello\ config.cxx=g++.exe If you get the same error, can you send the output of the following command (they are executed by build2 underneath to query various compiler properties): > g++ -v > g++ -print-multiarch > g++ -dumpmachine > echo // >dummy > g++ -x c++ -E - References: Message-ID: Phillip Shelton writes: > > C:\compilers\hello>b hello\ config.cxx=g++.exe > > terminate called after throwing an instance of 'butl::invalid_basic_path' > > what(): invalid filesystem path > > It failed with the same error. Ok, that's good, I feel like we are getting close. Could you re-run the above command with --verbose=3: > b hello\ config.cxx=g++.exe --verbose=3 Also, could you run the following two commands (I suspect the output from one of them is the culprit): > g++.exe -std=c++2a -print-search-dirs > g++.exe -std=c++2a -x c++ -v -E - References: Message-ID: stefano dalbosco writes: > I have a db object with a member that is a set of strings and I like > to create a odb::sqlite::database::query which given a string returns > all objects that contains that string in there set. > > This is how my object looks like: > > #pragma db object > struct person > { > #pragma db id auto > unsigned id_; > > std::string name_; > std::set emails_; > } > > I can then easily query on name like this: > db.query(odb::query::name == "John"); > which return all the persons with name John. But is there a similar way > to get all the persons with a specific email? Using containers in query conditions is not yet supported except in a few limited cases. Currently the only straightforward way to achieve this is to "drop down" to SQL with a native view. (The not straightforward way would be to try to map an object relationship to the container's table and use that in the query condition). You can find previous discussion of this topic by searching for query+container in archives: https://www.codesynthesis.com/pipermail/odb-users/ From phillip.shelton at cardno.com.au Wed Mar 16 18:22:08 2022 From: phillip.shelton at cardno.com.au (Phillip Shelton) Date: Thu Mar 17 01:53:59 2022 Subject: [odb-users] compiling odb library In-Reply-To: References: Message-ID: Hi, Thank you for your continued attention to my problem. So I reran the first command with the addition of --verbose=3 >C:\compilers\hello>b hello\ config.cxx=g++.exe --verbose=3 >git --exec-path=c:\compilers\build2\bin -C C:\compilers\hello\hello status --porcelain >git --exec-path=c:\compilers\build2\bin -C C:\compilers\hello\hello cat-file commit HEAD >g++.exe -v >g++.exe -print-multiarch >g++.exe -dumpmachine >g++.exe -x c++ -E - >bin hello@C:\compilers\hello\hello\ > target x86_64-w64-mingw32 >ar --version >bin.ar hello@C:\compilers\hello\hello\ > ar ar@c:\compilers\mingw64\bin\ar.exe > id gnu > version 2.37.0 > major 2 > minor 37 > patch 0 > signature GNU ar (Binutils for MinGW-W64 x86_64, built by Brecht Sanders) 2.37 > checksum 8b18fcf21c014384bee439d72372acdd72d46a303f085093f9b8d9c73ae48fd9 >windres --version >bin.rc hello@C:\compilers\hello\hello\ > rc windres@c:\compilers\mingw64\bin\windres.exe > id gnu > signature GNU windres (Binutils for MinGW-W64 x86_64, built by Brecht Sanders) 2.37 > checksum 9849d35468adb4b53e9f6c57dc458a13cdab51c447a945ab6c34b6a2cc68137e >g++.exe -std=c++23 -print-search-dirs >terminate called after throwing an instance of 'butl::invalid_basic_path' > what(): invalid filesystem path And it seems to bear out your concern with -print-search-dirs. C:\compilers\hello>g++.exe -std=c++23 -print-search-dirs install: c:\compilers\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.2.0/ programs: =c:/compilers/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/11.2.0/;c:/compilers/mingw64/bin/../libexec/gcc/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/11.2.0/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ libraries: =c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/;c:/compilers/mingw64/bin/../lib/gcc/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/11.2.0/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/lib/../lib/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../x86_64-w64-mingw32/11.2.0/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../lib/;/mingw/lib/x86_64-w64-mingw32/11.2.0/;/mingw/lib/../lib/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/lib/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../;/mingw/lib/ C:\compilers\hello>g++.exe -std=c++2a -print-search-dirs install: c:\compilers\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.2.0/ programs: =c:/compilers/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/11.2.0/;c:/compilers/mingw64/bin/../libexec/gcc/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/11.2.0/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ libraries: =c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/;c:/compilers/mingw64/bin/../lib/gcc/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/11.2.0/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/lib/../lib/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../x86_64-w64-mingw32/11.2.0/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../lib/;/mingw/lib/x86_64-w64-mingw32/11.2.0/;/mingw/lib/../lib/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/lib/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../;/mingw/lib/ Okay, it doesn't seem to matter if I use c++2a or c++23. That was one of my concerns after seeing the result of the --verbose=3 output. But I am not sure that I should be seeing ;/mingw/lib/ in either of them. That sounds like it would be trying to find a root directory called mingw in whatever drive was current for the build. Which I know I don't have. And, >C:\compilers\hello>g++.exe -std=c++2a -x c++ -v -E - The system cannot find the file specified. I assumed you meant the comment only file I created yesterday. >C:\compilers\hello>g++.exe -std=c++2a -x c++ -v -E - Using built-in specs. >COLLECT_GCC=g++.exe >OFFLOAD_TARGET_NAMES=nvptx-none >Target: x86_64-w64-mingw32 >Configured with: ../configure --prefix=/R/winlibs64_stage/inst_gcc-11.2.0/share/gcc --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --enable-offload-targets=nvptx-none --with-pkgversion='MinGW-W64 x86_64-ucrt-posix-seh, built by Brecht Sanders' --with-tune=generic --enable-checking=release --enable-threads=posix --disable-sjlj-exceptions --disable-libunwind-exceptions --disable-serial-configure --disable-bootstrap --enable-host-shared --enable-plugin --disable-default-ssp --disable-rpath --enable-libstdcxx-pch --enable-libstdcxx-time=yes --disable-libstdcxx-debug --disable-version-specific-runtime-libs --with-stabs --disable-symvers --enable-languages=c,c++,fortran,lto,objc,obj-c++,d,jit --disable-gold --disable-nls --disable-stage1-checking --disable-win32-registry --disable-multilib --enable-ld --enable-libquadmath --enable-libada --enable-libssp --enable-libstdcxx --enable-lto --enable-fully-dynamic-string --enable-libgomp --enable-graphite --enable-mingw-wildcard --with-mpc=/d/Prog/winlibs64_stage/custombuilt --with-mpfr=/d/Prog/winlibs64_stage/custombuilt --with-gmp=/d/Prog/winlibs64_stage/custombuilt --with-isl=/d/Prog/winlibs64_stage/custombuilt --enable-install-libiberty --enable-__cxa_atexit --without-included-gettext --with-diagnostics-color=auto --enable-clocale=generic --with-libiconv --with-system-zlib --with-build-sysroot=/R/winlibs64_stage/gcc-11.2.0/build_mingw/mingw-w64 CFLAGS=-I/d/Prog/winlibs64_stage/custombuilt/include/libdl-win32 >Thread model: posix >Supported LTO compression algorithms: zlib zstd >gcc version 11.2.0 (MinGW-W64 x86_64-ucrt-posix-seh, built by Brecht Sanders) >COLLECT_GCC_OPTIONS='-std=c++20' '-v' '-E' '-shared-libgcc' '-mtune=generic' '-march=x86-64' > c:/compilers/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/11.2.0/cc1plus.exe -E -quiet -v -iprefix c:\compilers\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.2.0/ -D_REENTRANT - -mtune=generic -march=x86-64 -std=c++20 -dumpbase - >ignoring duplicate directory "c:/compilers/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../include/c++/11.2.0" >ignoring duplicate directory "c:/compilers/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../include/c++/11.2.0/x86_64-w64-mingw32" >ignoring duplicate directory "c:/compilers/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../include/c++/11.2.0/backward" >ignoring duplicate directory "c:/compilers/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.2.0/include" >ignoring nonexistent directory "R:/winlibs64_stage/inst_gcc-11.2.0/share/gcc/include" >ignoring nonexistent directory "/R/winlibs64_stage/inst_gcc-11.2.0/share/gcc/include" >ignoring duplicate directory "c:/compilers/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.2.0/include-fixed" >ignoring duplicate directory "c:/compilers/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/include" >ignoring nonexistent directory "/mingw/include" >#include "..." search starts here: >#include <...> search starts here: > c:\compilers\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../include/c++/11.2.0 > c:\compilers\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../include/c++/11.2.0/x86_64-w64-mingw32 > c:\compilers\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../include/c++/11.2.0/backward > c:\compilers\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.2.0/include > c:\compilers\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../include > c:\compilers\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.2.0/include-fixed > c:\compilers\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/include >End of search list. >cc1plus.exe: warning: is shorter than expected ># 0 "" ># 0 "" ># 0 "" ># 1 "" >COMPILER_PATH=c:/compilers/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/11.2.0/;c:/compilers/mingw64/bin/../libexec/gcc/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ >LIBRARY_PATH=c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/;c:/compilers/mingw64/bin/../lib/gcc/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/lib/../lib/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../lib/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/lib/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../ >COLLECT_GCC_OPTIONS='-std=c++20' '-v' '-E' '-shared-libgcc' '-mtune=generic' '-march=x86-64' I am glad to see that compiler is prepared to ignore the non-existent directories. I must admit I am not sure what I am look for here. Phillip Shelton Senior Transport Modeller Cardno Phone +61 7 3877 6991 Address Level 11, 515 St Paul's Terrace, Fortitude Valley, 4006 Queensland Australia Postal Locked Bag 4006, Fortitude Valley 4006 Email phillip.shelton@cardno.com.au Web www.cardno.com Cardno operates a quality management system that has been certified to ISO 9001. This email and its attachments may contain confidential and/or privileged information for the sole use of the intended recipient(s). All electronically supplied data must be checked against an applicable hardcopy version which shall be the only document for which Cardno warrants accuracy. If you are not the intended recipient, any use, distribution or copying of the information contained in this email and its attachments is strictly prohibited. If you have received this email in error, please email the sender by replying to this message and immediately delete and destroy any copies of this email and any attachments. The views or opinions expressed are the author's own and may not reflect the views or opinions of Cardno. -----Original Message----- From: Boris Kolpackov Sent: Wednesday, 16 March 2022 9:44 PM To: Phillip Shelton Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] compiling odb library Phillip Shelton writes: > > C:\compilers\hello>b hello\ config.cxx=g++.exe terminate called > > after throwing an instance of 'butl::invalid_basic_path' > > what(): invalid filesystem path > > It failed with the same error. Ok, that's good, I feel like we are getting close. Could you re-run the above command with --verbose=3: > b hello\ config.cxx=g++.exe --verbose=3 Also, could you run the following two commands (I suspect the output from one of them is the culprit): > g++.exe -std=c++2a -print-search-dirs > g++.exe -std=c++2a -x c++ -v -E - References: Message-ID: Phillip Shelton writes: > C:\compilers\hello>g++.exe -std=c++23 -print-search-dirs > install: c:\compilers\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.2.0/ > programs: =c:/compilers/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/11.2.0/;c:/compilers/mingw64/bin/../libexec/gcc/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/11.2.0/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ > libraries: =c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/;c:/compilers/mingw64/bin/../lib/gcc/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/11.2.0/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/lib/../lib/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../x86_64-w64-mingw32/11.2.0/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../lib/;/mingw/lib/x86_64-w64-mingw32/11.2.0/;/mingw/lib/../lib/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/lib/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../;/mingw/lib/ > > But I am not sure that I should be seeing ;/mingw/lib/ in either of them. > That sounds like it would be trying to find a root directory called mingw > in whatever drive was current for the build. Which I know I don't have. Yes, that's the problem, your MinGW GCC appears to be mis-configured: MinGW runtime (unlike MSYS2) doesn't do anything special for POSIX paths and so /mingw/lib/ is not translated to something like c:/mingw/lib but rather used as a Windows path with the peculiar semantics of being relative to the current drive. In build2 we treat such paths as invalid and I've now fixed the relevant code to issue diagnostics rather than fail with an unhandled exception. While the correct place to fix this is in your MinGW GCC, I was also thinking if we can somehow work around this in build2. We could ignore such paths but I am not sure that's a good idea since if you did have, say, c:\mingw\{include,lib} with some stuff in it, I believe GCC would have used it. You can test this theory by creating c:\mingw\include and then see if the output of the second command (-v -E, running from drive c:) still says that it is ignoring c:\mingw\include. Another option would be to just complete such paths with the current drive so that we get consistent behavior with GCC, even if having paths like this is asking for trouble. From phillip.shelton at cardno.com.au Thu Mar 17 03:48:27 2022 From: phillip.shelton at cardno.com.au (Phillip Shelton) Date: Thu Mar 17 06:56:05 2022 Subject: [odb-users] compiling odb library In-Reply-To: References: Message-ID: Hi, >Yes, that's the problem, your MinGW GCC appears to be mis-configured: So strictly I should try to contact winlib and ask then how to properly configure MinGW. And yes, when I do have a c:\mingw\include, the search path /mingw/include does find it. gcc version 11.2.0 (MinGW-W64 x86_64-ucrt-posix-seh, built by Brecht Sanders) COLLECT_GCC_OPTIONS='-std=c++20' '-v' '-E' '-shared-libgcc' '-mtune=generic' '-march=x86-64' c:/compilers/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/11.2.0/cc1plus.exe -E -quiet -v -iprefix c:\compilers\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.2.0/ -D_REENTRANT - -mtune=generic -march=x86-64 -std=c++20 -dumpbase - ignoring duplicate directory "c:/compilers/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../include/c++/11.2.0" ignoring duplicate directory "c:/compilers/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../include/c++/11.2.0/x86_64-w64-mingw32" ignoring duplicate directory "c:/compilers/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../include/c++/11.2.0/backward" ignoring duplicate directory "c:/compilers/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.2.0/include" ignoring nonexistent directory "R:/winlibs64_stage/inst_gcc-11.2.0/share/gcc/include" ignoring nonexistent directory "/R/winlibs64_stage/inst_gcc-11.2.0/share/gcc/include" ignoring duplicate directory "c:/compilers/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.2.0/include-fixed" ignoring duplicate directory "c:/compilers/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/include" #include "..." search starts here: #include <...> search starts here: c:\compilers\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../include/c++/11.2.0 c:\compilers\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../include/c++/11.2.0/x86_64-w64-mingw32 c:\compilers\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../include/c++/11.2.0/backward c:\compilers\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.2.0/include c:\compilers\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../include c:\compilers\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.2.0/include-fixed c:\compilers\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/include /mingw/include End of search list. So at the moment I can not use this compiler to build anything that requires build2 and therefore odb. Phillip Shelton Senior Transport Modeller Cardno Phone +61 7 3877 6991 Address Level 11, 515 St Paul's Terrace, Fortitude Valley, 4006 Queensland Australia Postal Locked Bag 4006, Fortitude Valley 4006 Email phillip.shelton@cardno.com.au Web www.cardno.com Cardno operates a quality management system that has been certified to ISO 9001. This email and its attachments may contain confidential and/or privileged information for the sole use of the intended recipient(s). All electronically supplied data must be checked against an applicable hardcopy version which shall be the only document for which Cardno warrants accuracy. If you are not the intended recipient, any use, distribution or copying of the information contained in this email and its attachments is strictly prohibited. If you have received this email in error, please email the sender by replying to this message and immediately delete and destroy any copies of this email and any attachments. The views or opinions expressed are the author's own and may not reflect the views or opinions of Cardno. -----Original Message----- From: Boris Kolpackov Sent: Thursday, 17 March 2022 5:25 PM To: Phillip Shelton Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] compiling odb library Phillip Shelton writes: > C:\compilers\hello>g++.exe -std=c++23 -print-search-dirs > install: > c:\compilers\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.2.0/ > programs: > =c:/compilers/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/11.2.0/;c: > /compilers/mingw64/bin/../libexec/gcc/;c:/compilers/mingw64/bin/../lib > /gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/x86_ > 64-w64-mingw32/11.2.0/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64- > mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ > libraries: > =c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/;c:/com > pilers/mingw64/bin/../lib/gcc/;c:/compilers/mingw64/bin/../lib/gcc/x86 > _64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/lib/x86_64-w64-m > ingw32/11.2.0/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/ > 11.2.0/../../../../x86_64-w64-mingw32/lib/../lib/;c:/compilers/mingw64 > /bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../x86_64-w64-mingw32/ > 11.2.0/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/ > ../../../../lib/;/mingw/lib/x86_64-w64-mingw32/11.2.0/;/mingw/lib/../l > ib/;c:/compilers/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../. > ./../../x86_64-w64-mingw32/lib/;c:/compilers/mingw64/bin/../lib/gcc/x8 > 6_64-w64-mingw32/11.2.0/../../../;/mingw/lib/ > > But I am not sure that I should be seeing ;/mingw/lib/ in either of them. > That sounds like it would be trying to find a root directory called > mingw in whatever drive was current for the build. Which I know I don't have. Yes, that's the problem, your MinGW GCC appears to be mis-configured: MinGW runtime (unlike MSYS2) doesn't do anything special for POSIX paths and so /mingw/lib/ is not translated to something like c:/mingw/lib but rather used as a Windows path with the peculiar semantics of being relative to the current drive. In build2 we treat such paths as invalid and I've now fixed the relevant code to issue diagnostics rather than fail with an unhandled exception. While the correct place to fix this is in your MinGW GCC, I was also thinking if we can somehow work around this in build2. We could ignore such paths but I am not sure that's a good idea since if you did have, say, c:\mingw\{include,lib} with some stuff in it, I believe GCC would have used it. You can test this theory by creating c:\mingw\include and then see if the output of the second command (-v -E, running from drive c:) still says that it is ignoring c:\mingw\include. Another option would be to just complete such paths with the current drive so that we get consistent behavior with GCC, even if having paths like this is asking for trouble. From boris at codesynthesis.com Thu Mar 17 10:54:30 2022 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Mar 17 10:51:06 2022 Subject: [odb-users] compiling odb library In-Reply-To: References: Message-ID: Phillip Shelton writes: > >Yes, that's the problem, your MinGW GCC appears to be mis-configured: > > So strictly I should try to contact winlib and ask then how to > properly configure MinGW. More precisely, contact winlibs (note that it's winlibs.com, not winlib.com) and tell them that their build of MinGW GCC is mis- configured. I doubt you will be able to do anything about it on your side short of rebuilding GCC from source. > And yes, when I do have a c:\mingw\include, the search path > /mingw/include does find it. Ok, thanks for confirming. Based on that I went ahead and added a workaround in build2 to basically do as GCC. > So at the moment I can not use this compiler to build anything > that requires build2 and therefore odb. You can try the latest staged toolchain that includes the above fix, if you would like: https://build2.org/community.xhtml#stage You will need to build build2 again (this time the staged version). It's up to you if you want to rebuild the ODB compiler with that or just use the build you already have. There should be no issue with the latter if you install the staged build2 version somewhere else and just use it to build the runtime libraries. From cmusch at gmx.at Thu Mar 17 12:20:42 2022 From: cmusch at gmx.at (Friedrich Haven) Date: Mon Mar 21 09:47:01 2022 Subject: [odb-users] strategies for dealing with blocking behaviour (postgresql) Message-ID: Hello, my understanding is that ODB offers a blocking API, and uses the blocking API of underlying libraries (e.g. PQExec for postgresql). What is the intended way to deal with situations in which blocking is not acceptable? Are there reasonable alternatives to just wrapping ODB calls in threads? Are there any ideas or plans about offering a non-blocking style of interaction in a future version? My specific scenario is: ODB is used to connect to a postgresql cluster behind a virtual IP. Failover of the cluster can lead to blocking calls which return only after several tens of seconds (after certain TCP timeouts run out), long after the failover successfully happened. thanks christian From boris at codesynthesis.com Mon Mar 21 10:11:54 2022 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Mar 21 10:08:25 2022 Subject: [odb-users] strategies for dealing with blocking behaviour (postgresql) In-Reply-To: References: Message-ID: Friedrich Haven writes: > my understanding is that ODB offers a blocking API, and uses the > blocking API of underlying libraries (e.g. PQExec for postgresql). > > What is the intended way to deal with situations in which blocking is > not acceptable? Are there reasonable alternatives to just wrapping ODB > calls in threads? > Are there any ideas or plans about offering a non-blocking style of > interaction in a future version? > > My specific scenario is: ODB is used to connect to a postgresql > cluster behind a virtual IP. Failover of the cluster can lead to > blocking calls which return only after several tens of seconds (after > certain TCP timeouts run out), long after the failover successfully > happened. While we are not against supporting non-blocking API in principle, I am not sure the amount of complexity the inversion of control will introduce will be justifiable in this case (AFAIR, you are the first asking for such a feature). I am also having a hard time imagining how such a support would be used to solve your case without turning everything into quite a mess (though, admittedly, I didn't spend much time thinking about it). How do you see this working? Do you start, say, a load() call asynchronously, and then, after some timeout, decide that it's no good, and start another one on the same object? What if the first call ends up succeeding and they both end up writing to the same object? Maybe if you could sketch in a bit more detail how you see this working in your case (including how you would decide to abandon an in-progress call), it would help come up with a sensible solution.