cxx-gtk-utils-general Mailing List for c++-gtk-utils
Brought to you by:
cvine
Menu
▾
▴
cxx-gtk-utils-general — Mailing list for the c++-gtk-utils library
You can subscribe to this list here.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(9) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Barry J. <zen...@ze...> - 2016-05-12 16:01:58
|
On 12/05/16 16:03, Chris Vine wrote: > Ah yes. The tests will not be run by a 'make', but they will be > compiled, which is not what you want. There is no configuration option > for this. I am afraid you will need to patch the root Makefile.am file > by hand by omitting '@COND_TESTS@' from the SUBDIRS line, and then run > autoreconf. > > (If you compile with the --without-gtk option, the test suite will also > not be built, but that defeats half the purpose of the library. You > could add a rule to configure.ac which sets COND_TEST to "" and then > AC_SUBST's it near the end (right before AC_CONFIG_FILES), and then run > autreconf, but patching Makefile.am seems easier.) > > Chris > Many thanks, I patched MakeFile.am as suggested and the build now completes OK on ARM. http://pkgsubmit.mageia.org/uploads/done/cauldron/core/release/20160512152546.barjac.duvel.23691/c++-gtk-utils-2.2.13-2.mga6/build.0.20160512152947.log Cheers, Barry |
|
From: Chris V. <ch...@cv...> - 2016-05-12 15:04:00
|
On Thu, 12 May 2016 15:50:07 +0100 Barry Jackson <zen...@ze...> wrote: [snip] > Many thanks for your rapid response :) > Yes we want a distributable package, so skipping the tests would be > fine, however we currently don't call 'make check' in the spec, so > I'm guessing the tests can be disabled in the configuration somewhere? > Our current spec is here: > http://svnweb.mageia.org/packages/cauldron/c%2B%2B-gtk-utils/current/SPECS/c%2B%2B-gtk-utils.spec?view=markup Ah yes. The tests will not be run by a 'make', but they will be compiled, which is not what you want. There is no configuration option for this. I am afraid you will need to patch the root Makefile.am file by hand by omitting '@COND_TESTS@' from the SUBDIRS line, and then run autoreconf. (If you compile with the --without-gtk option, the test suite will also not be built, but that defeats half the purpose of the library. You could add a rule to configure.ac which sets COND_TEST to "" and then AC_SUBST's it near the end (right before AC_CONFIG_FILES), and then run autreconf, but patching Makefile.am seems easier.) Chris |
|
From: Barry J. <zen...@ze...> - 2016-05-12 14:50:18
|
On 12/05/16 15:32, Chris Vine wrote: > On Thu, 12 May 2016 13:14:22 +0100 > Chris Vine <ch...@cv...> wrote: >> On Thu, 12 May 2016 12:09:26 +0100 >> Barry Jackson <zen...@ze...> wrote: >>> Ah - seems I attached the wrong file - this is correct. >>> >>> Barry >>> >> >> It looks like a compiler bug. The error is first reported in line >> 522 of tests/test_task_manager.cpp, and says that std::future<int> >> is an incomplete type, when clearly it is complete. It looks as if >> the compiler cannot find the 'future' class in the std namespace. It >> should be able to do so, because the <future> header is included. >> >> You could try including a 'using namespace std;' statement after the >> 'using namespace Cgu;' in the file test_task_manager.cpp. If that >> fixes it then it is definitely a compiler bug. >> >> The build seems to be using gcc-5.3.1, which should be new enough but >> is not actually a gnu release, I think (gnu has only released >> gcc-5.3.0 in the 5.3 series). > > On looking at it further, it seems that std::future was not supported > by gcc-4.8 on armv5 because of the lack of an appropriate atomic > instruction: the debian error report at > https://gcc.gnu.org/ml/gcc/2014-07/msg00001.html is very similar to > yours. > > So it looks as if that may remain the case with gcc-5.3 (bummer). If so > it looks like a big miss and you are going to find an increasing number > of C++ packages failing to build for this reason, if that is the > reason: std::future is hardly ground-breaking. amd64 seems to be OK. > > You may have better luck with clang and their libc++, I don't know. > You could also look and see if it is fixed in gcc-6.1 (probably not). > > Alternatively, if you want a distributable package, you could just omit > the tests by not having your build system call 'make check' or 'make > tests'. Happily the code in question in c++-gtk-utils is templated and > so not actually instantiated unless it is used (as it is by the test > suite). Of course if users actually try calling a function returning a > std::future object they would then get a compile-time error similar to > yours, but that is a separate issue, and one which they are probably > aware of if using armv5. > > Chris > Many thanks for your rapid response :) Yes we want a distributable package, so skipping the tests would be fine, however we currently don't call 'make check' in the spec, so I'm guessing the tests can be disabled in the configuration somewhere? Our current spec is here: http://svnweb.mageia.org/packages/cauldron/c%2B%2B-gtk-utils/current/SPECS/c%2B%2B-gtk-utils.spec?view=markup Barry |
|
From: Chris V. <ch...@cv...> - 2016-05-12 14:45:45
|
On Thu, 12 May 2016 15:32:45 +0100 Chris Vine <ch...@cv...> wrote: > amd64 seems to be OK. I meant arm64/aarch64/armv8, whatever you happen to call it. (amd64 is also OK, but hardly relevant to this.) Chris |
|
From: Chris V. <ch...@cv...> - 2016-05-12 14:33:22
|
On Thu, 12 May 2016 13:14:22 +0100 Chris Vine <ch...@cv...> wrote: > On Thu, 12 May 2016 12:09:26 +0100 > Barry Jackson <zen...@ze...> wrote: > > Ah - seems I attached the wrong file - this is correct. > > > > Barry > > > > It looks like a compiler bug. The error is first reported in line > 522 of tests/test_task_manager.cpp, and says that std::future<int> > is an incomplete type, when clearly it is complete. It looks as if > the compiler cannot find the 'future' class in the std namespace. It > should be able to do so, because the <future> header is included. > > You could try including a 'using namespace std;' statement after the > 'using namespace Cgu;' in the file test_task_manager.cpp. If that > fixes it then it is definitely a compiler bug. > > The build seems to be using gcc-5.3.1, which should be new enough but > is not actually a gnu release, I think (gnu has only released > gcc-5.3.0 in the 5.3 series). On looking at it further, it seems that std::future was not supported by gcc-4.8 on armv5 because of the lack of an appropriate atomic instruction: the debian error report at https://gcc.gnu.org/ml/gcc/2014-07/msg00001.html is very similar to yours. So it looks as if that may remain the case with gcc-5.3 (bummer). If so it looks like a big miss and you are going to find an increasing number of C++ packages failing to build for this reason, if that is the reason: std::future is hardly ground-breaking. amd64 seems to be OK. You may have better luck with clang and their libc++, I don't know. You could also look and see if it is fixed in gcc-6.1 (probably not). Alternatively, if you want a distributable package, you could just omit the tests by not having your build system call 'make check' or 'make tests'. Happily the code in question in c++-gtk-utils is templated and so not actually instantiated unless it is used (as it is by the test suite). Of course if users actually try calling a function returning a std::future object they would then get a compile-time error similar to yours, but that is a separate issue, and one which they are probably aware of if using armv5. Chris |
|
From: Chris V. <ch...@cv...> - 2016-05-12 12:44:42
|
On Thu, 12 May 2016 12:09:26 +0100 Barry Jackson <zen...@ze...> wrote: > Ah - seems I attached the wrong file - this is correct. > > Barry > It looks like a compiler bug. The error is first reported in line 522 of tests/test_task_manager.cpp, and says that std::future<int> is an incomplete type, when clearly it is complete. It looks as if the compiler cannot find the 'future' class in the std namespace. It should be able to do so, because the <future> header is included. You could try including a 'using namespace std;' statement after the 'using namespace Cgu;' in the file test_task_manager.cpp. If that fixes it then it is definitely a compiler bug. The build seems to be using gcc-5.3.1, which should be new enough but is not actually a gnu release, I think (gnu has only released gcc-5.3.0 in the 5.3 series). Chris |
|
From: Barry J. <zen...@ze...> - 2016-05-12 11:09:44
|
Ah - seems I attached the wrong file - this is correct. Barry |
|
From: Barry J. <zen...@ze...> - 2016-05-12 11:00:55
|
On 12/05/16 11:18, Barry Jackson wrote: > Build fails in Mageia arm. > There is no problem in x86 (32 or 64bit) > > I could not create an issue on the bug tracker due to some permissions > issue so am reporting here. > > Full build log is attached. Why was my attachment truncated? This is really frustrating - please advise how I can report a bug and attach a log for c++-gtk-utils. Thanks Barry |
|
From: Barry J. <zen...@ze...> - 2016-05-12 10:39:59
|
Build fails in Mageia arm. There is no problem in x86 (32 or 64bit) I could not create an issue on the bug tracker due to some permissions issue so am reporting here. Full build log is attached. Any help will be appreciated. Barry |
|
From: Chris V. <ch...@cv...> - 2015-12-03 11:25:00
|
On Wed, 2 Dec 2015 12:59:43 -0800 Andy Tai <at...@at...> wrote: > Hi, just curious if there is any plan to wrap gtk+ widgets in C++? Or > ideally wrap gtk+ objects as C++ objects, via C++ templates... Hi Andy, Not really. The wrapping for GTK+ widgets is provided by Cgu::MainWidgetBase and Cgu::GobjHandle. These are really just objects to handle GObject (or GtkWidget) lifetimes for RAII purposes, so are not really a wrapper in the traditional sense: to operate on them you use the native GTK+ functions. gtkmm provides the kind of wrapping that you may be after (although it struggles with thread safety). Chris |
|
From: Andy T. <at...@at...> - 2015-12-02 20:59:51
|
Hi, just curious if there is any plan to wrap gtk+ widgets in C++? Or ideally wrap gtk+ objects as C++ objects, via C++ templates... -- Andy Tai, at...@at..., Skype: licheng.tai Year 2015 民國104年 自動的精神力是信仰與覺悟 自動的行為力是勞動與技能 |
|
From: Chris V. <ch...@cv...> - 2013-01-29 19:46:26
|
On Tue, 29 Jan 2013 11:02:32 -0600 "Jeff P. Zacher" <ad_...@ya...> wrote: > Do I need a so file built to link against to use window.h? I am > getting undefined reference errors to symbols in the cgu namespace > durning the link phase...I installed from the package manager in > Sabayon... Hi, The Cgu::WinBase class is compiled into the library rather than being templated into a header file only, so you do need the accompanying library binary, which could be an archive (*.a file) or a dynamically linked shared library (*.so file). I do not know how the Sabayon distribution organises its packages I am afraid, but I should be surprised if the library binaries were not included. Do you have a libcxx-gtk-utils* files appearing in /usr/lib? If you do, possibly your own project has not incorporated the result of 'pkg-config --libs' into its linker list. What build system are you using? Chris |
|
From: Jeff P. Z. <ad_...@ya...> - 2013-01-29 17:02:44
|
Do I need a so file built to link against to use window.h? I am getting undefined reference errors to symbols in the cgu namespace durning the link phase...I installed from the package manager in Sabayon... |
|
From: Chris V. <ch...@cv...> - 2010-04-14 10:28:45
|
test |
