FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 01-09-2008, 11:07 AM
Adam C Powell IV
 
Default C++/STL linking trouble

Greetings,

I'm having trouble with a new C++ package called Salomé which I can't
get to link to a C++ library in a new package OpenCASCADE.

Here's the error:

g++ -m64 -D_OCC64 -g -D_DEBUG_ -Wno-deprecated -Wparentheses -Wreturn-type -Wunused -o .libs/testDS testDS-testDS.o -pthread ./.libs/libSalomeDSImpl.so /home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/HDFPersist/.libs/libSalomeHDFPersist.so -L/usr/lib -L/usr/lib/openmpi/lib -L/usr/X11R6/lib64 ../HDFPersist/.libs/libSalomeHDFPersist.so /usr/lib/libTKStdSchema.so /usr/lib/libTKPCAF.so /usr/lib/libTKCAF.so /usr/lib/libTKV3d.so /usr/lib/libTKMesh.so /usr/lib/libTKV2d.so /usr/lib/libTKService.so -lXt -lX11 /usr/lib/libTKHLR.so /usr/lib/libTKStdLSchema.so /usr/lib/libTKPLCAF.so /usr/lib/libTKLCAF.so /usr/lib/libTKTopAlgo.so /usr/lib/libTKGeomAlgo.so /usr/lib/libTKShapeSchema.so /usr/lib/libTKPShape.so /usr/lib/libTKBRep.so /usr/lib/libTKGeomBase.so /usr/lib/libTKG3d.so /usr/lib/libPTKernel.so /usr/lib/libTKG2d.so /usr/lib/libTKMath.so /usr/lib/libTKCDF.so /usr/lib/libTKernel.so -lstlport -lieee /usr/lib/libhdf5.so -lpthread -lz -lXmu -lnsl -lm -lrt -ldl -Wl,--rpath -Wl,/usr/lib64/salome -Wl,--rpath -Wl,/usr/lib
testDS-testDS.o: In function `main':
/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/SALOMEDSImpl/testDS.cxx:64: undefined reference to `operator<<(std::basic_ostream<char, std::char_traits<char> >&, TCollection_AsciiString const&)'
/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/SALOMEDSImpl/testDS.cxx:66: undefined reference to `operator<<(std::basic_ostream<char, std::char_traits<char> >&, TCollection_AsciiString const&)'
/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/SALOMEDSImpl/testDS.cxx:69: undefined reference to `operator<<(std::basic_ostream<char, std::char_traits<char> >&, TCollection_AsciiString const&)'
/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/SALOMEDSImpl/testDS.cxx:71: undefined reference to `operator<<(std::basic_ostream<char, std::char_traits<char> >&, TCollection_ExtendedString const&)'
/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/SALOMEDSImpl/testDS.cxx:73: undefined reference to `operator<<(std::basic_ostream<char, std::char_traits<char> >&, TCollection_AsciiString const&)'
/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/SALOMEDSImpl/testDS.cxx:73: undefined reference to `operator<<(std::basic_ostream<char, std::char_traits<char> >&, TCollection_AsciiString const&)'
/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/SALOMEDSImpl/testDS.cxx:78: undefined reference to `operator<<(std::basic_ostream<char, std::char_traits<char> >&, TCollection_AsciiString const&)'
/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/SALOMEDSImpl/testDS.cxx:80: undefined reference to `operator<<(std::basic_ostream<char, std::char_traits<char> >&, TCollection_AsciiString const&)'
/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/SALOMEDSImpl/testDS.cxx:80: undefined reference to `operator<<(std::basic_ostream<char, std::char_traits<char> >&, TCollection_AsciiString const&)'
testDS-testDS.o:/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/SALOMEDSImpl/testDS.cxx:81: more undefined references to `operator<<(std::basic_ostream<char, std::char_traits<char> >&, TCollection_AsciiString const&)' follow
./.libs/libSalomeDSImpl.so: undefined reference to `TDF_Attribute::ExtendedDump(std::basic_ostream<ch ar, std::char_traits<char> >&, TDF_IDFilter const&, TDF_AttributeIndexedMap&) const'
./.libs/libSalomeDSImpl.so: undefined reference to `Standard_Transient::ShallowDump(std::basic_ostrea m<char, std::char_traits<char> >&) const'
./.libs/libSalomeDSImpl.so: undefined reference to `operator<<(std::basic_ostream<char, std::char_traits<char> >&, Handle_Standard_Type const&)'
./.libs/libSalomeDSImpl.so: undefined reference to `TDF_Attribute:ump(std::basic_ostream<char, std::char_traits<char> >&) const'
collect2: ld returned 1 exit status
make[2]: *** [testDS] Error 1
make[2]: Leaving directory `/home/hazelsct/salome-3.2.6/KERNEL_SRC_3.2.6/src/SALOMEDSImpl'

