From pravorskii at meta.ua Sat Feb 2 09:34:50 2019 From: pravorskii at meta.ua (pravorskii@meta.ua) Date: Sat Feb 2 09:49:48 2019 Subject: [odb-users] Generating files: options.cxx (.hxx, .ixx) during build Message-ID: <3304467.0n4JtTEsp7@99d44166af322fc16a4774097a5f271d> Hi. I'm trying to understand some of the nuances of the building odb (https://git.codesynthesis.com/cgit/odb/odb/) There are autogenerated files in Git repo: odb/options.cxx odb/options.hxx odb/options.ixx Is it necessary to regenerate them every time via CLI during building? Or I can use already generated from repository? From zxbzswxr at gmail.com Fri Feb 1 20:35:27 2019 From: zxbzswxr at gmail.com (Music samal) Date: Mon Feb 4 08:16:22 2019 Subject: [odb-users] questions about c++ 17 support of odb runtime? Message-ID: I'm using odb2.4.0 release now. The odb runtime is also 2.4.0. So what can I do to make it support C++ 17. Should I update odb compiler or odb runtime or just modify it? From boris at codesynthesis.com Mon Feb 4 08:05:14 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Feb 4 08:20:05 2019 Subject: [odb-users] questions about c++ 17 support of odb runtime? In-Reply-To: References: Message-ID: Music samal writes: > I'm using odb2.4.0 release now. The odb runtime is also 2.4.0. > So what can I do to make it support C++ 17. The easiest is to switch to the 2.5.0 pre-release by following these instructions: https://codesynthesis.com/products/odb/doc/install-build2.xhtml From boris at codesynthesis.com Mon Feb 4 08:06:49 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Feb 4 08:21:38 2019 Subject: [odb-users] Generating files: options.cxx (.hxx, .ixx) during build In-Reply-To: <3304467.0n4JtTEsp7@99d44166af322fc16a4774097a5f271d> References: <3304467.0n4JtTEsp7@99d44166af322fc16a4774097a5f271d> Message-ID: pravorskii@meta.ua writes: > There are autogenerated files in Git repo: > > odb/options.cxx > odb/options.hxx > odb/options.ixx > > Is it necessary to regenerate them every time via CLI during building? > Or I can use already generated from repository? You only need to regenerate them if you change anything in odb/options.cli. From zxbzswxr at gmail.com Tue Feb 5 00:05:40 2019 From: zxbzswxr at gmail.com (Music samal) Date: Tue Feb 5 09:09:54 2019 Subject: [odb-users] questions about odb 2.5.0-b9 Message-ID: How to install libodb-boost or libodb-qt using build2, I can not find the way to do that following the instructions : https://codesynthesis.com/products/odb/doc/install-build2.xhtml From boris at codesynthesis.com Wed Feb 6 08:33:33 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Feb 6 08:48:30 2019 Subject: [odb-users] questions about odb 2.5.0-b9 In-Reply-To: References: Message-ID: Music samal writes: > How to install libodb-boost or libodb-qt using build2, [...] These haven't been packaged yet. Give us a few day, we will try to fix that. From becoggins at hotmail.com Fri Feb 15 00:38:31 2019 From: becoggins at hotmail.com (Brian Coggins) Date: Fri Feb 15 00:54:03 2019 Subject: [odb-users] Internal Compiler Error in ODB 2.5.0-b.9 with Boost Profile Message-ID: Hi Boris, I?m trying to use the latest ODB (2.5.0-b.9, downloaded and built today via build2) to get c++17 support, and I?m running into that segfault people have been reporting. Using the Boost profile seems to trigger it reliably, and the user input doesn?t seem to matter. Here?s a test case with a completely blank user input: $ more test.h // Do nothing $ odb -d sqlite --profile boost test.h *** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins. Event | Plugins PLUGIN_START_UNIT | odb PLUGIN_PRAGMAS | odb PLUGIN_OVERRIDE_GATE | odb during GIMPLE pass: *warn_unused_result In file included from :1: /usr/local/include/odb/boost/multi-index/container-traits.hxx: In function 'void __static_initialization_and_destruction_0(int, int)': /usr/local/include/odb/boost/multi-index/container-traits.hxx:211:1: internal compiler error: Segmentation fault: 11 } ^ libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. Back in October when this error was discussed, you asked someone on the list to include a backtrace, and you gave instructions to run with ?-x -dH?. I tried that, but it didn?t work: $ odb -x -dH -d sqlite --profile boost test.h *** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins. Event | Plugins PLUGIN_START_UNIT | odb PLUGIN_PRAGMAS | odb PLUGIN_OVERRIDE_GATE | odb during GIMPLE pass: *warn_unused_result In file included from :1: /usr/local/include/odb/boost/multi-index/container-traits.hxx: In function 'void __static_initialization_and_destruction_0(int, int)': /usr/local/include/odb/boost/multi-index/container-traits.hxx:211:1: internal compiler error: Segmentation fault: 11 } ^ libbacktrace could not find executable to open g++-8: internal compiler error: Abort trap: 6 signal terminated program cc1plus Please submit a full bug report, with preprocessed source if appropriate. Here is the GCC version I am using to build ODB: $ g++-8 --version g++-8 (Homebrew GCC 8.2.0) 8.2.0 Copyright (C) 2018 Free Software Foundation, Inc. Thanks, Brian From boris at codesynthesis.com Fri Feb 15 10:05:38 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 15 10:21:05 2019 Subject: [odb-users] Internal Compiler Error in ODB 2.5.0-b.9 with Boost Profile In-Reply-To: References: Message-ID: Brian Coggins writes: > I?m trying to use the latest ODB (2.5.0-b.9, downloaded and built today via > build2) to get c++17 support, and I?m running into that segfault people have > been reporting. I believe I have fixed that[1] for the upcoming b.11 (but thanks for trying to get the backtrace). If you could try the latest staged version of ODB and confirm the fix, that would be great. I believe you can use the released build2 to upgrade and it should be as simple as: $ bpkg add https://stage.build2.org/1 $ bpkg fetch $ bpkg build --upgrade --recursive $ ... Effectively the upgrade step from install-build2.xhtml. On the off chance the released build2 toolchain can't do this, you can fallback to getting staged build2 and use that; it's the same installation steps but the install script comes from here: https://stage.build2.org/0/ [1] https://git.codesynthesis.com/cgit/odb/odb/commit/?id=3a1788234bfaa96ee093b68e9ba02cf7d5bdffe6 From shprotello at mail.ru Fri Feb 15 15:42:47 2019 From: shprotello at mail.ru (=?UTF-8?B?0KHQtdGA0LPQtdC5INCd0LjQutC+0L3QvtCy?=) Date: Fri Feb 15 15:58:22 2019 Subject: [odb-users] Use of persistent class with virtual member in another module (linker error) Message-ID: <1550263367.716692947@f238.i.mail.ru> Hi, all I've received a linker error in the following situation: Module A struct data { ? double x; ? double y; }; #pragma db value( data ) definition #pragma db member( data ::x) access(x) #pragma db member( data ::y) access(y) #pragma db object class person { public: ? person() {} private: ? friend class odb::access; #pragma db id auto ? int m_id; #pragma db transient ? data m_d; #pragma db member(d) virtual(data) access(m_d) }; Module B #pragma db object class dummy { public: ? dummy() {} private: #pragma db id auto ? int m_id; #pragma db not_null ? std::shared_ptr m_p; }; This is a bit sanitized example, but it describes the situation in general. I use?odb-2.5.0-b.3 version under VS2015. Modules are compiled with dynamic multi-database support. Module A exports both common and DB specific code. Module B is linked with common and DB specific Module A libraries. When I build Module B I receive a linker error like the following: error LNK2019: unresolved external symbol "__declspec(dllimport) public: __cdecl odb::query_columns::p_tag> >::p_class_::p_class_(void)"... referenced in function "void __cdecl `dynamic initializer for 'public: static struct odb::query_columns::p_tag> >::p_class_ const odb::query_columns::p_tag> >::p''(void)" ? But, when I exclude the virtual field from class "person" and use an ordinary m_d field instead, Module B is built successfully. The questions are: - Is it possible to use virtual members in the described context? - and if so, what I did wrong? Sergey From becoggins at hotmail.com Sat Feb 16 14:40:27 2019 From: becoggins at hotmail.com (Brian Coggins) Date: Sat Feb 16 14:56:05 2019 Subject: [odb-users] Internal Compiler Error in ODB 2.5.0-b.9 with Boost Profile In-Reply-To: References: Message-ID: That update seems to have solved the sigfault problem! However, do you have an updated odb-boost somewhere? The headers in /usr/local/include/odb/boost aren?t getting updated by bpkg and are still stuck at b3. bpkg can?t find an odb-boost package when I try to do it by hand, and I?m getting "incompatible odb interface version detected? when I attempt to compile against the old 2.5.0-b.3 headers. The only problem I encountered when upgrading b9 to b11 was that the ?bpkg uninstall --all --recursive? step in the instructions removes the ODB libraries, and that kills bpkg (which can?t find the ODB dylib). So I had to reinstall build2 at that point. Brian > On Feb 15, 2019, at 10:05 AM, Boris Kolpackov wrote: > > Brian Coggins writes: > >> I?m trying to use the latest ODB (2.5.0-b.9, downloaded and built today via >> build2) to get c++17 support, and I?m running into that segfault people have >> been reporting. > > I believe I have fixed that[1] for the upcoming b.11 (but thanks for trying > to get the backtrace). > > If you could try the latest staged version of ODB and confirm the fix, > that would be great. I believe you can use the released build2 to upgrade > and it should be as simple as: > > > $ bpkg add https://stage.build2.org/1 > $ bpkg fetch > $ bpkg build --upgrade --recursive > $ ... > > Effectively the upgrade step from install-build2.xhtml. > > On the off chance the released build2 toolchain can't do this, you can > fallback to getting staged build2 and use that; it's the same installation > steps but the install script comes from here: > > https://stage.build2.org/0/ > > [1] https://git.codesynthesis.com/cgit/odb/odb/commit/?id=3a1788234bfaa96ee093b68e9ba02cf7d5bdffe6 From boris at codesynthesis.com Mon Feb 18 07:24:53 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Feb 18 07:40:27 2019 Subject: [odb-users] Use of persistent class with virtual member in another module (linker error) In-Reply-To: <1550263367.716692947@f238.i.mail.ru> References: <1550263367.716692947@f238.i.mail.ru> Message-ID: ?????? ??????? writes: > error LNK2019: unresolved external symbol "__declspec(dllimport) public: > __cdecl odb::query_columns ::person,2,struct odb::access::object_traits::p_tag> > >::p_class_::p_class_(void)"... referenced in function "void __cdecl > `dynamic initializer for 'public: static struct odb::query_columns ::person,2,struct odb::alias_traits odb::access::object_traits::p_tag> >::p_class_ const > odb::query_columns ::person,2,struct odb::access::object_traits::p_tag> > >::p''(void)" > > The questions are: > - Is it possible to use virtual members in the described context? It should be possible. > - and if so, what I did wrong? Using Windows? ;-) Seriously though, DLL-exporting of things like template instantiations is a murky business, see Section 16.2.2, "Dynamic Loading of Database Support Code" for some background (specifically, --extern-symbol). I would also diff the generated code for the two cases to see if that gives any hints. From boris at codesynthesis.com Mon Feb 18 09:21:07 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Feb 18 09:36:43 2019 Subject: [odb-users] Internal Compiler Error in ODB 2.5.0-b.9 with Boost Profile In-Reply-To: References: Message-ID: Brian Coggins writes: > However, do you have an updated odb-boost somewhere? The libodb-boost and libodb-qt packages are now on stage.build2.org. The only requirement is that you upgrade your build2 toolchain from stage as well (there is a fix in build2 that's required by these packages). > The only problem I encountered when upgrading b9 to b11 was that the > ?bpkg uninstall --all --recursive? step in the instructions removes > the ODB libraries, and that kills bpkg (which can?t find the ODB dylib). > So I had to reinstall build2 at that point. Yes, if you install both ODB and build2 into the same place, that would happen, which is unfortunate. Need to think if we can do anything about it. From becoggins at hotmail.com Tue Feb 19 08:44:12 2019 From: becoggins at hotmail.com (Brian Coggins) Date: Tue Feb 19 08:59:58 2019 Subject: [odb-users] Internal Compiler Error in ODB 2.5.0-b.9 with Boost Profile In-Reply-To: References: Message-ID: Thanks for this. I updated libodb-boost, but something is still unhappy. The ODB-generated header has this line: #if ODB_BOOST_VERSION != 2046000 // 2.5.0-b.10 which is tripping things up. I?m guessing that libodb and libodb-boost are now out of sync? Is there a way to get them back in sync, or should I just uninstall everything and start over with the current staged? Brian > On Feb 18, 2019, at 9:21 AM, Boris Kolpackov wrote: > > Brian Coggins writes: > >> However, do you have an updated odb-boost somewhere? > > The libodb-boost and libodb-qt packages are now on stage.build2.org. The > only requirement is that you upgrade your build2 toolchain from stage as > well (there is a fix in build2 that's required by these packages). > > >> The only problem I encountered when upgrading b9 to b11 was that the >> ?bpkg uninstall --all --recursive? step in the instructions removes >> the ODB libraries, and that kills bpkg (which can?t find the ODB dylib). >> So I had to reinstall build2 at that point. > > Yes, if you install both ODB and build2 into the same place, that would > happen, which is unfortunate. Need to think if we can do anything about > it. > > From boris at codesynthesis.com Tue Feb 19 09:53:31 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Feb 19 10:09:10 2019 Subject: [odb-users] Internal Compiler Error in ODB 2.5.0-b.9 with Boost Profile In-Reply-To: References: Message-ID: Brian Coggins writes: > #if ODB_BOOST_VERSION != 2046000 // 2.5.0-b.10 > > I?m guessing that libodb and libodb-boost are now out of sync? Is there > a way to get them back in sync, or should I just uninstall everything > and start over with the current staged? No, that's our bug. We are in the middle of a build2 release which will also include the latest beta for ODB. I will make sure this is fixed there. Shouldn't be more than a few days. In the meantime you can patch: $config.install.root/include/odb/boost/version.hxx by adding: #define ODB_BOOST_VERSION 2046000 #define ODB_BOOST_VERSION_STR "2.5.0-b.10" From becoggins at hotmail.com Wed Feb 20 09:40:00 2019 From: becoggins at hotmail.com (Brian Coggins) Date: Wed Feb 20 09:55:50 2019 Subject: [odb-users] Internal Compiler Error in ODB 2.5.0-b.9 with Boost Profile In-Reply-To: References: Message-ID: That patch took care of it. Thanks! > On Feb 19, 2019, at 9:53 AM, Boris Kolpackov wrote: > > Brian Coggins writes: > >> #if ODB_BOOST_VERSION != 2046000 // 2.5.0-b.10 >> >> I?m guessing that libodb and libodb-boost are now out of sync? Is there >> a way to get them back in sync, or should I just uninstall everything >> and start over with the current staged? > > No, that's our bug. We are in the middle of a build2 release which will > also include the latest beta for ODB. I will make sure this is fixed > there. Shouldn't be more than a few days. > > In the meantime you can patch: > > $config.install.root/include/odb/boost/version.hxx > > by adding: > > #define ODB_BOOST_VERSION 2046000 > #define ODB_BOOST_VERSION_STR "2.5.0-b.10" From boris at codesynthesis.com Fri Feb 22 07:03:28 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 22 07:19:15 2019 Subject: [odb-users] Internal Compiler Error in ODB 2.5.0-b.9 with Boost Profile In-Reply-To: References: Message-ID: Brian Coggins writes: > That patch took care of it. ODB 2.5.0-b.11 is now available on cppget.org and should have this fixed. If you want to give it a try, it probably makes sense to get the latest released build2 from the same location. From lfiedler at informatik.uni-leipzig.de Sat Feb 23 04:14:47 2019 From: lfiedler at informatik.uni-leipzig.de (Lisa Fiedler) Date: Sat Feb 23 04:30:50 2019 Subject: [odb-users] Loading of lazy ptr within odb object class Message-ID: Hello, I am having trouble to execute the load operation on odb::lazy_shared_ptr within the odb class. To identify the reasons I set up the following program: Two odb classes: employee and employer (and some other classes but this is not really relevant). Basically it looks like this: #pragma db object pointer(std::shared_ptr) session table("schema1.employer") class employer { public: ? employer (const std::string& name); ? const std::string& ? name () const; ? // Employees of this employer. ? // ? typedef std::vector> employees_type; ? const employees_type& ? employees () const; ? employees_type& ? employees (); private: ? friend class odb::access; ? employer () {} ? #pragma db id type("VARCHAR (255)") column("name") ? std::string name_; ? #pragma db unordered table("schema1.employer_employees") id_column("name") value_column("id") ? employees_type employees_; }; #pragma db object pointer(std::shared_ptr) session table("schema1.employee") class employee { public: ? typedef odb::lazy_shared_ptr employer_type; ? employee (const std::string& first, ??????????? const std::string& last, ??????????? std::shared_ptr employer) ????? : first_ (first), last_ (last), emPloyer_ (employer) ? { ? } ? // Name. ? // ? const std::string& ? first () const ? { ??? return first_; ? } ? const std::string& ? last () const ? { ??? return last_; ? } ? unsigned long& id(){ ????? return id_; ? } ? // Employer. ? // ? employer_type ? emPloyer () const ? { ??? return emPloyer_; ? } ? void ? emPloyer (employer_type employer) ? { ??? emPloyer_ = employer; ? } ?? // having issues here!!! *? void printEmployer(){** **????? cout << emPloyer_.load()->name() << endl;** **? }* private: ? friend class odb::access; ? employee () {} ? #pragma db id type("INTEGER") column("id") ? unsigned long id_; ? #pragma db type("VARCHAR (255)") column("first") ? std::string first_; ? #pragma db type("VARCHAR (255)") column("last") ? std::string last_; ? #pragma db not_null column("employer") ? employer_type emPloyer_; }; Now what does not work out is the printEmployer method in the employee class (bold type setting). Error message: "error: no match for ?operator=? (operand types are ?std::shared_ptr? and ?odb::object_traits::pointer_type {aka employer*}?) ?????? p_ = i_.template load (true); // Reset id" If I execute this operation, i.e. emPloyer.load()->name(), for instance in the main method it executes just fine. I suspected the reason is, that in main.cpp I included employee-odb.hxx, which I did not do in employee.hxx where the above mentioned classes are defined. I therefore tried to include it there, but this apparently leads to some cyclic inclusions. Thanks a lot for any suggestions to what I can do, to enable lazy ptr loading wihtin odb classes. From boris at codesynthesis.com Mon Feb 25 06:15:11 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Feb 25 06:31:09 2019 Subject: [odb-users] Loading of lazy ptr within odb object class In-Reply-To: References: Message-ID: Lisa Fiedler writes: > #pragma db object pointer(std::shared_ptr) session table("schema1.employee") > class employee > { > > [...] > > void printEmployer(){ > cout << emPloyer_.load()->name() << endl; > } > > [...] > > "error: no match for ?operator=? (operand types are > ?std::shared_ptr? and ?odb::object_traits::pointer_type {aka employer*}?) > p_ = i_.template load (true); // Reset id" > > If I execute this operation, i.e. emPloyer.load()->name(), for instance in > the main method it executes just fine. I suspected the reason is, that in > main.cpp I included employee-odb.hxx, which I did not do in employee.hxx > where the above mentioned classes are defined. I therefore tried to include > it there, but this apparently leads to some cyclic inclusions. Yes, to be able to load a persistent object you need to have its database support code included (the corresponding *-odb.hxx file). The easiest way to resolve this problem is to move the definition of printEmployer() to the source file. For example: // file: employee.hxx ... #pragma db object pointer(std::shared_ptr) session table("schema1.employee") class employee { ... void printEmployer(); ... }; // file: employee.cxx ... #include "employer-odb.hxx" void employee::printEmployer() { cout << emPloyer_.load()->name() << endl; } From sean.clarke at sec-consulting.co.uk Thu Feb 28 02:43:00 2019 From: sean.clarke at sec-consulting.co.uk (Sean Clarke) Date: Thu Feb 28 02:59:30 2019 Subject: [odb-users] 2.5.0 release date? Message-ID: Hi, it seems like 2.5.0 has been an eternity in development, do we have an approximate date for when it might be released? Regards Sean Clarke From boris at codesynthesis.com Thu Feb 28 08:41:47 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Feb 28 08:57:55 2019 Subject: [odb-users] 2.5.0 release date? In-Reply-To: References: Message-ID: Sean Clarke writes: > it seems like 2.5.0 has been an eternity in development, do we have an > approximate date for when it might be released? Yes, the release is overdue. The reason for the delay is that we are moving to a uniform build/packaging toolchain as well as more of "continuous delivery" model in the future. And we are almost but not quite ready for the release. I would also recommend that you do not wait for the "official & final" release and start using the new setup as described here: https://codesynthesis.com/products/odb/doc/install-build2.xhtml At this stage in the development cycle, it is as stable as 2.4.0, we are using it ourselves in multiple projects, we have migrated a number of users with very good results, and it is fully supported (i.e., we provide the same level of support as for 2.4.0).