Discussion:
[Wt-interest] WApplication / WMenu boost-connection duplicate-section issue
K. Frank
2015-07-15 14:06:05 UTC
Permalink
Hello List!

I get "duplicate section ... has different size" messages when I
build a Wt application that contains (as far as I can tell) a call
to:

internalPathChanged().connect (...);

First question: Do I care?

My tool-chain does not flag this as a warning or error, and my
very simple Wt apps (that I don't really know how to test) seem
to work.

Second: Can I make this go away?

Third: Does anyone else care? I could try to provide more
information if someone could tell me what to look for.

Details:

This is wt-3.3.3 built with mingw-w64 on 64-bit windows 7:

C:\...\wt_test>g++ --version
g++ (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 4.9.2

When I build (link) my test program, I get the following par of messages:

C:\...\wt_test>g++ -std=gnu++14 -o section section.cpp -lwt
-lwthttp -lboost_date_time-mgw49-1_57 -lboost_filesystem-mgw49-1_57
-lboost_program_options-mgw49-1_57 -lboost_random-mgw49-1_57
-lboost_regex-mgw49-1_57 -lboost_system-mgw49-1_57
-lboost_thread-mgw49-mt-s-1_57 -lws2_32 -lwsock32
C:/.../wt-3.3.3_install/WT/lib/../lib/libwt.a(WApplication.obj):
duplicate section
`.rdata$_ZTIN5boost8signals26signalIFvSsN2Wt7NoClassES3_S3_S3_S3_ENS0_19optional_last_valueIvEEiSt4lessIiENS_8functionIS4_EENS9_IFvRKNS0_10connectionESsS3_S3_S3_S3_S3_EEENS0_5mutexEEE[_ZTIN5boost8signals26signalIFvSsN2Wt7NoClassES3_S3_S3_S3_ENS0_19optional_last_valueIvEEiSt4lessIiENS_8functionIS4_EENS9_IFvRKNS0_10connectionESsS3_S3_S3_S3_S3_EEENS0_5mutexEEE]'
has different size
C:/.../wt-3.3.3_install/WT/lib/../lib/libwt.a(WMenu.obj): duplicate
section `.rdata$_ZTIN5boost8signals26signalIFvSsN2Wt7NoClassES3_S3_S3_S3_ENS0_19optional_last_valueIvEEiSt4lessIiENS_8functionIS4_EENS9_IFvRKNS0_10connectionESsS3_S3_S3_S3_S3_EEENS0_5mutexEEE[_ZTIN5boost8signals26signalIFvSsN2Wt7NoClassES3_S3_S3_S3_ENS0_19optional_last_valueIvEEiSt4lessIiENS_8functionIS4_EENS9_IFvRKNS0_10connectionESsS3_S3_S3_S3_S3_EEENS0_5mutexEEE]'
has different size

This seems to have something to do with boost signals or boost
connection. As mentioned above, this happens when I have an
internalPathChanged().connect (...); call in my program. (See the
test program, below, for explicit detail.)

I built boost and the Wt libraries using the documented build procedures,
using the same tool-chain that I use for my test program. The compile
options I used for my test program are given in the compile command line
shown above, and the compile options used for boost and Wt are whatever
the standard build procedure had configured. (I didn't do anything special.)

The duplicate-section messages seems to be complaining about
WApplication.obj and WMenu.obj. These were compiled at the same time
when I built the Wt libraries all at once, so presumably they were compiled
with the same compiler options (but the standard build procedure could
have used different options for some reason).

My test program appears below. Note that not all connect calls trigger this
issue. If I comment out the line:

internalPathChanged().connect (this, SectionApp::dummy);

the duplicate-section messages go away.

(Note, none of the WPushButton stuff is necessary to trigger the
issue. If I comment out all of the WPushButton stuff, the issue
persists. I only included the WPushButton example to show that
button_->clicked().connect (this, SectionApp::dummy); doesn't
trigger the issue.)


Thanks.


K. Frank


section.cpp:

====================

#include <Wt/WApplication>
#include <Wt/WEnvironment>
#include <Wt/WPushButton>

using namespace Wt;

class SectionApp : public WApplication {
public:
SectionApp (const WEnvironment& env) : WApplication (env) {
setTitle ("Section Test");

// this line triggers "duplicate section"
internalPathChanged().connect (this, SectionApp::dummy);

button_ = new WPushButton ("button", root());
// this line does not
button_->clicked().connect (this, SectionApp::dummy);
}
void dummy() {}

private:
WPushButton *button_;

};

WApplication *createApplication(const WEnvironment& env) {
return new SectionApp (env);
}

int main (int argc, char *argv[]) {
return WRun (argc, argv, &createApplication);
}

====================
Koen Deforche
2015-07-15 14:11:35 UTC
Permalink
Hey,

Since you're building your test case with a C++14 compiler, you probably
didn't build Wt with the same compile flags.
See the WT_CPP_11_MODE CMake flag for building Wt.

Regards,
koen
Post by K. Frank
Hello List!
I get "duplicate section ... has different size" messages when I
build a Wt application that contains (as far as I can tell) a call
internalPathChanged().connect (...);
First question: Do I care?
My tool-chain does not flag this as a warning or error, and my
very simple Wt apps (that I don't really know how to test) seem
to work.
Second: Can I make this go away?
Third: Does anyone else care? I could try to provide more
information if someone could tell me what to look for.
C:\...\wt_test>g++ --version
g++ (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 4.9.2
C:\...\wt_test>g++ -std=gnu++14 -o section section.cpp -lwt
-lwthttp -lboost_date_time-mgw49-1_57 -lboost_filesystem-mgw49-1_57
-lboost_program_options-mgw49-1_57 -lboost_random-mgw49-1_57
-lboost_regex-mgw49-1_57 -lboost_system-mgw49-1_57
-lboost_thread-mgw49-mt-s-1_57 -lws2_32 -lwsock32
duplicate section
`.rdata$_ZTIN5boost8signals26signalIFvSsN2Wt7NoClassES3_S3_S3_S3_ENS0_19optional_last_valueIvEEiSt4lessIiENS_8functionIS4_EENS9_IFvRKNS0_10connectionESsS3_S3_S3_S3_S3_EEENS0_5mutexEEE[_ZTIN5boost8signals26signalIFvSsN2Wt7NoClassES3_S3_S3_S3_ENS0_19optional_last_valueIvEEiSt4lessIiENS_8functionIS4_EENS9_IFvRKNS0_10connectionESsS3_S3_S3_S3_S3_EEENS0_5mutexEEE]'
has different size
C:/.../wt-3.3.3_install/WT/lib/../lib/libwt.a(WMenu.obj): duplicate
section
`.rdata$_ZTIN5boost8signals26signalIFvSsN2Wt7NoClassES3_S3_S3_S3_ENS0_19optional_last_valueIvEEiSt4lessIiENS_8functionIS4_EENS9_IFvRKNS0_10connectionESsS3_S3_S3_S3_S3_EEENS0_5mutexEEE[_ZTIN5boost8signals26signalIFvSsN2Wt7NoClassES3_S3_S3_S3_ENS0_19optional_last_valueIvEEiSt4lessIiENS_8functionIS4_EENS9_IFvRKNS0_10connectionESsS3_S3_S3_S3_S3_EEENS0_5mutexEEE]'
has different size
This seems to have something to do with boost signals or boost
connection. As mentioned above, this happens when I have an
internalPathChanged().connect (...); call in my program. (See the
test program, below, for explicit detail.)
I built boost and the Wt libraries using the documented build procedures,
using the same tool-chain that I use for my test program. The compile
options I used for my test program are given in the compile command line
shown above, and the compile options used for boost and Wt are whatever
the standard build procedure had configured. (I didn't do anything special.)
The duplicate-section messages seems to be complaining about
WApplication.obj and WMenu.obj. These were compiled at the same time
when I built the Wt libraries all at once, so presumably they were compiled
with the same compiler options (but the standard build procedure could
have used different options for some reason).
My test program appears below. Note that not all connect calls trigger this
internalPathChanged().connect (this, SectionApp::dummy);
the duplicate-section messages go away.
(Note, none of the WPushButton stuff is necessary to trigger the
issue. If I comment out all of the WPushButton stuff, the issue
persists. I only included the WPushButton example to show that
button_->clicked().connect (this, SectionApp::dummy); doesn't
trigger the issue.)
Thanks.
K. Frank
====================
#include <Wt/WApplication>
#include <Wt/WEnvironment>
#include <Wt/WPushButton>
using namespace Wt;
class SectionApp : public WApplication {
SectionApp (const WEnvironment& env) : WApplication (env) {
setTitle ("Section Test");
// this line triggers "duplicate section"
internalPathChanged().connect (this, SectionApp::dummy);
button_ = new WPushButton ("button", root());
// this line does not
button_->clicked().connect (this, SectionApp::dummy);
}
void dummy() {}
WPushButton *button_;
};
WApplication *createApplication(const WEnvironment& env) {
return new SectionApp (env);
}
int main (int argc, char *argv[]) {
return WRun (argc, argv, &createApplication);
}
====================
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
witty-interest mailing list
https://lists.sourceforge.net/lists/listinfo/witty-interest
K. Frank
2015-07-15 14:44:41 UTC
Permalink
Hi Koen!
Post by Koen Deforche
Hey,
Since you're building your test case with a C++14 compiler, you probably
didn't build Wt with the same compile flags.
See the WT_CPP_11_MODE CMake flag for building Wt.
Thanks, good catch. My use of "-std=gnu++14" as a compile options does
seem to be triggering this issue. (And yes, I did not explicitly build Wt with
c++11 or c++14.)

I recompiled my test app leaving that option out:

C:\...\wt_test>g++ -o section section.cpp -lwt -lwthttp
-lboost_date_time-mgw49-1_57 -lboost_filesystem-mgw49-1_57
-lboost_program_options-mgw49-1_57 -lboost_random-mgw49-1_57
-lboost_regex-mgw49-1_57 -lboost_system-mgw49-1_57
-lboost_thread-mgw49-mt-s-1_57 -lws2_32 -lwsock32

and the duplicate-section messages go away. So, problem solved! (For now.)

By the way, I tried compiling with "-std=c++11", "-std=gnu++11", "-std=c++14",
as well as "-std=gnu++14". They all trigger the duplicate-session messages;
only leaving out the "-std" option does not.

As a follow-up, does anyone understand what is going on here? I sure
don't. The complaint appears to be about WApplication.obj and WMenu.obj
(extracted from libwt.a). So it's not obvious why compiling my app with
"-std=gnu++14" should affect a match / mismatch between two already
compiled object files. (And why might internalPathChanged().connect()
trigger the issue?)

Also, if I do pursue rebuilding Wt with the WT_CPP_11_MODE option, would
I have to similarly rebuild boost (and would anyone know offhand how to do it)?

And if I at some point want to use c++14 (or c++11) and don't rebuild Wt,
how much should I worry about the duplicate-section messages? Does
anyone know whether they represent a substantive error, or can I blissfully
ignore them.
Post by Koen Deforche
Regards,
koen
Thanks again for your help.


K. Frank
Post by Koen Deforche
Post by K. Frank
Hello List!
I get "duplicate section ... has different size" messages when I
build a Wt application that contains (as far as I can tell) a call
internalPathChanged().connect (...);
...
C:\...\wt_test>g++ --version
g++ (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 4.9.2
C:\...\wt_test>g++ -std=gnu++14 -o section section.cpp -lwt
-lwthttp -lboost_date_time-mgw49-1_57 -lboost_filesystem-mgw49-1_57
-lboost_program_options-mgw49-1_57 -lboost_random-mgw49-1_57
-lboost_regex-mgw49-1_57 -lboost_system-mgw49-1_57
-lboost_thread-mgw49-mt-s-1_57 -lws2_32 -lwsock32
duplicate section
...
Nagaev Boris
2015-07-15 20:17:40 UTC
Permalink
Post by K. Frank
Hi Koen!
Post by Koen Deforche
Hey,
Since you're building your test case with a C++14 compiler, you probably
didn't build Wt with the same compile flags.
See the WT_CPP_11_MODE CMake flag for building Wt.
Thanks, good catch. My use of "-std=gnu++14" as a compile options does
seem to be triggering this issue. (And yes, I did not explicitly build Wt with
c++11 or c++14.)
C:\...\wt_test>g++ -o section section.cpp -lwt -lwthttp
-lboost_date_time-mgw49-1_57 -lboost_filesystem-mgw49-1_57
-lboost_program_options-mgw49-1_57 -lboost_random-mgw49-1_57
-lboost_regex-mgw49-1_57 -lboost_system-mgw49-1_57
-lboost_thread-mgw49-mt-s-1_57 -lws2_32 -lwsock32
and the duplicate-section messages go away. So, problem solved! (For now.)
By the way, I tried compiling with "-std=c++11", "-std=gnu++11", "-std=c++14",
as well as "-std=gnu++14". They all trigger the duplicate-session messages;
only leaving out the "-std" option does not.
As a follow-up, does anyone understand what is going on here? I sure
don't. The complaint appears to be about WApplication.obj and WMenu.obj
(extracted from libwt.a). So it's not obvious why compiling my app with
"-std=gnu++14" should affect a match / mismatch between two already
compiled object files. (And why might internalPathChanged().connect()
trigger the issue?)
Also, if I do pursue rebuilding Wt with the WT_CPP_11_MODE option, would
I have to similarly rebuild boost (and would anyone know offhand how to do it)?
And if I at some point want to use c++14 (or c++11) and don't rebuild Wt,
how much should I worry about the duplicate-section messages? Does
anyone know whether they represent a substantive error, or can I blissfully
ignore them.
Post by Koen Deforche
Regards,
koen
Thanks again for your help.
K. Frank
Post by Koen Deforche
Post by K. Frank
Hello List!
I get "duplicate section ... has different size" messages when I
build a Wt application that contains (as far as I can tell) a call
internalPathChanged().connect (...);
...
C:\...\wt_test>g++ --version
g++ (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 4.9.2
C:\...\wt_test>g++ -std=gnu++14 -o section section.cpp -lwt
-lwthttp -lboost_date_time-mgw49-1_57 -lboost_filesystem-mgw49-1_57
-lboost_program_options-mgw49-1_57 -lboost_random-mgw49-1_57
-lboost_regex-mgw49-1_57 -lboost_system-mgw49-1_57
-lboost_thread-mgw49-mt-s-1_57 -lws2_32 -lwsock32
duplicate section
...
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
witty-interest mailing list
https://lists.sourceforge.net/lists/listinfo/witty-interest
Hi Koen and Wt team,

do you use a Continuous Integration system? If the answer is no, then
please add Travis CI [1]. It is free for open source. It would rebuild
Wt and run tests after each "push" to Github repo according to
".travis.yml" file from the repo. It would report errors. It is also
possible to build multiple targets (different compilers or options).
Appveyor CI is nice service too - it is similar to Travis CI, but uses
Windows instead of Linux. You can count on me to help you.

[1] https://travis-ci.org
--
Best regards,
Boris Nagaev
Koen Deforche
2015-07-16 06:40:27 UTC
Permalink
Hey Boris,

We have been using Jenkins for a few years now, and learned to live with
its warts.
It's monitoring our internal git repository actually, and also builds 'JWt'
from 'Wt'.

Koen
Post by Koen Deforche
Post by K. Frank
Hi Koen!
Post by Koen Deforche
Hey,
Since you're building your test case with a C++14 compiler, you probably
didn't build Wt with the same compile flags.
See the WT_CPP_11_MODE CMake flag for building Wt.
Thanks, good catch. My use of "-std=gnu++14" as a compile options does
seem to be triggering this issue. (And yes, I did not explicitly build
Wt with
Post by K. Frank
c++11 or c++14.)
C:\...\wt_test>g++ -o section section.cpp -lwt -lwthttp
-lboost_date_time-mgw49-1_57 -lboost_filesystem-mgw49-1_57
-lboost_program_options-mgw49-1_57 -lboost_random-mgw49-1_57
-lboost_regex-mgw49-1_57 -lboost_system-mgw49-1_57
-lboost_thread-mgw49-mt-s-1_57 -lws2_32 -lwsock32
and the duplicate-section messages go away. So, problem solved! (For
now.)
Post by K. Frank
By the way, I tried compiling with "-std=c++11", "-std=gnu++11",
"-std=c++14",
Post by K. Frank
as well as "-std=gnu++14". They all trigger the duplicate-session
messages;
Post by K. Frank
only leaving out the "-std" option does not.
As a follow-up, does anyone understand what is going on here? I sure
don't. The complaint appears to be about WApplication.obj and WMenu.obj
(extracted from libwt.a). So it's not obvious why compiling my app with
"-std=gnu++14" should affect a match / mismatch between two already
compiled object files. (And why might internalPathChanged().connect()
trigger the issue?)
Also, if I do pursue rebuilding Wt with the WT_CPP_11_MODE option, would
I have to similarly rebuild boost (and would anyone know offhand how to
do it)?
Post by K. Frank
And if I at some point want to use c++14 (or c++11) and don't rebuild Wt,
how much should I worry about the duplicate-section messages? Does
anyone know whether they represent a substantive error, or can I
blissfully
Post by K. Frank
ignore them.
Post by Koen Deforche
Regards,
koen
Thanks again for your help.
K. Frank
Post by Koen Deforche
Post by K. Frank
Hello List!
I get "duplicate section ... has different size" messages when I
build a Wt application that contains (as far as I can tell) a call
internalPathChanged().connect (...);
...
C:\...\wt_test>g++ --version
g++ (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 4.9.2
When I build (link) my test program, I get the following par of
C:\...\wt_test>g++ -std=gnu++14 -o section section.cpp -lwt
-lwthttp -lboost_date_time-mgw49-1_57 -lboost_filesystem-mgw49-1_57
-lboost_program_options-mgw49-1_57 -lboost_random-mgw49-1_57
-lboost_regex-mgw49-1_57 -lboost_system-mgw49-1_57
-lboost_thread-mgw49-mt-s-1_57 -lws2_32 -lwsock32
duplicate section
...
------------------------------------------------------------------------------
Post by K. Frank
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
witty-interest mailing list
https://lists.sourceforge.net/lists/listinfo/witty-interest
Hi Koen and Wt team,
do you use a Continuous Integration system? If the answer is no, then
please add Travis CI [1]. It is free for open source. It would rebuild
Wt and run tests after each "push" to Github repo according to
".travis.yml" file from the repo. It would report errors. It is also
possible to build multiple targets (different compilers or options).
Appveyor CI is nice service too - it is similar to Travis CI, but uses
Windows instead of Linux. You can count on me to help you.
[1] https://travis-ci.org
--
Best regards,
Boris Nagaev
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
witty-interest mailing list
https://lists.sourceforge.net/lists/listinfo/witty-interest
Loading...