The libraries libTKPCAF, libTCAF, libTKernel etc. are part of the
OpenCASCADE package, which I haven't uploaded yet, but you can get from
http://lyre.mit.edu/~powell/opencascade/ (signed with my key in the
Debian keyring). -4 is missing a build-dep on libmesa-gl1-dev, -5 will
be up soon. The package I'm trying to build is Salomé, for which I've
put very preliminary -1 sources in http://lyre.mit.edu/~powell/salome/ .

To make matters worse, the Salomé build doesn't get this far in unstable
because of an incompatibility between omniorb4 4.0.6 and 4.1.1, so to
see the above error you need to build it against omniorb4 4.0.6 which is
in testing. I've emailed the omniorb4 maintainers to ask for help with
making that part work. Oh -- and building Salomé at all requires
patches to HDF5 and OpenMPI which I put in bugs 457080 and 459642 and
which the maintainers have agreed to merge. The necessary HDF5 packages
are in the http://lyre.mit.edu/~powell/hdf5/ , and for OpenMPI, do
"ln -s libmpi_cxx.so /usr/lib/libmpi++.so" and Salomé will configure and
build properly.

Using nm -C I found that the library libTKernel has:
0000000000004c74 T operator<<(_STL::basic_ostream<char, _STL::char_traits<char> >&, TCollection_AsciiString const&)
and the other missing symbols are in that and other OpenCASCADE libs
with s/std/_STL/ .

>From Googling around, I've learned that this seems to be a confusion
between the stlport namespace and standard C++ library namespace for the
argument symbols. So how do I either get Salomé to build in the stlport
namespace, or get OpenCASCADE to not build there?

Thanks for any help you can provide. Please CC me in replies.

-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/
 
Old 01-09-2008, 01:37 PM
Thomas Girard
 
Default C++/STL linking trouble

On Wed, Jan 09, 2008 at 07:07:30AM -0500, Adam C Powell IV wrote:
> Greetings,

Hello Adam,

> I'm having trouble with a new C++ package called Salomé which I can't
> get to link to a C++ library in a new package OpenCASCADE.
>
> Here's the error:

[...]

> Using nm -C I found that the library libTKernel has:
> 0000000000004c74 T operator<<(_STL::basic_ostream<char, _STL::char_traits<char> >&, TCollection_AsciiString const&)
> and the other missing symbols are in that and other OpenCASCADE libs
> with s/std/_STL/ .
>
> >From Googling around, I've learned that this seems to be a confusion
> between the stlport namespace and standard C++ library namespace for the
> argument symbols. So how do I either get Salomé to build in the stlport
> namespace, or get OpenCASCADE to not build there?

It seems the libTKernel has changed how STLport std:: namespace (through
_STDP_STD_NAME macro) gets expanded. If you have a look at libstlport5.1
symbols you should see there are defined in the stlp_std:: namespace.
Removing this #define _STDP_STD_NAME _STL from headers used by libTKernel
should fix the link failure.

I'll answer the omniORB change on the pkg-corba mailing list.

Thomas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-09-2008, 02:08 PM
Adam C Powell IV
 
Default C++/STL linking trouble

On Wed, 2008-01-09 at 15:37 +0100, Thomas Girard wrote:
> On Wed, Jan 09, 2008 at 07:07:30AM -0500, Adam C Powell IV wrote:
> > Greetings,
>
> Hello Adam,
>
> > I'm having trouble with a new C++ package called Salomé which I can't
> > get to link to a C++ library in a new package OpenCASCADE.
> >
> > Here's the error:
>
> [...]
>
> > Using nm -C I found that the library libTKernel has:
> > 0000000000004c74 T operator<<(_STL::basic_ostream<char, _STL::char_traits<char> >&, TCollection_AsciiString const&)
> > and the other missing symbols are in that and other OpenCASCADE libs
> > with s/std/_STL/ .
> >
> > >From Googling around, I've learned that this seems to be a confusion
> > between the stlport namespace and standard C++ library namespace for the
> > argument symbols. So how do I either get Salomé to build in the stlport
> > namespace, or get OpenCASCADE to not build there?
>
> It seems the libTKernel has changed how STLport std:: namespace (through
> _STDP_STD_NAME macro) gets expanded. If you have a look at libstlport5.1
> symbols you should see there are defined in the stlp_std:: namespace.
> Removing this #define _STDP_STD_NAME _STL from headers used by libTKernel
> should fix the link failure.

Thank you for pointing this out. OpenCASCADE doesn't work with stlport
5.1, just 4.6.

I don't see _STDP_STD_NAME in any of the OpenCASCADE headers... Should
I perhaps #define _STDP_STD_NAME std, or #undef it?

