1:48 p.m.
Hello,
I got an error (see below) while compiling the latest version (1.3),
although I haven't had any problems with 1.2.99.x versions. I'd greatly
appreciate any help.
Regards,
Vlad.
Configure parameters
***********************************************************************
./configure --prefix=/usr --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --libdir=/usr/lib64
--disable-dependency-tracking --with-rst2man=/usr/bin/rst2man.py
--with-rst2html=/usr/bin/rst2html.py --enable-dbus-service
--disable-akonadi --disable-bluetooth --enable-dav --disable-sqlite
--enable-ebook --enable-ecal --enable-gnome-keyring --disable-kwallet
--disable-xmlrpc --disable-sqlite --disable-file
--disable-gnome-bluetooth-panel-plugin --enable-gui=gtk --enable-gtk=2
--enable-notify --disable-maintainer-mode
CONFIGURATION SUMMARY
Core SyncEvolution: yes
activesync: no
addressbook: no
akonadi: no
ebook: yes
ecal: yes
file: no
kcalextended: no
maemocal: no
qtcontacts: no
sqlite: no
dav: yes
xmlrpc: no
DBus service: yes
Notifications: yes
GIO GDBus: yes
GNOME keyring: yes
UI (DBus client): gtk (using gtk+-2.0)
Bluetooth transport: no
GNOME Bluetooth panel plugin: no
SHA-256: glib
API documentation: no
D-Bus Timeout Hack: yes
***********************************************************************
Compilation error
***********************************************************************
cp test/syncevo-phone-config.py src/syncevo-phone-config
perl -e '$syncfound=0; $sourcefound=0; $res=0;' \
-e 'sub run { $cmd = shift; $buffer = `env
LD_LIBRARY_PATH=src/syncevo/.libs:src/gdbus/.libs:src/gdbusxx/.libs:src/build-synthesis/src/.libs:$ENV{LD_LIBRARY_PATH}
$cm
d`; die if $?; return $buffer; }' \
-e 'while (<>) {' \
-e 's/^:Version: .*/:Version: 1.3/;' \
-e 's/:Date: .*/":Date: " . `date +%Y-%m-%d`/e;' \
-e 'if (s;(<< see "syncevolution --sync-property ."
>>\n);run("src/syncevolution --daemon=no --sync-property ?") || $1;e) {
$syncfound=1; }' \
-e 'if (s;(<< see "syncevolution --source-property ."
>>\n);run("src/syncevolution --daemon=no --source-property ?") || $1;e) {
$sourcefound=1; }' \
-e 'print;' \
-e '}' \
-e 'die "<<sync-property>> tag not in
README.rst?!" unless $syncfound;' \
-e 'die "<<source-property>> tag not in
README.rst?!" unless $sourcefound;' \
-e 'exit $res;' \
README.rst >README.patched.rst
syncevolution: /usr/include/boost/smart_ptr/shared_ptr.hpp:418:
boost::shared_ptr<T>::reference boost::shared_ptr<T>::operator*() const [with
T =
boost::signals2::detail::connection_body<std::pair<boost::signals2::detail::slot_meta_group,
boost::optional<int> >, boost::signals2::slot4<bool, const
SyncEvo::InitStateTri&, const std::basic_string<char>&, const
std::basic_string<char>&, const SyncEvo::ConfigPasswordKey&,
boost::function<bool(const SyncEvo::InitStateTri&, const
std::basic_string<char>&, const std::basic_string<char>&, const
SyncEvo::ConfigPasswordKey&)> >, boost::signals2::mutex>;
boost::shared_ptr<T>::reference =
boost::signals2::detail::connection_body<std::pair<boost::signals2::detail::slot_meta_group,
boost::optional<int> >, boost::signals2::slot4<bool, const
SyncEvo::InitStateTri&, const std::basic_string<char>&, const
std::basic_string<char>&, const SyncEvo::ConfigPasswordKey&,
boost::function<bool(const SyncEvo::InitStateTri&, const
std::basic_string<char>&, const std::basic_string<char>&, const
SyncEvo::ConfigPasswordKey&)> >, boost::signals2::mutex>&]: Assertion `px
!= 0' failed.
Died at -e line 2, <> line 674.
make[2]: *** [README.patched.rst] Error 255
make[2]: *** Deleting file `README.patched.rst'
make[2]: Leaving directory
`/mnt/portage/tmp/portage/app-pda/syncevolution-1.3/work/syncevolution-1.3'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/mnt/portage/tmp/portage/app-pda/syncevolution-1.3/work/syncevolution-1.3'
make: *** [all] Error 2
***********************************************************************
1:56 p.m.
On Thu, 2012-09-13 at 14:48 +0200, Elisseev V. wrote:
Hello,
I got an error (see below) while compiling the latest version (1.3),
although I haven't had any problems with 1.2.99.x versions. I'd greatly
appreciate any help.
Which was the latest 1.2.99.x that worked?
The problem is in the invocation of
LD_LIBRARY_PATH=src/syncevo/.libs:src/gdbus/.libs:src/gdbusxx/.libs:src/build-synthesis/src/.libs:$LD_LIBRARY_PATH
src/syncevolution --daemon=no --sync-property ?
Can you run that in your build dir? Does it also crash? If yes, please
run in gdb with the same parameters and capture a stack backtrace.
It would be nice to generate the property help without having to run the
SyncEvolution binary, but that's a major change.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
2:40 p.m.
Patrick,
The latest properly compiled version was 1.2.99.4.
The command line you specified, in deed, craches...
When I run gdb it says:
"/mnt/portage/tmp/portage/app-pda/syncevolution-1.3/work/syncevolution-1.3/src/syncevolution":
not in executable format: File format not recognized
I see that syncevolution is a shell script, but I'm not that familiar with gdb, so I
don't know what would be the right command line parameters.
Regards,
Vladimir.
On Thu, 2012-09-13 at 14:56 +0200, Patrick Ohly wrote:
On Thu, 2012-09-13 at 14:48 +0200, Elisseev V. wrote:
> Hello,
>
> I got an error (see below) while compiling the latest version (1.3),
> although I haven't had any problems with 1.2.99.x versions. I'd greatly
> appreciate any help.
Which was the latest 1.2.99.x that worked?
The problem is in the invocation of
LD_LIBRARY_PATH=src/syncevo/.libs:src/gdbus/.libs:src/gdbusxx/.libs:src/build-synthesis/src/.libs:$LD_LIBRARY_PATH
src/syncevolution --daemon=no --sync-property ?
Can you run that in your build dir? Does it also crash? If yes, please
run in gdb with the same parameters and capture a stack backtrace.
It would be nice to generate the property help without having to run the
SyncEvolution binary, but that's a major change.
2:54 p.m.
On Thu, 2012-09-13 at 15:40 +0200, Vladimir Elisseev wrote:
Patrick,
The latest properly compiled version was 1.2.99.4.
The command line you specified, in deed, craches...
When I run gdb it says:
"/mnt/portage/tmp/portage/app-pda/syncevolution-1.3/work/syncevolution-1.3/src/syncevolution":
not in executable format: File format not recognized
I see that syncevolution is a shell script, but I'm not that familiar
with gdb, so I don't know what would be the right command line
parameters.
You can run gdb on src/.libs/syncevolution instead of the shell script.
Setting the LD_LIBRARY_PATH manually as suggested should be enough to
get the real binary running.
Then use "run --daemon=no --sync-property ?".
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Open Source Technology Center
Pützstr. 5 Phone: +49-228-2493652
53129 Bonn
Germany
3:36 p.m.
Oke, I've compiled with debugging symbols, so see output of gdb below.
Hopefully it helps. Let me know if you need any other commands (I
mentioned already I'm not familiar with gdb, sorry.)
Regards,
Vlad.
gdb src/.libs/syncevolution
GNU gdb (Gentoo 7.5 p1) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>;...
Reading symbols from
/mnt/portage/tmp/portage/app-pda/syncevolution-1.3/work/syncevolution-1.3/src/.libs/syncevolution...done.
(gdb) run --daemon=no --sync-property
Starting program:
/mnt/portage/tmp/portage/app-pda/syncevolution-1.3/work/syncevolution-1.3/src/.libs/syncevolution
--daemon=no --sync-property
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
syncevolution: /usr/include/boost/smart_ptr/shared_ptr.hpp:418:
boost::shared_ptr<T>::reference boost::shared_ptr<T>::operator*() const [with
T =
boost::signals2::detail::connection_body<std::pair<boost::signals2::detail::slot_meta_group,
boost::optional<int> >, boost::signals2::slot4<bool, const
SyncEvo::InitStateTri&, const std::basic_string<char>&, const
std::basic_string<char>&, const SyncEvo::ConfigPasswordKey&,
boost::function<bool(const SyncEvo::InitStateTri&, const
std::basic_string<char>&, const std::basic_string<char>&, const
SyncEvo::ConfigPasswordKey&)> >, boost::signals2::mutex>;
boost::shared_ptr<T>::reference =
boost::signals2::detail::connection_body<std::pair<boost::signals2::detail::slot_meta_group,
boost::optional<int> >, boost::signals2::slot4<bool, const
SyncEvo::InitStateTri&, const std::basic_string<char>&, const
std::basic_string<char>&, const SyncEvo::ConfigPasswordKey&,
boost::function<bool(const SyncEvo::InitStateTri&, const
std::basic_string<char>&, const std::basic_string<char>&, const
SyncEvo::ConfigPasswordKey&)> >, boost::signals2::mutex>&]: Assertion `px
!= 0' failed.
Program received signal SIGABRT, Aborted.
0x0000003689237b85 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x0000003689237b85 in raise () from /lib64/libc.so.6
#1 0x0000003689238ffb in abort () from /lib64/libc.so.6
#2 0x0000003689230c2e in ?? () from /lib64/libc.so.6
#3 0x0000003689230cd2 in __assert_fail () from /lib64/libc.so.6
#4 0x00007ffff7b678eb in
boost::shared_ptr<boost::signals2::detail::connection_body<std::pair<boost::signals2::detail::slot_meta_group,
boost::optional<int> >, boost::signals2::slot4<bool, SyncEvo::InitStateTri
const&, std::string const&, std::string const&, SyncEvo::ConfigPasswordKey
const&, boost::function<bool (SyncEvo::InitStateTri const&, std::string
const&, std::string const&, SyncEvo::ConfigPasswordKey const&)> >,
boost::signals2::mutex> >::operator*() const (this=<optimized out>)
at /usr/include/boost/smart_ptr/shared_ptr.hpp:418
#5 0x00007ffff7b6abd4 in operator* (this=<optimized out>) at
/usr/include/boost/smart_ptr/shared_ptr.hpp:418
#6 connection_bodies (this=<optimized out>) at
/usr/include/boost/signals2/detail/signal_template.hpp:392
#7 boost::signals2::detail::signal4_impl<bool, SyncEvo::InitStateTri const&,
std::string const&, std::string const&, SyncEvo::ConfigPasswordKey const&,
SyncEvo::TrySlots, int, std::less<int>, boost::function<bool
(SyncEvo::InitStateTri const&, std::string const&, std::string const&,
SyncEvo::ConfigPasswordKey const&)>, boost::function<bool
(boost::signals2::connection const&, SyncEvo::InitStateTri const&, std::string
const&, std::string const&, SyncEvo::ConfigPasswordKey const&)>,
boost::signals2::mutex>::nolock_cleanup_connections_from(bool,
std::_List_iterator<boost::shared_ptr<boost::signals2::detail::connection_body<std::pair<boost::signals2::detail::slot_meta_group,
boost::optional<int> >, boost::signals2::slot4<bool, SyncEvo::InitStateTri
const&, std::string const&, std::string const&, SyncEvo::ConfigPasswordKey
const&, boost::function<bool (SyncEvo::InitStateTri const&, std::string
const&, std::string const&, SyncEvo::ConfigPasswordKey const&)> >,
boost::signals2::mutex> > > const&, unsigned int) const (
this=0x664c00, grab_tracked=true, begin=..., count=2) at
/usr/include/boost/signals2/detail/signal_template.hpp:449
#8 0x00007ffff7b6ac98 in boost::signals2::detail::signal4_impl<bool,
SyncEvo::InitStateTri const&, std::string const&, std::string const&,
SyncEvo::ConfigPasswordKey const&, SyncEvo::TrySlots, int, std::less<int>,
boost::function<bool (SyncEvo::InitStateTri const&, std::string const&,
std::string const&, SyncEvo::ConfigPasswordKey const&)>,
boost::function<bool (boost::signals2::connection const&, SyncEvo::InitStateTri
const&, std::string const&, std::string const&, SyncEvo::ConfigPasswordKey
const&)>, boost::signals2::mutex>::nolock_cleanup_connections(bool, unsigned
int) const (this=<optimized out>, grab_tracked=grab_tracked@entry=true,
count=count@entry=2)
at /usr/include/boost/signals2/detail/signal_template.hpp:469
#9 0x00007ffff7bec04f in boost::signals2::detail::signal4_impl<bool,
SyncEvo::InitStateTri const&, std::string const&, std::string const&,
SyncEvo::ConfigPasswordKey const&, SyncEvo::TrySlots, int, std::less<int>,
boost::function<bool (SyncEvo::InitStateTri const&, std::string const&,
std::string const&, SyncEvo::ConfigPasswordKey const&)>,
boost::function<bool (boost::signals2::connection const&, SyncEvo::InitStateTri
const&, std::string const&, std::string const&, SyncEvo::ConfigPasswordKey
const&)>, boost::signals2::mutex>::nolock_force_unique_connection_list()
(this=this@entry=0x664c00) at /usr/include/boost/signals2/detail/signal_template.hpp:484
#10 0x00007ffff7bec0c8 in boost::signals2::detail::signal4_impl<bool,
SyncEvo::InitStateTri const&, std::string const&, std::string const&,
SyncEvo::ConfigPasswordKey const&, SyncEvo::TrySlots, int, std::less<int>,
boost::function<bool (SyncEvo::InitStateTri const&, std::string const&,
std::string const&, SyncEvo::ConfigPasswordKey const&)>,
boost::function<bool (boost::signals2::connection const&, SyncEvo::InitStateTri
const&, std::string const&, std::string const&, SyncEvo::ConfigPasswordKey
const&)>,
boost::signals2::mutex>::create_new_connection(boost::signals2::slot4<bool,
SyncEvo::InitStateTri const&, std::string const&, std::string const&,
SyncEvo::ConfigPasswordKey const&, boost::function<bool (SyncEvo::InitStateTri
const&, std::string const&, std::string const&, SyncEvo::ConfigPasswordKey
const&)> > const&) (this=this@entry=0x664c00,
slot=...) at /usr/include/boost/signals2/detail/signal_template.hpp:510
#11 0x00007ffff7bec2d3 in boost::signals2::detail::signal4_impl<bool,
SyncEvo::InitStateTri const&, std::string const&, std::string const&,
SyncEvo::ConfigPasswordKey const&, SyncEvo::TrySlots, int, std::less<int>,
boost::function<bool (SyncEvo::InitStateTri const&, std::string const&,
std::string const&, SyncEvo::ConfigPasswordKey const&)>,
boost::function<bool (boost::signals2::connection const&, SyncEvo::InitStateTri
const&, std::string const&, std::string const&, SyncEvo::ConfigPasswordKey
const&)>, boost::signals2::mutex>::nolock_connect(int const&,
boost::signals2::slot4<bool, SyncEvo::InitStateTri const&, std::string const&,
std::string const&, SyncEvo::ConfigPasswordKey const&, boost::function<bool
(SyncEvo::InitStateTri const&, std::string const&, std::string const&,
SyncEvo::ConfigPasswordKey const&)> > const&,
boost::signals2::connect_position) (this=0x664c00, group=@0x7fffffffd75c: 1, slot=...,
position=boost::signals2::at_back) at
/usr/include/boost/signals2/detail/signal_template.hpp:564
#12 0x00007ffff590397c in SyncEvo::GNOMEInit::GNOMEInit() () from
/usr/lib64/syncevolution/backends/platformgnome.so
#13 0x0000003687a0e50e in ?? () from /lib64/ld-linux-x86-64.so.2
#14 0x0000003687a0e5f6 in ?? () from /lib64/ld-linux-x86-64.so.2
#15 0x0000003687a12782 in ?? () from /lib64/ld-linux-x86-64.so.2
#16 0x0000003687a0e336 in ?? () from /lib64/ld-linux-x86-64.so.2
#17 0x0000003687a11fba in ?? () from /lib64/ld-linux-x86-64.so.2
#18 0x0000003689a010d6 in ?? () from /lib64/libdl.so.2
#19 0x0000003687a0e336 in ?? () from /lib64/ld-linux-x86-64.so.2
#20 0x0000003689a0166f in ?? () from /lib64/libdl.so.2
#21 0x0000003689a01171 in dlopen () from /lib64/libdl.so.2
#22 0x00007ffff7b84ec2 in SyncEvo::ScannedModules::ScannedModules (this=0x7ffff7fd1fa0
<SyncEvo::scannedModules>) at src/syncevo/SyncSource.cpp:340
#23 0x00007ffff7ad6b0e in __static_initialization_and_destruction_0
(__initialize_p=<optimized out>, __priority=<optimized out>) at
src/syncevo/SyncSource.cpp:363
#24 _GLOBAL__sub_I_SyncSource.cpp(void) () at src/syncevo/SyncSource.cpp:1517
#25 0x0000003687a0e50e in ?? () from /lib64/ld-linux-x86-64.so.2
#26 0x0000003687a0e5f6 in ?? () from /lib64/ld-linux-x86-64.so.2
#27 0x0000003687a0173a in ?? () from /lib64/ld-linux-x86-64.so.2
#28 0x0000000000000003 in ?? ()
#29 0x00007fffffffe173 in ?? ()
#30 0x00007fffffffe1d5 in ?? ()
#31 0x00007fffffffe1e1 in ?? ()
#32 0x0000000000000000 in ?? ()
On Thu, 2012-09-13 at 15:54 +0200, Patrick Ohly wrote:
On Thu, 2012-09-13 at 15:40 +0200, Vladimir Elisseev wrote:
> Patrick,
>
> The latest properly compiled version was 1.2.99.4.
> The command line you specified, in deed, craches...
> When I run gdb it says:
>
"/mnt/portage/tmp/portage/app-pda/syncevolution-1.3/work/syncevolution-1.3/src/syncevolution":
not in executable format: File format not recognized
>
> I see that syncevolution is a shell script, but I'm not that familiar
> with gdb, so I don't know what would be the right command line
> parameters.
You can run gdb on src/.libs/syncevolution instead of the shell script.
Setting the LD_LIBRARY_PATH manually as suggested should be enough to
get the real binary running.
Then use "run --daemon=no --sync-property ?".
4:28 p.m.
On Thu, 2012-09-13 at 16:36 +0200, Vladimir Elisseev wrote:
Oke, I've compiled with debugging symbols, so see output of gdb
below.
Hopefully it helps. Let me know if you need any other commands (I
mentioned already I'm not familiar with gdb, sorry.)
I see roughly where it crashes, but I have no idea why. It looks like a
boost::signals2 internal boost::shared_ptr is empty at a time when
boost::signals2 expects it to be set.
SyncEvolution is careful to work with real singletons her (instances
initialized in a function before returning a pointer to them), so it is
not a problem of using a global instance which has not been initialized
yet at a time when another global instance constructor tries to use it -
I hope Boost itself is not making that mistake.
Did the version of Boost perhaps change since the last time that you
built SyncEvolution? Can you double-check by recompiling SyncEvolution
1.2.99.4 with the current set of system libraries?
Alternatively (or in addition), can you compile with "-O0 -g" and
produce another stack backtrace? It might be a bit more informative.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
4:50 p.m.
Patrick,
Thanks for the tip! This isn't boost, but new gcc (migrated from 4.6.3
to 4.7.1). Since it's not syncevolution related, I'll try to investigate
what is the problem. Sorry for taking your time.
Regards,
Vlad.
On Thu, 2012-09-13 at 17:28 +0200, Patrick Ohly wrote:
On Thu, 2012-09-13 at 16:36 +0200, Vladimir Elisseev wrote:
> Oke, I've compiled with debugging symbols, so see output of gdb below.
> Hopefully it helps. Let me know if you need any other commands (I
> mentioned already I'm not familiar with gdb, sorry.)
I see roughly where it crashes, but I have no idea why. It looks like a
boost::signals2 internal boost::shared_ptr is empty at a time when
boost::signals2 expects it to be set.
SyncEvolution is careful to work with real singletons her (instances
initialized in a function before returning a pointer to them), so it is
not a problem of using a global instance which has not been initialized
yet at a time when another global instance constructor tries to use it -
I hope Boost itself is not making that mistake.
Did the version of Boost perhaps change since the last time that you
built SyncEvolution? Can you double-check by recompiling SyncEvolution
1.2.99.4 with the current set of system libraries?
Alternatively (or in addition), can you compile with "-O0 -g" and
produce another stack backtrace? It might be a bit more informative.
5:13 p.m.
On Thu, 2012-09-13 at 17:50 +0200, Vladimir Elisseev wrote:
Thanks for the tip! This isn't boost, but new gcc (migrated from
4.6.3
to 4.7.1). Since it's not syncevolution related, I'll try to investigate
what is the problem. Sorry for taking your time.
Not at all, thanks for reporting the problem. It may be relevant for
other people compiling SyncEvolution.
Note that it still could be a bug outside of gcc that is merely
triggered by the compiler update.
I have found (and fixed) bugs in SyncEvolution where the order of global
instance construction was relevant. Those bugs showed up only after a
change in the toolchain reordered global initialization. However, as I
said in the previous mail, in this case I think SyncEvolution is doing
the right thing (forcing construction of instances by embedding them in
a function).
What is your version of Boost and binutils?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
5:38 p.m.
I have:
dev-libs/boost-1.48
sys-devel/binutils-2.22.90
both compiled with the old gcc (4.6.3).
I don't thinks so, but maybe recompiling system packages with the new
gcc helps?
Regards,
Vlad.
On Thu, 2012-09-13 at 18:13 +0200, Patrick Ohly wrote:
On Thu, 2012-09-13 at 17:50 +0200, Vladimir Elisseev wrote:
> Thanks for the tip! This isn't boost, but new gcc (migrated from 4.6.3
> to 4.7.1). Since it's not syncevolution related, I'll try to investigate
> what is the problem. Sorry for taking your time.
Not at all, thanks for reporting the problem. It may be relevant for
other people compiling SyncEvolution.
Note that it still could be a bug outside of gcc that is merely
triggered by the compiler update.
I have found (and fixed) bugs in SyncEvolution where the order of global
instance construction was relevant. Those bugs showed up only after a
change in the toolchain reordered global initialization. However, as I
said in the previous mail, in this case I think SyncEvolution is doing
the right thing (forcing construction of instances by embedding them in
a function).
What is your version of Boost and binutils?
1:35 p.m.
Patrick,
I've been able to compile 1.3 successfully with the latest boost 1.49
instead of 1.48. So it might be wise to mention this as a requirement
for building syncevolution with gcc >=4.7. Thanks for you help!
Regards,
Vlad.
On Thu, 2012-09-13 at 18:38 +0200, Vladimir Elisseev wrote:
I have:
dev-libs/boost-1.48
sys-devel/binutils-2.22.90
both compiled with the old gcc (4.6.3).
I don't thinks so, but maybe recompiling system packages with the new
gcc helps?
Regards,
Vlad.
On Thu, 2012-09-13 at 18:13 +0200, Patrick Ohly wrote:
> On Thu, 2012-09-13 at 17:50 +0200, Vladimir Elisseev wrote:
> > Thanks for the tip! This isn't boost, but new gcc (migrated from 4.6.3
> > to 4.7.1). Since it's not syncevolution related, I'll try to
investigate
> > what is the problem. Sorry for taking your time.
>
> Not at all, thanks for reporting the problem. It may be relevant for
> other people compiling SyncEvolution.
>
> Note that it still could be a bug outside of gcc that is merely
> triggered by the compiler update.
>
> I have found (and fixed) bugs in SyncEvolution where the order of global
> instance construction was relevant. Those bugs showed up only after a
> change in the toolchain reordered global initialization. However, as I
> said in the previous mail, in this case I think SyncEvolution is doing
> the right thing (forcing construction of instances by embedding them in
> a function).
>
> What is your version of Boost and binutils?
>
_______________________________________________
SyncEvolution mailing list
SyncEvolution(a)syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution
3626
days inactive
3627
days old
syncevolution@synevolution.org
9 comments
3 participants
participants (3)
-
Elisseev V. -
Patrick Ohly -
Vladimir Elisseev