You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by "Ravi K Inampudi (JIRA)" <ji...@apache.org> on 2007/08/03 23:36:52 UTC
[jira] Created: (STDCXX-509) RW libstd is sensitive to link order
RW libstd is sensitive to link order
------------------------------------
Key: STDCXX-509
URL: https://issues.apache.org/jira/browse/STDCXX-509
Project: C++ Standard Library
Issue Type: Improvement
Components: Build
Affects Versions: 4.1.2
Environment: gcc3.2, linux AS3.0
Reporter: Ravi K Inampudi
Fix For: 4.1.2
A customer discovered a problem with std::numeric_limits<double> in RW libstd. Placing RW libstd on linkline *before* libFoo results in the program printing "0" instead of "inf". The problem doesn't happen with native gcc STL.
We reproduced the problem with the latest version of standard library downloaded from Apache. From our understanding, when creating the libFoo.so and using the native standard library is creating an implicit dependency on the libsupc++ (compiler dependent). This implicit dependency is initializing the static variable when libFoo.so is loaded. If we use RW libstd instread of libstdc++(native gcc stl), the program will print "0" instead of "inf".
# make shared lib
gcc -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include/ansi -pthread -D_RWSTD_USE_CONFIG -I/nfs/homes/dean/temp/stdlib-cxx/12d/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/examples/include -pedantic -nostdinc++ -O2 -Wall -W -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align -fPIC -shared -o libFooRW-link.so foo.C
# make binary.
gcc -pthread -o mainRW main.C -L/nfs/homes/dean/temp/stdlib-cxx/12d/lib -lstd12d -lsupc++ -lm -lFooRW
However, using the RW standard library, if such dependency is created explicitly then it prints "inf". For example, the following set of commands fixes the problem:
# make shared lib
gcc -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include/ansi -pthread -D_RWSTD_USE_CONFIG -I/nfs/homes/dean/temp/stdlib-cxx/12d/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/examples/include -pedantic -nostdinc++ -O2 -Wall -W -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align -fPIC -shared -o libFooRW-link.so foo.C -lstd12d
# make binary.
gcc -pthread -o mainRW main.C -L/nfs/homes/dean/temp/stdlib-cxx/12d/lib -lstd12d -lsupc++ -lm -lFooRW
But the customer never links their shared libs(i.e libFoo in this example) with RW libstd. They only link binaries with RW libstd! But it makes RW libstd sensitive to link order. And they think the problem is in limits.cpp file:
> <snip>
> static union {
> char _C_bits [sizeof (double)];
> double _C_inf;
> } __rw_dbl_inf_bits = { _RWSTD_DBL_INF_BITS };
>
> _RWSTD_EXPORT extern const double __rw_dbl_infinity =
> __rw_dbl_inf_bits._C_inf; </snip>
>
> __rw_dbl_infinity ends up in the uninitialized data section of
> libstd_gcc32.so
>
> nm -C libstd_gcc32.so| grep __rw_dbl_infinity
> 000937f8 B __rw::__rw_dbl_infinity
>
If the symbol was initialized in data section, the link order wouldn't matter.
Environment: RWSP6, gcc3.2, linux AS3.0
Martin Sebor's Comments:
Because the initializer of __rw_dbl_infinity is not a constant expresssion [expr.const] the symbol is initialized dynamically (at runtime) rather than statically (i.e., at load time). It seems that the compiler should be able to initialize it statically anyway, even if it's not required to. Regardless, we should avoid making the assumption that it will and change the initialization of the extern constants to use constant expressions instead.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-509)
std::numeric_limits::infinity() depends on dynamic initialization
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523429 ]
Martin Sebor commented on STDCXX-509:
-------------------------------------
Looks like the committed change is binary compatible (see the post below) and so it's not appropriate for 4.2. We need a different solution for this release.
http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg04613.html
> std::numeric_limits<double>::infinity() depends on dynamic initialization
> -------------------------------------------------------------------------
>
> Key: STDCXX-509
> URL: https://issues.apache.org/jira/browse/STDCXX-509
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 18. Language Support
> Affects Versions: 4.1.2, 4.1.3
> Environment: gcc3.2, linux AS3.0
> Reporter: Ravi K Inampudi
> Assignee: Martin Sebor
> Fix For: 4.2
>
> Attachments: limits_bits.cpp.patch
>
>
> A customer discovered a problem with std::numeric_limits<double> in RW libstd. Placing RW libstd on linkline *before* libFoo results in the program printing "0" instead of "inf". The problem doesn't happen with native gcc STL.
> We reproduced the problem with the latest version of standard library downloaded from Apache. From our understanding, when creating the libFoo.so and using the native standard library is creating an implicit dependency on the libsupc++ (compiler dependent). This implicit dependency is initializing the static variable when libFoo.so is loaded. If we use RW libstd instread of libstdc++(native gcc stl), the program will print "0" instead of "inf".
> # make shared lib
> gcc -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include/ansi -pthread -D_RWSTD_USE_CONFIG -I/nfs/homes/dean/temp/stdlib-cxx/12d/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/examples/include -pedantic -nostdinc++ -O2 -Wall -W -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align -fPIC -shared -o libFooRW-link.so foo.C
> # make binary.
> gcc -pthread -o mainRW main.C -L/nfs/homes/dean/temp/stdlib-cxx/12d/lib -lstd12d -lsupc++ -lm -lFooRW
> However, using the RW standard library, if such dependency is created explicitly then it prints "inf". For example, the following set of commands fixes the problem:
> # make shared lib
> gcc -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include/ansi -pthread -D_RWSTD_USE_CONFIG -I/nfs/homes/dean/temp/stdlib-cxx/12d/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/examples/include -pedantic -nostdinc++ -O2 -Wall -W -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align -fPIC -shared -o libFooRW-link.so foo.C -lstd12d
> # make binary.
> gcc -pthread -o mainRW main.C -L/nfs/homes/dean/temp/stdlib-cxx/12d/lib -lstd12d -lsupc++ -lm -lFooRW
> But the customer never links their shared libs(i.e libFoo in this example) with RW libstd. They only link binaries with RW libstd! But it makes RW libstd sensitive to link order. And they think the problem is in limits.cpp file:
> > <snip>
> > static union {
> > char _C_bits [sizeof (double)];
> > double _C_inf;
> > } __rw_dbl_inf_bits = { _RWSTD_DBL_INF_BITS };
> >
> > _RWSTD_EXPORT extern const double __rw_dbl_infinity =
> > __rw_dbl_inf_bits._C_inf; </snip>
> >
> > __rw_dbl_infinity ends up in the uninitialized data section of
> > libstd_gcc32.so
> >
> > nm -C libstd_gcc32.so| grep __rw_dbl_infinity
> > 000937f8 B __rw::__rw_dbl_infinity
> >
> If the symbol was initialized in data section, the link order wouldn't matter.
> Environment: RWSP6, gcc3.2, linux AS3.0
> Martin Sebor's Comments:
> Because the initializer of __rw_dbl_infinity is not a constant expresssion [expr.const] the symbol is initialized dynamically (at runtime) rather than statically (i.e., at load time). It seems that the compiler should be able to initialize it statically anyway, even if it's not required to. Regardless, we should avoid making the assumption that it will and change the initialization of the extern constants to use constant expressions instead.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-509) RW libstd is sensitive to link order
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Sebor reassigned STDCXX-509:
-----------------------------------
Assignee: Martin Sebor
> RW libstd is sensitive to link order
> ------------------------------------
>
> Key: STDCXX-509
> URL: https://issues.apache.org/jira/browse/STDCXX-509
> Project: C++ Standard Library
> Issue Type: Improvement
> Components: Build
> Affects Versions: 4.1.2
> Environment: gcc3.2, linux AS3.0
> Reporter: Ravi K Inampudi
> Assignee: Martin Sebor
> Fix For: 4.1.2
>
>
> A customer discovered a problem with std::numeric_limits<double> in RW libstd. Placing RW libstd on linkline *before* libFoo results in the program printing "0" instead of "inf". The problem doesn't happen with native gcc STL.
> We reproduced the problem with the latest version of standard library downloaded from Apache. From our understanding, when creating the libFoo.so and using the native standard library is creating an implicit dependency on the libsupc++ (compiler dependent). This implicit dependency is initializing the static variable when libFoo.so is loaded. If we use RW libstd instread of libstdc++(native gcc stl), the program will print "0" instead of "inf".
> # make shared lib
> gcc -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include/ansi -pthread -D_RWSTD_USE_CONFIG -I/nfs/homes/dean/temp/stdlib-cxx/12d/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/examples/include -pedantic -nostdinc++ -O2 -Wall -W -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align -fPIC -shared -o libFooRW-link.so foo.C
> # make binary.
> gcc -pthread -o mainRW main.C -L/nfs/homes/dean/temp/stdlib-cxx/12d/lib -lstd12d -lsupc++ -lm -lFooRW
> However, using the RW standard library, if such dependency is created explicitly then it prints "inf". For example, the following set of commands fixes the problem:
> # make shared lib
> gcc -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include/ansi -pthread -D_RWSTD_USE_CONFIG -I/nfs/homes/dean/temp/stdlib-cxx/12d/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/examples/include -pedantic -nostdinc++ -O2 -Wall -W -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align -fPIC -shared -o libFooRW-link.so foo.C -lstd12d
> # make binary.
> gcc -pthread -o mainRW main.C -L/nfs/homes/dean/temp/stdlib-cxx/12d/lib -lstd12d -lsupc++ -lm -lFooRW
> But the customer never links their shared libs(i.e libFoo in this example) with RW libstd. They only link binaries with RW libstd! But it makes RW libstd sensitive to link order. And they think the problem is in limits.cpp file:
> > <snip>
> > static union {
> > char _C_bits [sizeof (double)];
> > double _C_inf;
> > } __rw_dbl_inf_bits = { _RWSTD_DBL_INF_BITS };
> >
> > _RWSTD_EXPORT extern const double __rw_dbl_infinity =
> > __rw_dbl_inf_bits._C_inf; </snip>
> >
> > __rw_dbl_infinity ends up in the uninitialized data section of
> > libstd_gcc32.so
> >
> > nm -C libstd_gcc32.so| grep __rw_dbl_infinity
> > 000937f8 B __rw::__rw_dbl_infinity
> >
> If the symbol was initialized in data section, the link order wouldn't matter.
> Environment: RWSP6, gcc3.2, linux AS3.0
> Martin Sebor's Comments:
> Because the initializer of __rw_dbl_infinity is not a constant expresssion [expr.const] the symbol is initialized dynamically (at runtime) rather than statically (i.e., at load time). It seems that the compiler should be able to initialize it statically anyway, even if it's not required to. Regardless, we should avoid making the assumption that it will and change the initialization of the extern constants to use constant expressions instead.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-509) RW libstd is sensitive to link order
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518592 ]
Martin Sebor commented on STDCXX-509:
-------------------------------------
See the thread in the archive for reference:
http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg04080.html
Below are the relevant symbols in 4.1.3 (on Linux x86_64), with 'B' denoting BSS data (uninitialized data section).
$ nm -C ../lib/libstd15D.so | egrep "__rw_(flt|dbl|ldbl)_"
0000000000062214 t global constructors keyed to _ZN4__rw17__rw_dbl_infinityE
0000000000213ea0 B __rw::__rw_dbl_qNaN
0000000000213ec0 B __rw::__rw_dbl_sNaN
0000000000213ea8 B __rw::__rw_flt_qNaN
0000000000213ec8 B __rw::__rw_flt_sNaN
0000000000213eb0 B __rw::__rw_ldbl_qNaN
0000000000213ed0 B __rw::__rw_ldbl_sNaN
00000000000bae90 r __rw::__rw_dbl_inf_bits
0000000000213e80 B __rw::__rw_dbl_infinity
00000000000bae98 r __rw::__rw_flt_inf_bits
0000000000213e88 B __rw::__rw_flt_infinity
00000000000baeb0 r __rw::__rw_dbl_qNaN_bits
00000000000baed0 r __rw::__rw_dbl_sNaN_bits
00000000000baeb8 r __rw::__rw_flt_qNaN_bits
00000000000baed8 r __rw::__rw_flt_sNaN_bits
00000000000baea0 r __rw::__rw_ldbl_inf_bits
0000000000213e90 B __rw::__rw_ldbl_infinity
0000000000213ee0 B __rw::__rw_dbl_denorm_min
0000000000213ee8 B __rw::__rw_flt_denorm_min
00000000000baec0 r __rw::__rw_ldbl_qNaN_bits
00000000000baee0 r __rw::__rw_ldbl_sNaN_bits
0000000000213ef0 B __rw::__rw_ldbl_denorm_min
00000000000baef0 r __rw::__rw_dbl_denorm_min_bits
00000000000baef8 r __rw::__rw_flt_denorm_min_bits
00000000000baf00 r __rw::__rw_ldbl_denorm_min_bits
Here are the symbols on trunk after the committed change, with 'R' denoting statically initialized symbols in the read-only section:
$ nm -C ../lib/libstd15D.so | egrep "__rw_(flt|dbl|ldbl)_"
00000000000c2510 R __rw_dbl_denorm_min
00000000000c24b0 R __rw_dbl_infinity
00000000000c24d0 R __rw_dbl_qNaN
00000000000c24f0 R __rw_dbl_sNaN
00000000000c2518 R __rw_flt_denorm_min
00000000000c24b8 R __rw_flt_infinity
00000000000c24d8 R __rw_flt_qNaN
00000000000c24f8 R __rw_flt_sNaN
00000000000c2520 R __rw_ldbl_denorm_min
00000000000c24c0 R __rw_ldbl_infinity
00000000000c24e0 R __rw_ldbl_qNaN
00000000000c2500 R __rw_ldbl_sNaN
In addition to making the symbols statically initialized, the change also reduced the size of the limits_bits.o object file in which they are defined from 12K to 5K:
$ ls -l ../lib/limits_bits.o ../lib/libstd15D.so.4.1.3
-rwxr-xr-x 1 sebor devel 4870602 Aug 7 22:58 ../lib/libstd15D.so.4.1.3
-rw-r--r-- 1 sebor devel 12288 Aug 7 22:58 ../lib/limits_bits.o
$ ls -l ../lib/limits_bits.o ../lib/libstd15D.so.4.2.0
-rwxr-xr-x 1 sebor devel 5007014 Aug 9 00:49 ../lib/libstd15D.so.4.2.0
-rw-r--r-- 1 sebor devel 5224 Aug 9 00:49 ../lib/limits_bits.o
> RW libstd is sensitive to link order
> ------------------------------------
>
> Key: STDCXX-509
> URL: https://issues.apache.org/jira/browse/STDCXX-509
> Project: C++ Standard Library
> Issue Type: Improvement
> Components: Build
> Affects Versions: 4.1.2
> Environment: gcc3.2, linux AS3.0
> Reporter: Ravi K Inampudi
> Assignee: Martin Sebor
> Fix For: 4.1.2
>
> Attachments: limits_bits.cpp.patch
>
>
> A customer discovered a problem with std::numeric_limits<double> in RW libstd. Placing RW libstd on linkline *before* libFoo results in the program printing "0" instead of "inf". The problem doesn't happen with native gcc STL.
> We reproduced the problem with the latest version of standard library downloaded from Apache. From our understanding, when creating the libFoo.so and using the native standard library is creating an implicit dependency on the libsupc++ (compiler dependent). This implicit dependency is initializing the static variable when libFoo.so is loaded. If we use RW libstd instread of libstdc++(native gcc stl), the program will print "0" instead of "inf".
> # make shared lib
> gcc -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include/ansi -pthread -D_RWSTD_USE_CONFIG -I/nfs/homes/dean/temp/stdlib-cxx/12d/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/examples/include -pedantic -nostdinc++ -O2 -Wall -W -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align -fPIC -shared -o libFooRW-link.so foo.C
> # make binary.
> gcc -pthread -o mainRW main.C -L/nfs/homes/dean/temp/stdlib-cxx/12d/lib -lstd12d -lsupc++ -lm -lFooRW
> However, using the RW standard library, if such dependency is created explicitly then it prints "inf". For example, the following set of commands fixes the problem:
> # make shared lib
> gcc -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include/ansi -pthread -D_RWSTD_USE_CONFIG -I/nfs/homes/dean/temp/stdlib-cxx/12d/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/examples/include -pedantic -nostdinc++ -O2 -Wall -W -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align -fPIC -shared -o libFooRW-link.so foo.C -lstd12d
> # make binary.
> gcc -pthread -o mainRW main.C -L/nfs/homes/dean/temp/stdlib-cxx/12d/lib -lstd12d -lsupc++ -lm -lFooRW
> But the customer never links their shared libs(i.e libFoo in this example) with RW libstd. They only link binaries with RW libstd! But it makes RW libstd sensitive to link order. And they think the problem is in limits.cpp file:
> > <snip>
> > static union {
> > char _C_bits [sizeof (double)];
> > double _C_inf;
> > } __rw_dbl_inf_bits = { _RWSTD_DBL_INF_BITS };
> >
> > _RWSTD_EXPORT extern const double __rw_dbl_infinity =
> > __rw_dbl_inf_bits._C_inf; </snip>
> >
> > __rw_dbl_infinity ends up in the uninitialized data section of
> > libstd_gcc32.so
> >
> > nm -C libstd_gcc32.so| grep __rw_dbl_infinity
> > 000937f8 B __rw::__rw_dbl_infinity
> >
> If the symbol was initialized in data section, the link order wouldn't matter.
> Environment: RWSP6, gcc3.2, linux AS3.0
> Martin Sebor's Comments:
> Because the initializer of __rw_dbl_infinity is not a constant expresssion [expr.const] the symbol is initialized dynamically (at runtime) rather than statically (i.e., at load time). It seems that the compiler should be able to initialize it statically anyway, even if it's not required to. Regardless, we should avoid making the assumption that it will and change the initialization of the extern constants to use constant expressions instead.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (STDCXX-509)
std::numeric_limits::infinity() depends on dynamic initialization
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523429 ]
sebor edited comment on STDCXX-509 at 10/15/07 9:45 AM:
---------------------------------------------------------------
Looks like the committed change is binary incompatible (see the post below) and so it's not appropriate for 4.2. We need a different solution for this release.
http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg04613.html
was (Author: sebor):
Looks like the committed change is binary compatible (see the post below) and so it's not appropriate for 4.2. We need a different solution for this release.
http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg04613.html
> std::numeric_limits<double>::infinity() depends on dynamic initialization
> -------------------------------------------------------------------------
>
> Key: STDCXX-509
> URL: https://issues.apache.org/jira/browse/STDCXX-509
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 18. Language Support
> Affects Versions: 4.1.2, 4.1.3
> Environment: gcc3.2, linux AS3.0
> Reporter: Ravi K Inampudi
> Assignee: Martin Sebor
> Fix For: 4.2
>
> Attachments: limits_bits.cpp.patch
>
>
> A customer discovered a problem with std::numeric_limits<double> in RW libstd. Placing RW libstd on linkline *before* libFoo results in the program printing "0" instead of "inf". The problem doesn't happen with native gcc STL.
> We reproduced the problem with the latest version of standard library downloaded from Apache. From our understanding, when creating the libFoo.so and using the native standard library is creating an implicit dependency on the libsupc++ (compiler dependent). This implicit dependency is initializing the static variable when libFoo.so is loaded. If we use RW libstd instread of libstdc++(native gcc stl), the program will print "0" instead of "inf".
> # make shared lib
> gcc -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include/ansi -pthread -D_RWSTD_USE_CONFIG -I/nfs/homes/dean/temp/stdlib-cxx/12d/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/examples/include -pedantic -nostdinc++ -O2 -Wall -W -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align -fPIC -shared -o libFooRW-link.so foo.C
> # make binary.
> gcc -pthread -o mainRW main.C -L/nfs/homes/dean/temp/stdlib-cxx/12d/lib -lstd12d -lsupc++ -lm -lFooRW
> However, using the RW standard library, if such dependency is created explicitly then it prints "inf". For example, the following set of commands fixes the problem:
> # make shared lib
> gcc -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include/ansi -pthread -D_RWSTD_USE_CONFIG -I/nfs/homes/dean/temp/stdlib-cxx/12d/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/examples/include -pedantic -nostdinc++ -O2 -Wall -W -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align -fPIC -shared -o libFooRW-link.so foo.C -lstd12d
> # make binary.
> gcc -pthread -o mainRW main.C -L/nfs/homes/dean/temp/stdlib-cxx/12d/lib -lstd12d -lsupc++ -lm -lFooRW
> But the customer never links their shared libs(i.e libFoo in this example) with RW libstd. They only link binaries with RW libstd! But it makes RW libstd sensitive to link order. And they think the problem is in limits.cpp file:
> > <snip>
> > static union {
> > char _C_bits [sizeof (double)];
> > double _C_inf;
> > } __rw_dbl_inf_bits = { _RWSTD_DBL_INF_BITS };
> >
> > _RWSTD_EXPORT extern const double __rw_dbl_infinity =
> > __rw_dbl_inf_bits._C_inf; </snip>
> >
> > __rw_dbl_infinity ends up in the uninitialized data section of
> > libstd_gcc32.so
> >
> > nm -C libstd_gcc32.so| grep __rw_dbl_infinity
> > 000937f8 B __rw::__rw_dbl_infinity
> >
> If the symbol was initialized in data section, the link order wouldn't matter.
> Environment: RWSP6, gcc3.2, linux AS3.0
> Martin Sebor's Comments:
> Because the initializer of __rw_dbl_infinity is not a constant expresssion [expr.const] the symbol is initialized dynamically (at runtime) rather than statically (i.e., at load time). It seems that the compiler should be able to initialize it statically anyway, even if it's not required to. Regardless, we should avoid making the assumption that it will and change the initialization of the extern constants to use constant expressions instead.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-509)
std::numeric_limits::infinity() depends on dynamic initialization
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Sebor updated STDCXX-509:
--------------------------------
Component/s: (was: Build)
18. Language Support
Affects Version/s: 4.1.3
Fix Version/s: (was: 4.1.2)
4.2
Issue Type: Bug (was: Improvement)
Summary: std::numeric_limits<double>::infinity() depends on dynamic initialization (was: RW libstd is sensitive to link order)
Changing Issue Type to Bug. It's is more than an Improvement: the library should not rely on dynamic initialization where it may be detectable in user code.
Changing component to Language Support (it affects std::numeric_limits), adding 4.1.3 to Affected Versions, and scheduling the fix for 4.2.
> std::numeric_limits<double>::infinity() depends on dynamic initialization
> -------------------------------------------------------------------------
>
> Key: STDCXX-509
> URL: https://issues.apache.org/jira/browse/STDCXX-509
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 18. Language Support
> Affects Versions: 4.1.3, 4.1.2
> Environment: gcc3.2, linux AS3.0
> Reporter: Ravi K Inampudi
> Assignee: Martin Sebor
> Fix For: 4.2
>
> Attachments: limits_bits.cpp.patch
>
>
> A customer discovered a problem with std::numeric_limits<double> in RW libstd. Placing RW libstd on linkline *before* libFoo results in the program printing "0" instead of "inf". The problem doesn't happen with native gcc STL.
> We reproduced the problem with the latest version of standard library downloaded from Apache. From our understanding, when creating the libFoo.so and using the native standard library is creating an implicit dependency on the libsupc++ (compiler dependent). This implicit dependency is initializing the static variable when libFoo.so is loaded. If we use RW libstd instread of libstdc++(native gcc stl), the program will print "0" instead of "inf".
> # make shared lib
> gcc -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include/ansi -pthread -D_RWSTD_USE_CONFIG -I/nfs/homes/dean/temp/stdlib-cxx/12d/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/examples/include -pedantic -nostdinc++ -O2 -Wall -W -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align -fPIC -shared -o libFooRW-link.so foo.C
> # make binary.
> gcc -pthread -o mainRW main.C -L/nfs/homes/dean/temp/stdlib-cxx/12d/lib -lstd12d -lsupc++ -lm -lFooRW
> However, using the RW standard library, if such dependency is created explicitly then it prints "inf". For example, the following set of commands fixes the problem:
> # make shared lib
> gcc -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include/ansi -pthread -D_RWSTD_USE_CONFIG -I/nfs/homes/dean/temp/stdlib-cxx/12d/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/examples/include -pedantic -nostdinc++ -O2 -Wall -W -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align -fPIC -shared -o libFooRW-link.so foo.C -lstd12d
> # make binary.
> gcc -pthread -o mainRW main.C -L/nfs/homes/dean/temp/stdlib-cxx/12d/lib -lstd12d -lsupc++ -lm -lFooRW
> But the customer never links their shared libs(i.e libFoo in this example) with RW libstd. They only link binaries with RW libstd! But it makes RW libstd sensitive to link order. And they think the problem is in limits.cpp file:
> > <snip>
> > static union {
> > char _C_bits [sizeof (double)];
> > double _C_inf;
> > } __rw_dbl_inf_bits = { _RWSTD_DBL_INF_BITS };
> >
> > _RWSTD_EXPORT extern const double __rw_dbl_infinity =
> > __rw_dbl_inf_bits._C_inf; </snip>
> >
> > __rw_dbl_infinity ends up in the uninitialized data section of
> > libstd_gcc32.so
> >
> > nm -C libstd_gcc32.so| grep __rw_dbl_infinity
> > 000937f8 B __rw::__rw_dbl_infinity
> >
> If the symbol was initialized in data section, the link order wouldn't matter.
> Environment: RWSP6, gcc3.2, linux AS3.0
> Martin Sebor's Comments:
> Because the initializer of __rw_dbl_infinity is not a constant expresssion [expr.const] the symbol is initialized dynamically (at runtime) rather than statically (i.e., at load time). It seems that the compiler should be able to initialize it statically anyway, even if it's not required to. Regardless, we should avoid making the assumption that it will and change the initialization of the extern constants to use constant expressions instead.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-509) RW libstd is sensitive to link order
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Sebor updated STDCXX-509:
--------------------------------
Attachment: limits_bits.cpp.patch
Attached is a patch I'm testing.
> RW libstd is sensitive to link order
> ------------------------------------
>
> Key: STDCXX-509
> URL: https://issues.apache.org/jira/browse/STDCXX-509
> Project: C++ Standard Library
> Issue Type: Improvement
> Components: Build
> Affects Versions: 4.1.2
> Environment: gcc3.2, linux AS3.0
> Reporter: Ravi K Inampudi
> Assignee: Martin Sebor
> Fix For: 4.1.2
>
> Attachments: limits_bits.cpp.patch
>
>
> A customer discovered a problem with std::numeric_limits<double> in RW libstd. Placing RW libstd on linkline *before* libFoo results in the program printing "0" instead of "inf". The problem doesn't happen with native gcc STL.
> We reproduced the problem with the latest version of standard library downloaded from Apache. From our understanding, when creating the libFoo.so and using the native standard library is creating an implicit dependency on the libsupc++ (compiler dependent). This implicit dependency is initializing the static variable when libFoo.so is loaded. If we use RW libstd instread of libstdc++(native gcc stl), the program will print "0" instead of "inf".
> # make shared lib
> gcc -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include/ansi -pthread -D_RWSTD_USE_CONFIG -I/nfs/homes/dean/temp/stdlib-cxx/12d/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/examples/include -pedantic -nostdinc++ -O2 -Wall -W -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align -fPIC -shared -o libFooRW-link.so foo.C
> # make binary.
> gcc -pthread -o mainRW main.C -L/nfs/homes/dean/temp/stdlib-cxx/12d/lib -lstd12d -lsupc++ -lm -lFooRW
> However, using the RW standard library, if such dependency is created explicitly then it prints "inf". For example, the following set of commands fixes the problem:
> # make shared lib
> gcc -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include/ansi -pthread -D_RWSTD_USE_CONFIG -I/nfs/homes/dean/temp/stdlib-cxx/12d/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/examples/include -pedantic -nostdinc++ -O2 -Wall -W -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align -fPIC -shared -o libFooRW-link.so foo.C -lstd12d
> # make binary.
> gcc -pthread -o mainRW main.C -L/nfs/homes/dean/temp/stdlib-cxx/12d/lib -lstd12d -lsupc++ -lm -lFooRW
> But the customer never links their shared libs(i.e libFoo in this example) with RW libstd. They only link binaries with RW libstd! But it makes RW libstd sensitive to link order. And they think the problem is in limits.cpp file:
> > <snip>
> > static union {
> > char _C_bits [sizeof (double)];
> > double _C_inf;
> > } __rw_dbl_inf_bits = { _RWSTD_DBL_INF_BITS };
> >
> > _RWSTD_EXPORT extern const double __rw_dbl_infinity =
> > __rw_dbl_inf_bits._C_inf; </snip>
> >
> > __rw_dbl_infinity ends up in the uninitialized data section of
> > libstd_gcc32.so
> >
> > nm -C libstd_gcc32.so| grep __rw_dbl_infinity
> > 000937f8 B __rw::__rw_dbl_infinity
> >
> If the symbol was initialized in data section, the link order wouldn't matter.
> Environment: RWSP6, gcc3.2, linux AS3.0
> Martin Sebor's Comments:
> Because the initializer of __rw_dbl_infinity is not a constant expresssion [expr.const] the symbol is initialized dynamically (at runtime) rather than statically (i.e., at load time). It seems that the compiler should be able to initialize it statically anyway, even if it's not required to. Regardless, we should avoid making the assumption that it will and change the initialization of the extern constants to use constant expressions instead.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-509) std::numeric_limits::infinity()
depends on dynamic initialization
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Sebor closed STDCXX-509.
-------------------------------
Resolution: Fixed
We can finally close this. Whew!
See this thread for background into the final solution:
http://www.nabble.com/binary-compatibility-question-tf4649664.html
Some additional history is here:
http://www.nabble.com/Re%3A-STDCXX-509-tf4638226.html#a13247047
> std::numeric_limits<double>::infinity() depends on dynamic initialization
> -------------------------------------------------------------------------
>
> Key: STDCXX-509
> URL: https://issues.apache.org/jira/browse/STDCXX-509
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 18. Language Support
> Affects Versions: 4.1.2, 4.1.3
> Environment: gcc3.2, linux AS3.0
> Reporter: Ravi K Inampudi
> Assignee: Martin Sebor
> Fix For: 4.2
>
> Attachments: limits_bits.cpp.patch
>
>
> A customer discovered a problem with std::numeric_limits<double> in RW libstd. Placing RW libstd on linkline *before* libFoo results in the program printing "0" instead of "inf". The problem doesn't happen with native gcc STL.
> We reproduced the problem with the latest version of standard library downloaded from Apache. From our understanding, when creating the libFoo.so and using the native standard library is creating an implicit dependency on the libsupc++ (compiler dependent). This implicit dependency is initializing the static variable when libFoo.so is loaded. If we use RW libstd instread of libstdc++(native gcc stl), the program will print "0" instead of "inf".
> # make shared lib
> gcc -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include/ansi -pthread -D_RWSTD_USE_CONFIG -I/nfs/homes/dean/temp/stdlib-cxx/12d/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/examples/include -pedantic -nostdinc++ -O2 -Wall -W -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align -fPIC -shared -o libFooRW-link.so foo.C
> # make binary.
> gcc -pthread -o mainRW main.C -L/nfs/homes/dean/temp/stdlib-cxx/12d/lib -lstd12d -lsupc++ -lm -lFooRW
> However, using the RW standard library, if such dependency is created explicitly then it prints "inf". For example, the following set of commands fixes the problem:
> # make shared lib
> gcc -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include/ansi -pthread -D_RWSTD_USE_CONFIG -I/nfs/homes/dean/temp/stdlib-cxx/12d/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/examples/include -pedantic -nostdinc++ -O2 -Wall -W -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align -fPIC -shared -o libFooRW-link.so foo.C -lstd12d
> # make binary.
> gcc -pthread -o mainRW main.C -L/nfs/homes/dean/temp/stdlib-cxx/12d/lib -lstd12d -lsupc++ -lm -lFooRW
> But the customer never links their shared libs(i.e libFoo in this example) with RW libstd. They only link binaries with RW libstd! But it makes RW libstd sensitive to link order. And they think the problem is in limits.cpp file:
> > <snip>
> > static union {
> > char _C_bits [sizeof (double)];
> > double _C_inf;
> > } __rw_dbl_inf_bits = { _RWSTD_DBL_INF_BITS };
> >
> > _RWSTD_EXPORT extern const double __rw_dbl_infinity =
> > __rw_dbl_inf_bits._C_inf; </snip>
> >
> > __rw_dbl_infinity ends up in the uninitialized data section of
> > libstd_gcc32.so
> >
> > nm -C libstd_gcc32.so| grep __rw_dbl_infinity
> > 000937f8 B __rw::__rw_dbl_infinity
> >
> If the symbol was initialized in data section, the link order wouldn't matter.
> Environment: RWSP6, gcc3.2, linux AS3.0
> Martin Sebor's Comments:
> Because the initializer of __rw_dbl_infinity is not a constant expresssion [expr.const] the symbol is initialized dynamically (at runtime) rather than statically (i.e., at load time). It seems that the compiler should be able to initialize it statically anyway, even if it's not required to. Regardless, we should avoid making the assumption that it will and change the initialization of the extern constants to use constant expressions instead.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-509)
std::numeric_limits::infinity() depends on dynamic initialization
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535048 ]
Martin Sebor commented on STDCXX-509:
-------------------------------------
The change committed at rev 584981 (http://svn.apache.org/viewcvs?view=rev&rev=584981) along with rev 584956 (http://svn.apache.org/viewvc?view=rev&revision=584956) implement a binary compatible fix for all supported platforms except Visual Studio (and most likely Intel C++ on Windows). Still need to come up with a fix for that one.
> std::numeric_limits<double>::infinity() depends on dynamic initialization
> -------------------------------------------------------------------------
>
> Key: STDCXX-509
> URL: https://issues.apache.org/jira/browse/STDCXX-509
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 18. Language Support
> Affects Versions: 4.1.2, 4.1.3
> Environment: gcc3.2, linux AS3.0
> Reporter: Ravi K Inampudi
> Assignee: Martin Sebor
> Fix For: 4.2
>
> Attachments: limits_bits.cpp.patch
>
>
> A customer discovered a problem with std::numeric_limits<double> in RW libstd. Placing RW libstd on linkline *before* libFoo results in the program printing "0" instead of "inf". The problem doesn't happen with native gcc STL.
> We reproduced the problem with the latest version of standard library downloaded from Apache. From our understanding, when creating the libFoo.so and using the native standard library is creating an implicit dependency on the libsupc++ (compiler dependent). This implicit dependency is initializing the static variable when libFoo.so is loaded. If we use RW libstd instread of libstdc++(native gcc stl), the program will print "0" instead of "inf".
> # make shared lib
> gcc -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include/ansi -pthread -D_RWSTD_USE_CONFIG -I/nfs/homes/dean/temp/stdlib-cxx/12d/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/examples/include -pedantic -nostdinc++ -O2 -Wall -W -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align -fPIC -shared -o libFooRW-link.so foo.C
> # make binary.
> gcc -pthread -o mainRW main.C -L/nfs/homes/dean/temp/stdlib-cxx/12d/lib -lstd12d -lsupc++ -lm -lFooRW
> However, using the RW standard library, if such dependency is created explicitly then it prints "inf". For example, the following set of commands fixes the problem:
> # make shared lib
> gcc -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include/ansi -pthread -D_RWSTD_USE_CONFIG -I/nfs/homes/dean/temp/stdlib-cxx/12d/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/include -I/amd/homes/dean/temp/stdlib-cxx/stdcxx-4.1.3/examples/include -pedantic -nostdinc++ -O2 -Wall -W -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align -fPIC -shared -o libFooRW-link.so foo.C -lstd12d
> # make binary.
> gcc -pthread -o mainRW main.C -L/nfs/homes/dean/temp/stdlib-cxx/12d/lib -lstd12d -lsupc++ -lm -lFooRW
> But the customer never links their shared libs(i.e libFoo in this example) with RW libstd. They only link binaries with RW libstd! But it makes RW libstd sensitive to link order. And they think the problem is in limits.cpp file:
> > <snip>
> > static union {
> > char _C_bits [sizeof (double)];
> > double _C_inf;
> > } __rw_dbl_inf_bits = { _RWSTD_DBL_INF_BITS };
> >
> > _RWSTD_EXPORT extern const double __rw_dbl_infinity =
> > __rw_dbl_inf_bits._C_inf; </snip>
> >
> > __rw_dbl_infinity ends up in the uninitialized data section of
> > libstd_gcc32.so
> >
> > nm -C libstd_gcc32.so| grep __rw_dbl_infinity
> > 000937f8 B __rw::__rw_dbl_infinity
> >
> If the symbol was initialized in data section, the link order wouldn't matter.
> Environment: RWSP6, gcc3.2, linux AS3.0
> Martin Sebor's Comments:
> Because the initializer of __rw_dbl_infinity is not a constant expresssion [expr.const] the symbol is initialized dynamically (at runtime) rather than statically (i.e., at load time). It seems that the compiler should be able to initialize it statically anyway, even if it's not required to. Regardless, we should avoid making the assumption that it will and change the initialization of the extern constants to use constant expressions instead.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.