> I'll answer the omniORB change on the pkg-corba mailing list.

Alexandre Fayolle pointed out that Salomé only supports omniORB 4.0.x,
not 4.1.1. So to get this to build in unstable, I'll need to port it to
4.1.1. :-(

I'll stick to building in testing for now, and port when I get time.

Thanks again,
-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-09-2008, 09:30 PM
Adam C Powell IV
 
Default C++/STL linking trouble

On Wed, 2008-01-09 at 10:09 -0500, Adam C Powell IV wrote:
> On Wed, 2008-01-09 at 15:37 +0100, Thomas Girard wrote:
> > On Wed, Jan 09, 2008 at 07:07:30AM -0500, Adam C Powell IV wrote:
> > > I'm having trouble with a new C++ package called Salomé which I can't
> > > get to link to a C++ library in a new package OpenCASCADE.
> > >
> > > Using nm -C I found that the library libTKernel has:
> > > 0000000000004c74 T operator<<(_STL::basic_ostream<char, _STL::char_traits<char> >&, TCollection_AsciiString const&)
> > > and the other missing symbols are in that and other OpenCASCADE libs
> > > with s/std/_STL/ .
> > >
> > > >From Googling around, I've learned that this seems to be a confusion
> > > between the stlport namespace and standard C++ library namespace for the
> > > argument symbols. So how do I either get Salomé to build in the stlport
> > > namespace, or get OpenCASCADE to not build there?
> >
> > It seems the libTKernel has changed how STLport std:: namespace (through
> > _STDP_STD_NAME macro) gets expanded. If you have a look at libstlport5.1
> > symbols you should see there are defined in the stlp_std:: namespace.
> > Removing this #define _STDP_STD_NAME _STL from headers used by libTKernel
> > should fix the link failure.
>
> Thank you for pointing this out. OpenCASCADE doesn't work with stlport
> 5.1, just 4.6.
>
> I don't see _STDP_STD_NAME in any of the OpenCASCADE headers... Should
> I perhaps #define _STDP_STD_NAME std, or #undef it?

I think I found the problem. I pre-processed two files in question,
TDF_Attribute.cxx in OpenCASCADE and testDS.cxx in Salomé. I put both
outputs in http://lyre.mit.edu/~powell/salome/

In the former, /usr/include/stlport/stl/_iosfwd.h opens a "namespace
_STL {" then #includes /usr/include/stlport/stl/_iosfwd.h which has:
typedef basic_ostream<char, char_traits<char> > ostream; (line 2685)

In the latter, /usr/include/c++/4.2/iosfwd opens a
"namespace std __attribute__ ((__visibility__ ("default"))) {" then
#includes /usr/include/c++/4.2/iosfwd which has:
typedef basic_ostream<char> ostream; (line 6311)

So they lead to different symbols, which breaks linking. What to do?

I see "using namespace std" in testDS.E (lines 31862 and 37777) and
"using namespace _STL" in TDF_Attribute.E (lines 17427 and 23430).
Would changing this in the OpenCASCADE headers override the "namespace
_STL {" and fix the problem?

Otherwise, how does a non-stlport binary link to an stlport library??

Thanks for any help and insights you can provide.

-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-13-2008, 12:13 PM
Ben Hutchings
 
Default C++/STL linking trouble

On Wed, 2008-01-09 at 17:30 -0500, Adam C Powell IV wrote:
<snip>
> I think I found the problem. I pre-processed two files in question,
> TDF_Attribute.cxx in OpenCASCADE and testDS.cxx in Salomé. I put both
> outputs in http://lyre.mit.edu/~powell/salome/
>
> In the former, /usr/include/stlport/stl/_iosfwd.h opens a "namespace
> _STL {" then #includes /usr/include/stlport/stl/_iosfwd.h which has:
> typedef basic_ostream<char, char_traits<char> > ostream; (line 2685)
>
> In the latter, /usr/include/c++/4.2/iosfwd opens a
> "namespace std __attribute__ ((__visibility__ ("default"))) {" then
> #includes /usr/include/c++/4.2/iosfwd which has:
> typedef basic_ostream<char> ostream; (line 6311)
>
> So they lead to different symbols, which breaks linking. What to do?

Don't try to "fix" this by making STLport use namespace std; it is not
binary-compatible with libstdc++, which is why it uses a different
namespace. You must use the same implementation (libraries and headers)
in both Salomé and OpenCASCADE. This should probably be libstdc++; so
far as I know there is little reason to use STLport with g++ today. You
should probably investigate how one of these packages is configured to
use STLport and the other doesn't.

Ben.

--
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.
 

Thread Tools




All times are GMT. The time now is 03:56 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org