From xavier.monset at gmail.com Tue Aug 11 07:24:34 2020 From: xavier.monset at gmail.com (Xavier Monset) Date: Tue Aug 11 07:40:39 2020 Subject: [odb-users] std::atomic cause me trouble. Message-ID: Hi ! I'm trying to use ODB, but I'm stuck with an error about std::atomic. I've read this : https://odb-users.codesynthesis.narkive.com/yfbzUHDa/wrapping-existing-members-with-std-atomic So I tried to to define the odb::wrapper_traits specialization for std::atomic in file wrapper-traits.hxx. I did it this by adding : // Specialization for odb::atomic. > // > template > class wrapper_traits< std::atomic > > { > public: > // T can be const. > // > typedef T wrapped_type; > typedef nullable wrapper_type; > > // T can be const. > // > typedef > typename odb::details::meta::remove_const::result > unrestricted_wrapped_type; > > static const bool null_handler = true; > static const bool null_default = true; > > static bool > get_null (const wrapper_type& n) > { > return n.null (); > } > > static void > set_null (wrapper_type& n) > { > n.reset (); > } > > static const wrapped_type& > get_ref (const wrapper_type& n) > { > return *n; > } > > static unrestricted_wrapped_type& > set_ref (wrapper_type& n) > { > if (n.null ()) > n = unrestricted_wrapped_type (); > > return const_cast (*n); > } > > }; > But, now, I'm getting error. I have this complain : " /usr/local/include/odb/wrapper-traits.hxx:277:30*: error: ?atomic? is not a member of ?std*?" May someone help me with this ? Thanks. Xavier. From xavier.monset at gmail.com Wed Aug 12 10:32:08 2020 From: xavier.monset at gmail.com (Xavier Monset) Date: Wed Aug 12 10:48:16 2020 Subject: [odb-users] Pointer to a objects list. Message-ID: Hi ! I have two classes 'Groupe' and 'Consignes'. Groupe own a list of Consignes. #include #pragma db object class Groupe { private: friend class odb::access; #pragma db id auto unsigned long id_; map liste_arrets; StatsEcPhGroupe *messtatsEcPh = new StatsEcPhGroupe(); StatsTempsGroupe *mesStatsTemps = new StatsTempsGroupe(); StatsVolumeGroupe *mesStatsVolume = new StatsVolumeGroupe(); * list *mesConsignesInjectionExterieure = new list;* public: bla bla bla } the line " list *mesConsignesInjectionExterieure = new list; " seems to not be right for odb. I have this error : error: unable to map C++ type '::std::list< ::Consignes_Injection_Exterieure* >*' used in data member 'mesConsignesInjectionExterieure' to a MySQL database type info: use '#pragma db type' to specify the database type How should I handle it ? Thanks a lot. Xavier. From boris at codesynthesis.com Wed Aug 12 10:42:44 2020 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Aug 12 10:58:32 2020 Subject: [odb-users] std::atomic cause me trouble. In-Reply-To: References: Message-ID: Xavier Monset writes: > So I tried to to define the odb::wrapper_traits specialization for > std::atomic in file wrapper-traits.hxx. > I did it this by adding : > > [...] > > But, now, I'm getting error. I have this complain : " > /usr/local/include/odb/wrapper-traits.hxx:277:30*: error: ?atomic? is not a > member of ?std*?" It's hard to say for sure without looking at the entire file, but my first guess would be a missing `#include `. From xavier.monset at gmail.com Thu Aug 13 02:57:04 2020 From: xavier.monset at gmail.com (Xavier Monset) Date: Thu Aug 13 03:13:14 2020 Subject: [odb-users] std::atomic cause me trouble. In-Reply-To: References: Message-ID: Hi Boris, It was more shameful : I just had --std c++11 on the odb command. Sorry for the noise. Xavier. Le mer. 12 ao?t 2020 ? 16:42, Boris Kolpackov a ?crit : > Xavier Monset writes: > > > So I tried to to define the odb::wrapper_traits specialization for > > std::atomic in file wrapper-traits.hxx. > > I did it this by adding : > > > > [...] > > > > But, now, I'm getting error. I have this complain : " > > /usr/local/include/odb/wrapper-traits.hxx:277:30*: error: ?atomic? is > not a > > member of ?std*?" > > It's hard to say for sure without looking at the entire file, but > my first guess would be a missing `#include `. > From boris at codesynthesis.com Thu Aug 13 09:56:12 2020 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Aug 13 10:12:05 2020 Subject: [odb-users] Pointer to a objects list. In-Reply-To: References: Message-ID: Xavier Monset writes: > error: unable to map C++ type '::std::list< > ::Consignes_Injection_Exterieure* >*' used in data member > 'mesConsignesInjectionExterieure' to a MySQL database type > info: use '#pragma db type' to specify the database type > > How should I handle it ? One way would be to use a smart pointer like std::unique_ptr (or turn them into values). For pointers, see wrapper_traits. From jp.samper at apex.ai Tue Aug 18 16:18:47 2020 From: jp.samper at apex.ai (Juan Pablo Samper) Date: Wed Aug 19 10:27:14 2020 Subject: [odb-users] Support for ODB on QNX Message-ID: Hello, I'm trying to compile ODB for QNX (Linux host -> QNX target), but I'm having trouble finding up to date guidelines: I found the document for ODB on embedded devices: - http://wiki.codesynthesis.com/Using_ODB_on_Mobile_and_Embedded_Systems And a couple of older posts that refer to it: - https://www.codesynthesis.com/pipermail/odb-users/2014-December/002249.html - https://www.codesynthesis.com/pipermail/odb-users/2014-December/002247.html However, it looks like configure has been deprecated in favor of build2: - https://www.codesynthesis.com/products/odb/doc/install-build2.xhtml Are there any guidelines for cross-compiling ODB using build2? I guess I'll start here (https://build2.org/build2/doc/build2-build-system-manual.xhtml)? (Side note: Maybe a link here https://build2.org/faq.xhtml#cross?) Thanks! -- Juan Pablo Samper Software Tooling and Infrastucture Apex.AI www.apex.ai From boris at codesynthesis.com Wed Aug 19 10:20:38 2020 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Aug 19 10:36:48 2020 Subject: [odb-users] Support for ODB on QNX In-Reply-To: References: Message-ID: Juan Pablo Samper writes: > Are there any guidelines for cross-compiling ODB using build2? It should just work (I know, famous last words) provided your cross- compiler is sane (which it should be). Specifically, the build is already split into two configurations: the ODB compiler (which you would build natively for host) and the runtime libraries (which you would cross-build for target). So just point config.cxx to your cross-compiler for the latter and see what happens. But let me know if there are any issues, I would definitely be interested in ironing them out. > (Side note: Maybe a link here https://build2.org/faq.xhtml#cross?) You mean from the odb/build2-install.xhtml instructions? Seeing that this FAQ entry doesn't say much other than "it's expected to work", maybe a note alone the above lines would be more useful? From jp.samper at apex.ai Wed Aug 19 20:00:10 2020 From: jp.samper at apex.ai (Juan Pablo Samper) Date: Thu Aug 20 08:22:16 2020 Subject: [odb-users] Support for ODB on QNX In-Reply-To: References: Message-ID: Hi Boris, As you suggested, I pointed config.cxx to the QNX compiler: bpkg create \ -d qnx-aarch64 cc \ config.cxx=ntoaarch64-g++ \ config.cc.coptions=-O3 \ config.install.root=$(realpath install-qnx) and I get the following error: qnx-aarch64-qcc/build/root.build:3:7: error: cxx and bin module target mismatch info: cxx target is aarch64-nto-qnx7.0.0 info: bin target is aarch64-nto-qnx7.0.0 When I run with -V and --verbose 6, I see: cxx @/home/jp.samper/workspace/odb_ws/odb-build/qnx-aarch64-qcc/ ... target aarch64-nto-qnx7.0.0 (aarch64-unknown-nto-qnx7.0.0) ... bin @/home/jp.samper/workspace/odb_ws/odb-build/qnx-aarch64-qcc/ target aarch64-nto-qnx7.0.0 which could explain the mismatch. Is there a way to work around this? I tried manually giving it cxx.target and/or bin.target, but it says I can't override. W.R.T side note: I think a note in the FAQ like the reply above would be enough to get someone started. I guess I just assumed cross-compiling wouldn't be that simple: as a sanity check, I tried with aarch64-linux-gnu-g++, and as you claimed, it just worked :) Best, JP On Wed, Aug 19, 2020 at 7:20 AM Boris Kolpackov wrote: > Juan Pablo Samper writes: > > > Are there any guidelines for cross-compiling ODB using build2? > > It should just work (I know, famous last words) provided your cross- > compiler is sane (which it should be). Specifically, the build is > already split into two configurations: the ODB compiler (which you > would build natively for host) and the runtime libraries (which you > would cross-build for target). So just point config.cxx to your > cross-compiler for the latter and see what happens. > > But let me know if there are any issues, I would definitely be > interested in ironing them out. > > > > (Side note: Maybe a link here https://build2.org/faq.xhtml#cross?) > > You mean from the odb/build2-install.xhtml instructions? Seeing that > this FAQ entry doesn't say much other than "it's expected to work", > maybe a note alone the above lines would be more useful? > -- Juan Pablo Samper Software Tooling and Infrastucture Apex.AI www.apex.ai From boris at codesynthesis.com Thu Aug 20 08:34:51 2020 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Aug 20 08:51:05 2020 Subject: [odb-users] Support for ODB on QNX In-Reply-To: References: Message-ID: Juan Pablo Samper writes: > qnx-aarch64-qcc/build/root.build:3:7: error: cxx and bin module target > mismatch > info: cxx target is aarch64-nto-qnx7.0.0 > info: bin target is aarch64-nto-qnx7.0.0 I looked into this and there is a bug in our handling of target triplets (in the first target `nto` is attributed to the system while in the second -- to the vendor). I still need to meditate on how to best fix this. In the meantime, you should be able to work around this issue by overriding the guessed target: config.cxx.target=aarch64-nto-qnx7.0.0 > W.R.T side note: > I think a note in the FAQ like the reply above would be enough to get > someone started. Sounds good, I will add it. From jp.samper at apex.ai Thu Aug 20 19:06:52 2020 From: jp.samper at apex.ai (Juan Pablo Samper) Date: Fri Aug 21 00:14:03 2020 Subject: [odb-users] Support for ODB on QNX In-Reply-To: References: Message-ID: Hi Boris, The workaround works! I managed to compile libodb, libodb-boost, and libodb-mysql for QNX. It required patching libcrypto and libmysqlclient to account for some QNX-specific options. I still have to test whether our application will compile and run, so I'm not out of the woods yet. There is one quirk that would be nice to iron out, though: I specified config.cxx and config.cxx.target when running bpkg create, but then when I try to build libz, I got this warning: $ bpkg build libz ... libz-1.2.1100+1/build/root.build:6:7: error: cxx and c module target mismatch info: cxx is 'aarch64-nto-qnx7.0.0' info: c is 'aarch64-nto-qnx7.0.0' info: consider explicitly specifying config.cxx and config.c It's probably the same underlying mismatch, so I explicitly add it to build/config.build config.c = ntoaarch64-gcc config.c.target = aarch64-nto-qnx7.0.0 I then run bpkg build libz again and everything compiles successfully, but it prints the following warning: $ bpkg build libz ... libz-1.2.1100+1/build/config.build: warning: saving previously inherited variable config.c info: because project /home/jp.samper/workspace/odb_ws/odb-build/qnx-aarch64-with-c/ no longer uses it in its configuration libz-1.2.1100+1/build/config.build: warning: saving previously inherited variable config.c.target info: because project /home/jp.samper/workspace/odb_ws/odb-build/qnx-aarch64-with-c/ no longer uses it in its configuration libz-1.2.1100+1/tests/build/config.build: warning: saving previously inherited variable config.c info: because project /home/jp.samper/workspace/odb_ws/odb-build/qnx-aarch64-with-c/ no longer uses it in its configuration libz-1.2.1100+1/tests/build/config.build: warning: saving previously inherited variable config.c.target info: because project /home/jp.samper/workspace/odb_ws/odb-build/qnx-aarch64-with-c/ no longer uses it in its configuration ... updated libz/1.2.1100+1 I can live with the warning, but it does seem strange that bpkg first asked me to configure it, and then tells me it no longer uses it. The actual quirk that would be nice to iron out is that if I try to set config.c and config.c.target when running bpkg create, bpkg drops it: qnx-aarch64-with-c/build/config.build: warning: dropping no longer used variable config.c info: variable value: 'ntoaarch64-gcc' qnx-aarch64-with-c/build/config.build: warning: dropping no longer used variable config.c.target info: variable value: 'aarch64-nto-qnx7.0.0' Is this all expected or am I missing something? Thanks! JP On Thu, Aug 20, 2020 at 5:34 AM Boris Kolpackov wrote: > Juan Pablo Samper writes: > > > qnx-aarch64-qcc/build/root.build:3:7: error: cxx and bin module target > > mismatch > > info: cxx target is aarch64-nto-qnx7.0.0 > > info: bin target is aarch64-nto-qnx7.0.0 > > I looked into this and there is a bug in our handling of target > triplets (in the first target `nto` is attributed to the system > while in the second -- to the vendor). I still need to meditate > on how to best fix this. > > In the meantime, you should be able to work around this issue by > overriding the guessed target: > > config.cxx.target=aarch64-nto-qnx7.0.0 > > > > W.R.T side note: > > I think a note in the FAQ like the reply above would be enough to get > > someone started. > > Sounds good, I will add it. > > -- Juan Pablo Samper Software Tooling and Infrastucture Apex.AI www.apex.ai From boris at codesynthesis.com Fri Aug 21 00:14:51 2020 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Aug 21 00:31:11 2020 Subject: [odb-users] Support for ODB on QNX In-Reply-To: References: Message-ID: Juan Pablo Samper writes: > It required patching libcrypto and libmysqlclient to account for some > QNX-specific options. You can also use QNX-supplied versions of these if you would like (especially libcrypto/libssl). See notes on using system-installed dependencies in odb/install-build2.xhtml. > $ bpkg build libz > ... > libz-1.2.1100+1/build/root.build:6:7: error: cxx and c module target > mismatch > info: cxx is 'aarch64-nto-qnx7.0.0' > info: c is 'aarch64-nto-qnx7.0.0' > info: consider explicitly specifying config.cxx and config.c Yes, this is the same issue. > I then run bpkg build libz again and everything compiles successfully, but > it prints the following warning: > > $ bpkg build libz > ... > libz-1.2.1100+1/build/config.build: warning: saving previously inherited > variable config.c Hm, strange. This sequence of steps doesn't issue any warnings for me: bpkg create -d conf cc config.cxx=g++ config.c=gcc bpkg build -d conf libz@https://pkg.cppget.org/1/stable > The actual quirk that would be nice to iron out is that if I try to set > config.c and config.c.target when running bpkg create, bpkg drops it: > > qnx-aarch64-with-c/build/config.build: warning: dropping no longer used > variable config.c What is the exact sequence of steps to reproduce this? And this is using build2 0.13.0, correct? From jp.samper at apex.ai Fri Aug 21 12:18:06 2020 From: jp.samper at apex.ai (Juan Pablo Samper) Date: Mon Aug 24 06:52:10 2020 Subject: [odb-users] Support for ODB on QNX In-Reply-To: References: Message-ID: Hi Boris, I noticed my mistake: I was running `bpkg create -d conf *cxx`. *Once I used `cc`, no warning. I did try to use the QNX-provided libssl and libcrypto, and I ran into the following: $ bpkg build libmysqlclient ?sys:libssl ?sys:libcrypto error: unable to import target libssl%lib{ssl} info: use config.import.libssl configuration variable to specify its project out_root info: or use config.import.libssl.ssl.lib configuration variable to specify its path error: unable to import target libssl%lib{ssl} info: use config.import.libssl configuration variable to specify its project out_root info: or use config.import.libssl.ssl.lib configuration variable to specify its path So then I set config.import.libssl.ssl.lib in the build/config.build: config.import.libssl.ssl.lib = /path/to/qnx/usr/lib But then bpkg crashes: $ bpkg build libmysqlclient ?sys:libssl ?sys:libcrypto b: /home/jp.samper/workspace/odb_ws/build2-build/build2-toolchain-0.13/build2-0.13.0/libbuild2/target.cxx:550: std::ostream& build2::to_stream(std::ostream&, const build2::target_key&, butl::optional): Assertion `!k.ext' failed. error: process b terminated abnormally: aborted (SIGABRT) (core dumped) I assumed it was just an RTFM moment on how to configure the path to the library, so I decided to set it aside and come back to it if compiling from source didn't work, but since we are already here, maybe you can tell me what I'm doing wrong? Thanks! JP On Thu, Aug 20, 2020 at 9:15 PM Boris Kolpackov wrote: > Juan Pablo Samper writes: > > > It required patching libcrypto and libmysqlclient to account for some > > QNX-specific options. > > You can also use QNX-supplied versions of these if you would like > (especially libcrypto/libssl). See notes on using system-installed > dependencies in odb/install-build2.xhtml. > > > > $ bpkg build libz > > ... > > libz-1.2.1100+1/build/root.build:6:7: error: cxx and c module target > > mismatch > > info: cxx is 'aarch64-nto-qnx7.0.0' > > info: c is 'aarch64-nto-qnx7.0.0' > > info: consider explicitly specifying config.cxx and config.c > > Yes, this is the same issue. > > > > I then run bpkg build libz again and everything compiles successfully, > but > > it prints the following warning: > > > > $ bpkg build libz > > ... > > libz-1.2.1100+1/build/config.build: warning: saving previously inherited > > variable config.c > > Hm, strange. This sequence of steps doesn't issue any warnings for me: > > bpkg create -d conf cc config.cxx=g++ config.c=gcc > bpkg build -d conf libz@https://pkg.cppget.org/1/stable > > > > The actual quirk that would be nice to iron out is that if I try to set > > config.c and config.c.target when running bpkg create, bpkg drops it: > > > > qnx-aarch64-with-c/build/config.build: warning: dropping no longer used > > variable config.c > > What is the exact sequence of steps to reproduce this? And this is using > build2 0.13.0, correct? > -- Juan Pablo Samper Software Tooling and Infrastucture Apex.AI www.apex.ai From jp.samper at apex.ai Fri Aug 21 20:13:07 2020 From: jp.samper at apex.ai (Juan Pablo Samper) Date: Mon Aug 24 06:52:10 2020 Subject: [odb-users] Support for ODB on QNX In-Reply-To: References: Message-ID: Hi Boris, When compiling a file generated by the odb compiler, I get the following errors: analysis_result_odb.cpp:105:11: error: '::__time_t' has not been declared analysis_result_odb.cpp:114:7: error: '::__suseconds_t' has not been declared Sure enough, if I search in the QNX toolchain, __time_t and __suseconds_t do not exist. However, I do find __TIME_T and __SUSECONDS_T, and time_t and suseconds_t. In linux, the types are defined in bits/types.h I can work around the error by adding, e.g., typedef __TIME_T __time_t in some QNX headers, which is kind of hacky (but works :P). I guess the question is what component (odb, libodb-mysql, qnx toolchain, etc.) is responsible to make sure __time_t is available? Or put differently, should I be creating a ticket for QNX support people or is this a new use-case for ODB? You should be able to generate the same file by using the files in the performance_test project: https://gitlab.com/ApexAI/performance_test/-/tree/qnx_perf_test_odb. The underlying command used to generate the files: $ odb \ -d mysql \ --generate-query \ --generate-session \ --generate-schema \ --schema-format embedded --std c++11 \ --changelog-dir /home/jp.samper/workspace/performance_test/performance_test/schema_changelog \ --profile boost/uuid -x -DPERFORMANCE_TEST_ODB_FOR_SQL_ENABLED \ --output-dir /home/jp.samper/workspace/performance_test/build/performance_test/odb_gen \ --hxx-suffix .hpp \ --ixx-suffix _inline.hpp \ --cxx-suffix .cpp \ --odb-file-suffix _odb \ -I/home/jp.samper/workspace/performance_test/performance_test/src/experiment_configuration \ -I/home/jp.samper/workspace/performance_test/performance_test/src/experiment_execution \ -I/tmp/qnx_toolchain/qnx700_bl/target/qnx7/aarch64le/opt/odb/include \ src/experiment_execution/analysis_result.hpp (also src/experiment_configuration/experiment_configuration.hpp) I'm using odb 2.5.0-b.19+1 compiled with gcc 7.5.0 on Ubuntu 18.04. Best, JP On Fri, Aug 21, 2020 at 9:18 AM Juan Pablo Samper wrote: > Hi Boris, > > I noticed my mistake: I was running `bpkg create -d conf *cxx`. *Once I > used `cc`, no warning. > > I did try to use the QNX-provided libssl and libcrypto, and I ran into the > following: > > $ bpkg build libmysqlclient ?sys:libssl ?sys:libcrypto > error: unable to import target libssl%lib{ssl} > info: use config.import.libssl configuration variable to specify its > project out_root > info: or use config.import.libssl.ssl.lib configuration variable to > specify its path > error: unable to import target libssl%lib{ssl} > info: use config.import.libssl configuration variable to specify its > project out_root > info: or use config.import.libssl.ssl.lib configuration variable to > specify its path > > So then I set config.import.libssl.ssl.lib in the build/config.build: > > config.import.libssl.ssl.lib = /path/to/qnx/usr/lib > > But then bpkg crashes: > > $ bpkg build libmysqlclient ?sys:libssl ?sys:libcrypto > b: > /home/jp.samper/workspace/odb_ws/build2-build/build2-toolchain-0.13/build2-0.13.0/libbuild2/target.cxx:550: > std::ostream& build2::to_stream(std::ostream&, const build2::target_key&, > butl::optional): Assertion `!k.ext' failed. > error: process b terminated abnormally: aborted (SIGABRT) (core dumped) > > I assumed it was just an RTFM moment on how to configure the path to the > library, > so I decided to set it aside and come back to it if compiling from source > didn't work, but > since we are already here, maybe you can tell me what I'm doing wrong? > > Thanks! > JP > > On Thu, Aug 20, 2020 at 9:15 PM Boris Kolpackov > wrote: > >> Juan Pablo Samper writes: >> >> > It required patching libcrypto and libmysqlclient to account for some >> > QNX-specific options. >> >> You can also use QNX-supplied versions of these if you would like >> (especially libcrypto/libssl). See notes on using system-installed >> dependencies in odb/install-build2.xhtml. >> >> >> > $ bpkg build libz >> > ... >> > libz-1.2.1100+1/build/root.build:6:7: error: cxx and c module target >> > mismatch >> > info: cxx is 'aarch64-nto-qnx7.0.0' >> > info: c is 'aarch64-nto-qnx7.0.0' >> > info: consider explicitly specifying config.cxx and config.c >> >> Yes, this is the same issue. >> >> >> > I then run bpkg build libz again and everything compiles successfully, >> but >> > it prints the following warning: >> > >> > $ bpkg build libz >> > ... >> > libz-1.2.1100+1/build/config.build: warning: saving previously inherited >> > variable config.c >> >> Hm, strange. This sequence of steps doesn't issue any warnings for me: >> >> bpkg create -d conf cc config.cxx=g++ config.c=gcc >> bpkg build -d conf libz@https://pkg.cppget.org/1/stable >> >> >> > The actual quirk that would be nice to iron out is that if I try to set >> > config.c and config.c.target when running bpkg create, bpkg drops it: >> > >> > qnx-aarch64-with-c/build/config.build: warning: dropping no longer used >> > variable config.c >> >> What is the exact sequence of steps to reproduce this? And this is using >> build2 0.13.0, correct? >> > > > -- > > Juan Pablo Samper > > Software Tooling and Infrastucture > > Apex.AI > > www.apex.ai > > -- Juan Pablo Samper Software Tooling and Infrastucture Apex.AI www.apex.ai From boris at codesynthesis.com Mon Aug 24 06:50:04 2020 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Aug 24 07:06:31 2020 Subject: [odb-users] Support for ODB on QNX In-Reply-To: References: Message-ID: Juan Pablo Samper writes: > I did try to use the QNX-provided libssl and libcrypto, and I ran into the > following: > > $ bpkg build libmysqlclient ?sys:libssl ?sys:libcrypto > error: unable to import target libssl%lib{ssl} > > > So then I set config.import.libssl.ssl.lib in the build/config.build: > > config.import.libssl.ssl.lib = /path/to/qnx/usr/lib This is now quite how you would do this for a library (the suggestion is misleading becasue it's printed by generic code that is used to import other things, like executables; need to see if we can fix that). The proper way to resolve this is to supply -I/-L options during the configuration creation. This section in the introduction has the details: https://build2.org/build2-toolchain/doc/build2-toolchain-intro.xhtml#guide-unpackaged-deps > But then bpkg crashes: I believe we have fixed this already in master. From boris at codesynthesis.com Mon Aug 24 07:17:50 2020 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Aug 24 07:34:17 2020 Subject: [odb-users] Support for ODB on QNX In-Reply-To: References: Message-ID: Juan Pablo Samper writes: > When compiling a file generated by the odb compiler, I get the following > errors: > > analysis_result_odb.cpp:105:11: error: '::__time_t' has not been declared > analysis_result_odb.cpp:114:7: error: '::__suseconds_t' has not been > declared When generating database support code on one platform to be used on another you have to be careful not to depend on platform-specific definitions (or hack things around to match). I am pretty sure the above error is caused by your use of struct timeval. One way to resolve this would be to map timeval to a value type that has a platform-independent definition. Something along these lines (the mapping might need some type casting to get rid of warnings): #pragma db value struct odb_timeval { std::int64_t tv_sec; std::int64_t tv_usec; }; #pragma db map type(timeval) as(odb_timeval) \ to(odb_timeval{(?).tv_sec, (?).tv_usec}) \ from(timeval{(?).tv_sec, (?).tv_usec}) From jp.samper at apex.ai Tue Aug 25 14:01:43 2020 From: jp.samper at apex.ai (Juan Pablo Samper) Date: Wed Aug 26 08:43:24 2020 Subject: [odb-users] Support for ODB on QNX In-Reply-To: References: Message-ID: Hi Boris, I agree that "hacking things to match" is not really the way to go. I also get that we have to be careful to not use platform-specific constructs; however, QNX defines its own timeval, which wraps the platform-specific part (e.g. __time_t). The ODB compiler seems to be using information from the underlying Linux implementation of timeval which negates the QNX wrapper. I guess I was hoping that there is a way to tell the ODB compiler to use the QNX definition rather than the Linux definition. That being said, I'm working with one of my team members to figure out the exact mapping that we need to configure to get this working. I'll report back. Best, JP On Mon, Aug 24, 2020 at 4:17 AM Boris Kolpackov wrote: > Juan Pablo Samper writes: > > > When compiling a file generated by the odb compiler, I get the following > > errors: > > > > analysis_result_odb.cpp:105:11: error: '::__time_t' has not been declared > > analysis_result_odb.cpp:114:7: error: '::__suseconds_t' has not been > > declared > > When generating database support code on one platform to be used on > another you have to be careful not to depend on platform-specific > definitions (or hack things around to match). I am pretty sure the > above error is caused by your use of struct timeval. > > One way to resolve this would be to map timeval to a value type that > has a platform-independent definition. Something along these lines > (the mapping might need some type casting to get rid of warnings): > > #pragma db value > struct odb_timeval > { > std::int64_t tv_sec; > std::int64_t tv_usec; > }; > > #pragma db map type(timeval) as(odb_timeval) \ > to(odb_timeval{(?).tv_sec, (?).tv_usec}) \ > from(timeval{(?).tv_sec, (?).tv_usec}) > -- Juan Pablo Samper Software Tooling and Infrastucture Apex.AI www.apex.ai From boris at codesynthesis.com Wed Aug 26 08:55:46 2020 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Aug 26 09:12:18 2020 Subject: [odb-users] Support for ODB on QNX In-Reply-To: References: Message-ID: Juan Pablo Samper writes: > I also get that we have to be careful to not use platform-specific > constructs; however, QNX defines its own timeval, which wraps the > platform-specific part (e.g. __time_t). > The ODB compiler seems to be using information from the underlying Linux > implementation of timeval which negates the QNX wrapper. Yes, it uses Linux headers since you built the ODB compiler to use host's GCC. If your QNX cross-compiler is also GCC and has plugin support enabled, then theoretically you could build ODB to use that (and thus QNX headers), however, we never tried anything like that. Note also that depending on platform-specific definitions has other drawbacks. For example, POSIX does not define the size of types used in the timeval definition and the implementation is free to change them from release to release. So you may end up with different and incompatible database schemas on, say, qnx6.0.0 and qnx7.0.0. Overall, depending on platform-specific definitions for database mapping is a can of worms that we strongly recommend one does not open. From jp.samper at apex.ai Thu Aug 27 14:18:30 2020 From: jp.samper at apex.ai (Juan Pablo Samper) Date: Fri Aug 28 10:41:04 2020 Subject: [odb-users] Support for ODB on QNX In-Reply-To: References: Message-ID: Hi Boris, Thanks for your advice. I think we'll avoid opening that can of worms for now. I do have a stupid question, though: You suggested that we "map timeval to a value type that has a platform-independent definition." Should we be using this mapping instead of or in addition to #pragma db value(timeval) definition. In other words, should the code be: // #pragma db value(timeval) definition #pragma db value struct odb_timeval { std::int64_t tv_sec; std::int64_t tv_usec; }; #pragma db map type(timeval) as(odb_timeval) \ to(odb_timeval{(?).tv_sec, (?).tv_usec}) \ from(timeval{(?).tv_sec, (?).tv_usec}) OR #pragma db value(timeval) definition #pragma db value struct odb_timeval { std::int64_t tv_sec; std::int64_t tv_usec; }; #pragma db map type(timeval) as(odb_timeval) \ to(odb_timeval{(?).tv_sec, (?).tv_usec}) \ from(timeval{(?).tv_sec, (?).tv_usec}) Thanks! JP On Wed, Aug 26, 2020 at 5:55 AM Boris Kolpackov wrote: > Juan Pablo Samper writes: > > > I also get that we have to be careful to not use platform-specific > > constructs; however, QNX defines its own timeval, which wraps the > > platform-specific part (e.g. __time_t). > > The ODB compiler seems to be using information from the underlying Linux > > implementation of timeval which negates the QNX wrapper. > > Yes, it uses Linux headers since you built the ODB compiler to use > host's GCC. If your QNX cross-compiler is also GCC and has plugin > support enabled, then theoretically you could build ODB to use that > (and thus QNX headers), however, we never tried anything like that. > > Note also that depending on platform-specific definitions has other > drawbacks. For example, POSIX does not define the size of types used > in the timeval definition and the implementation is free to change > them from release to release. So you may end up with different and > incompatible database schemas on, say, qnx6.0.0 and qnx7.0.0. > > Overall, depending on platform-specific definitions for database > mapping is a can of worms that we strongly recommend one does not > open. > -- Juan Pablo Samper Software Tooling and Infrastucture Apex.AI www.apex.ai From boris at codesynthesis.com Mon Aug 31 10:12:54 2020 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Aug 31 10:29:44 2020 Subject: [odb-users] Support for ODB on QNX In-Reply-To: References: Message-ID: Juan Pablo Samper writes: > You suggested that we "map timeval to a value type that has a platform- > independent definition." Should we be using this mapping instead of or > in addition to #pragma db value(timeval) definition. You would use it instead. Essentially, you are telling ODB to pretend timeval is odb_timeval, where database mapping is concerned. From jp.samper at apex.ai Mon Aug 31 10:54:07 2020 From: jp.samper at apex.ai (Juan Pablo Samper) Date: Tue Sep 1 10:25:03 2020 Subject: [odb-users] Support for ODB on QNX In-Reply-To: References: Message-ID: Hi Boris, Great, that's what we thought. Everything seems to be working now! Thanks a lot for your help. Cheers! JP On Mon, Aug 31, 2020 at 7:13 AM Boris Kolpackov wrote: > Juan Pablo Samper writes: > > > You suggested that we "map timeval to a value type that has a platform- > > independent definition." Should we be using this mapping instead of or > > in addition to #pragma db value(timeval) definition. > > You would use it instead. Essentially, you are telling ODB to pretend > timeval is odb_timeval, where database mapping is concerned. > -- Juan Pablo Samper Software Tooling and Infrastucture Apex.AI www.apex.ai