On Mon, 28 Aug 2000 10:51:52 +0200 Pavel Hlavnicka <[EMAIL PROTECTED]> wrote:
>
> > > Unfortunately not. FreeBSD account, which we use for testing, has badly
> > > compiled C libraries, and doesn't allow to link C++ libraries to C programs.
> > >
> > > Perl extension itself compiles fine, but running tests results with some
> > > unresolved externals.
> >
> > That sounds about like what I saw. Unresolved externals were for C++
> > builtin's like delete (with name mangling).
>
> It's time to describe all my experience.
>
> The very first problem I've met was linking of sabcmd program. Original
> version of this utility was written in C, while the sablot libraries was
> C++. Linking on FreeBSD resulted to unresolved externals related to
> exception handling. Just renaming .c to .cpp file was enough (of course
> together with plenty of work, which was done by libtool and automake).
>
> I serched the deja.com archive. Explanation, I've found said, that
> problem is caused by incompatibility between compiler version and
> version of libc (or stdc++ stc.). It makes sense to me. Compiler
> (linker?) adds some 'magic' calls to the output files, which are
> responsible for several system tasks, exception handling is one of them.
I doubt that is the problem I saw. The exceptions problem is separate to the
problem with missing C++ primitives like delete and new. FreeBSD still uses
an older version of gcc which doesn't do exceptions (gcc didn't do exceptions
until version 2.8). This means that gcc can't compile the C++ sablotron
libraries without a little bit of modification. This is not the same problem
as linking C++ libraries from C.
> Another version of compiler doesn't add these calls, because it
> supposes, that they are introduced in std. libs. Thats all.
C++ linking is pretty non-standardised. Given that everything in this
scenario is built with gcc, gcc knows that when it finds C++ libraries it has
to link in its basic c++ library as well, using what I understand to be a gcc
specific linking scheme. libraries can't call in other libraries, so perl's
dynamic linking arrangement needs to know to bring in the c++ primitives
library before the sablotron library. I tried specifying extra libraries in
the perl setup (Makefile.PL) but with no success. I'm not entirely sure which
library I should be using (libg++ or libstdc++), but I've had no success with
either so far. I suspect that I only need libstdc++ ?
Do you have any confirmation that the compiler you were working with is not
the one used to compile the standard libraries? This strikes me as unlikely
on a vanilla system, or one that had been maintained in a typical manner, but
it's possible if the compiler has been switched without doing a 'make world'
(recompiling everything) to bring the whole system into line.
> > I'm curious that you say that the C Libraries are badly compiled. Is this
> > something specific to the machine where you have an account, or part of the
> > way a default FreeBSD machine is configured? What do you know about this
> > problem? I've had problems as described on FreeBSD systems which should be
> > pretty vanilla in this regard.
>
> Actually C libraries are not *badly* compiled, but not compatible with
> used compiler. I'm not expert on this field, and compiling and testing
> sablotron on FreeBSD is my only experience with this system. somebody
> else has to help us.
>
> Our account was managed somewhere at West Coast (actually very far from
> Prague :-), and I don't know any details.
>
> > libtool has some problems with linking C and C++ which are noted in its
> > documentation. If this hasn't caused problems under Linux, then where is the
> > point of divergence? Has any comparison been done between the way gcc is
> > compiled under Linux and the way it's compiled under FreeBSD? As far as I can
> > tell, the differences are all contained in the GCC source distribution config
> > files.
>
> Libtool ducumentation is little bit vague on this filed, but described
> problems are very similar to ours. The point of divergence is given
> strictly by the compiler implementation (just my opinion).
It's the same compiler, and a very similar system. The differences in how it
is installed are expressed in the config files within the gcc distribution's
config directory.
On the other hand, FreeBSD uses a different linker to linux. Libtool
presumably knows enough about the differences to pass the right flags for
building sabcmd, but presumably perl doesn't get the linker arguments right.
I suspect that the difference is that libtool calls gcc using the 'c++' link
rather than 'cc' or 'gcc'. I don't know if it is possible to do this when
building the perl module, or if it would have to be done when building perl.
Apart from that, perhaps it is simply the difference in version of gcc.
I'm a bit puzzled as to why FreeBSD is still using such an old gcc. 2.7.2.3
came out in January 1997. (Later versions are available in the FreeBSD ports
tree, but not installed by default).
> > If there is a problem with the gcc/freebsd config, and it can be addressed
> > without screwing other programs up, it might be possible to get that changed.
> >
> > > Any help with tests on this field are *very* welcome.
> >
> > Tell me what you need.
>
>
> Next steps woul'd be usefull.
>
> a) try to build and install Sablotron on FreeBSD (it's done, as fare as
> I know)
It doesn't work with BSD's make - requires the user to type gmake instead of
make to use gnu make instead. Otherwise this works OK. It would be good to
add a bit to the INSTALL file which explicitly states where the Expat
directory should be unpacked to. Better still make that a separate install
process, and then use the installed libraries.
> b) try to compile and test perl module.
>
> If this file succeeds, it's great, but not informative :-)
>
> If make, make test, fails, please send us reported stuff, and try fo
> find, which std. libraries are reported function living in. Additional
> step is to specify these libraries via 'LIBS' parameter in Makefile.PL.
make appears to work, but then make test fails:
root@sub# make test
PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/arch -Iblib/lib -I/usr/local/lib/pe
rl5/5.6.0/i386-freebsd -I/usr/local/lib/perl5/5.6.0 test.pl
1..10
Can't load 'blib/arch/auto/XML/Sablotron/Sablotron.so' for module XML::Sab
lotron: /usr/local/lib/libsablot.so.43: Undefined symbol "__builtin_vec_ne
w" at /usr/local/lib/perl5/5.6.0/i386-freebsd/DynaLoader.pm line 200.
This test was done with FreeBSD-3.4, perl-5.6.0 and gcc version 2.7.2.3.
--
--
Andrew McNaughton
[EMAIL PROTECTED]
Cellphone: +64 21 323 3076
[EMAIL PROTECTED]
http://www.scoop.co.nz/
[EMAIL PROTECTED]
http://www.tki.org.nz/
