|
osdir.com mailing list archive |
|
Subject: RE: Swig relocation error and sun CC compiler - msg#00088List: programming.swigI wish we could use gcc :-( anyway I have basically made my class that is casuing me problems a stub class. It still wasn't working. I then made sure that I linked in the CC libraries libCrun, libiostream, libCstd and libcx this stops it screaming at the constructor I now get this error Can't locate auto/profile/CProfileDB/LogOutServi.al in @INC (@INC contains: /usr/local/lib/perl5/5.6.0/sun4-solaris /usr/local/lib/perl5/5.6.0 /usr/local/lib/perl5/site_perl/5.6.0/sun4-solaris /usr/local/lib/perl5/site_perl/5.6.0 /usr/local/lib/perl5/site_perl . /export/home/dharmesh/BBCWork/projects/profile/perl) at profile.pl line 26 basically I create the object but the first call LogOutService brings this error. Dharmesh -----Original Message----- From: David Beazley [mailto:beazley@xxxxxxxxxxxxxxx] Sent: 23 August 2002 15:10 To: Dharmesh Raithatha Cc: 'David Beazley'; 'swig@xxxxxxxxxxxxxxx' Subject: RE: [Swig] Swig relocation error and sun CC compiler Dharmesh Raithatha writes: > > It definitely gets into the wrapper as I put a few printf's before the real > call to the CProgDB > > when it gets to this line of code I get this error > > ld.so.1: perl: fatal: relocation error: file ./program.so: symbol > __1cKCProgDB2t6Mpcc_v_: referenced symbol not found > This error is probably caused by a missing library. Are you sure that program.so is linked against all of the necessary C++ librarys? It is also possible that the C++ library is incomplete. For example, if a class defined a member function that was never implemented and never used, a stand-alone program might compile, but a SWIG generated wrapper would fail (since SWIG wrappers would try to access the undefined member). Also, one last thing that may or may not be applicable. When linking C++ extensions on Solaris with CC, you might need to include -lCrun. > To me this sounds like it hasn't created the library using Position > indpependant code, but I compiled the library myself. > I don't think PIC has anything to do with this. I'd check on the libraries first. Cheers, Dave BBCi at http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system, do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. _______________________________________________ Swig maillist - Swig@xxxxxxxxxxxxxxx http://mailman.cs.uchicago.edu/mailman/listinfo/swig Thread at a glance:
Previous Message by Date: click to view message previewRE: Swig relocation error and sun CC compilerDharmesh Raithatha writes: > Hello again, > > One thing I don't understand is that if the libraries were missing then > surely it would complain about that code and not the constructor, also my > perl program does manage to create the other object which comes from a > different library. > Not necessarily. A constructor is part of a library just like anything else. > I am also using libxml2 and it is being used from one of the libraries > dynamically. Could this be a problem. > One thought that comes to mind is that the class you are wrapping might be abstract. If you don't tell SWIG about that, it would try to create a constructor wrapper for it (which would be wrong). What happens if you stick this in the interface file? %nodefault Foo; where "Foo" is the name of the class that's having the constructor problem? Cheers, Dave _______________________________________________ Swig maillist - Swig@xxxxxxxxxxxxxxx http://mailman.cs.uchicago.edu/mailman/listinfo/swig Next Message by Date: click to view message previewRE: Swig relocation error and sun CC compilerDharmesh Raithatha writes: > Hmmm... > > I wish we could use gcc :-( > > anyway I have basically made my class that is casuing me problems a stub > class. > > It still wasn't working. I then made sure that I linked in the CC libraries > libCrun, libiostream, libCstd and libcx > > this stops it screaming at the constructor > > I now get this error > > Can't locate auto/profile/CProfileDB/LogOutServi.al in @INC (@INC contains: > /usr/local/lib/perl5/5.6.0/sun4-solaris /usr/local/lib/perl5/5.6.0 > /usr/local/lib/perl5/site_perl/5.6.0/sun4-solaris > /usr/local/lib/perl5/site_perl/5.6.0 /usr/local/lib/perl5/site_perl . > /export/home/dharmesh/BBCWork/projects/profile/perl) at profile.pl line 26 > > basically I create the object but the first call LogOutService brings this > error. > Well, this looks like a Perl script error-not one due to SWIG. My gut feeling on this tells me that you are somehow trying to construct an object for which no constructor exists. First, it wouldn't work because no constructor was defined in the library itself. Now it doesn't work, because there is no constructor in the Perl extension module. Without knowing more about the actual class definition of the object in question, it's hard to say. As for gcc, I don't really see what that has to do with this problem. The Sun CC compiler worked fine with SWIG the last time I checked. You aren't, by chance, trying to link C++ code created with two different compilers together? (i.e., a library compiled with g++ and an extension module compiled with CC). That definitely won't work. Cheers, Dave _______________________________________________ Swig maillist - Swig@xxxxxxxxxxxxxxx http://mailman.cs.uchicago.edu/mailman/listinfo/swig Previous Message by Thread: click to view message previewRE: Swig relocation error and sun CC compilerDharmesh Raithatha writes: > Hello again, > > One thing I don't understand is that if the libraries were missing then > surely it would complain about that code and not the constructor, also my > perl program does manage to create the other object which comes from a > different library. > Not necessarily. A constructor is part of a library just like anything else. > I am also using libxml2 and it is being used from one of the libraries > dynamically. Could this be a problem. > One thought that comes to mind is that the class you are wrapping might be abstract. If you don't tell SWIG about that, it would try to create a constructor wrapper for it (which would be wrong). What happens if you stick this in the interface file? %nodefault Foo; where "Foo" is the name of the class that's having the constructor problem? Cheers, Dave _______________________________________________ Swig maillist - Swig@xxxxxxxxxxxxxxx http://mailman.cs.uchicago.edu/mailman/listinfo/swig Next Message by Thread: click to view message previewRE: Swig relocation error and sun CC compilerDharmesh Raithatha writes: > Hmmm... > > I wish we could use gcc :-( > > anyway I have basically made my class that is casuing me problems a stub > class. > > It still wasn't working. I then made sure that I linked in the CC libraries > libCrun, libiostream, libCstd and libcx > > this stops it screaming at the constructor > > I now get this error > > Can't locate auto/profile/CProfileDB/LogOutServi.al in @INC (@INC contains: > /usr/local/lib/perl5/5.6.0/sun4-solaris /usr/local/lib/perl5/5.6.0 > /usr/local/lib/perl5/site_perl/5.6.0/sun4-solaris > /usr/local/lib/perl5/site_perl/5.6.0 /usr/local/lib/perl5/site_perl . > /export/home/dharmesh/BBCWork/projects/profile/perl) at profile.pl line 26 > > basically I create the object but the first call LogOutService brings this > error. > Well, this looks like a Perl script error-not one due to SWIG. My gut feeling on this tells me that you are somehow trying to construct an object for which no constructor exists. First, it wouldn't work because no constructor was defined in the library itself. Now it doesn't work, because there is no constructor in the Perl extension module. Without knowing more about the actual class definition of the object in question, it's hard to say. As for gcc, I don't really see what that has to do with this problem. The Sun CC compiler worked fine with SWIG the last time I checked. You aren't, by chance, trying to link C++ code created with two different compilers together? (i.e., a library compiled with g++ and an extension module compiled with CC). That definitely won't work. Cheers, Dave _______________________________________________ Swig maillist - Swig@xxxxxxxxxxxxxxx http://mailman.cs.uchicago.edu/mailman/listinfo/swig Loading Comments...
|
|
