[ 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.