[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native

From: Ben Reser <ben_at_reser.org>
Date: 2004-06-28 04:02:15 CEST

On Sun, Jun 27, 2004 at 06:41:49PM -0400, Russell Yanofsky wrote:
> How do I fix it if I'm using the binary version of ActiveState Perl? I don't
> understand why the bindings have to be built with the same compiler flags as
> perl itself. Some of them, like -DPERL_IMPLICIT_SYS, are clearly
> inappropriate.

Because we use Perl internals. There are a variety of things that
change those internals slightly. Many things in these internals are
done with macros. So if you don't have all the flags set then our calls
to Perl will be out of sync with what the actual perl binary expects.

Say Perl was built with -D_FILE_OFFSET_BITS=64, then off_t will be
64-bits long. But the default is to use 32-bit off_t's. So when we
give Perl an off_t that is 32-bits and it is expecting a 64-bit off_t
we'll get a segfault...

I really don't understand why you think -DPERL_IMPLICIT_SYS is
inappropriate? From what I understand PERL_IMPLICIT_SYS is necessary
for Perl to emulate fork() under Windows.

Just because removing it makes the build work doesn't mean that it's not
necessary. You might even be lucky that your platform happens to be
mostly default and not subject to any definitions...

> The MS linker probably does support -L -l and standard search paths. I
> didn't use them because I dodn't know how they work offhand.

I'll commit something that I think will work for the Subversion
libraries then.

> No. Many of the .lib files are import libraries which are used on windows to
> link to DLLs. Some of them are plain old static libaries though.

Shouldn't the only libs you need to pull in then are the subversion
libs? They should already be linked against the import libraries for
the DLLs they need or for the static libs for anything else? The only
thing we use directly at all (besides the Subversion libraries) would be
APR. And that's for the pool code and the apr_initialize() and
apr_terminate(). Not sure if pulling in the Subversion libs is enough
for the MSVC linker to give us the apr functions or not...

> > I guess I don't see a good way of detecting at build time all of that.
> You can get the locations of the external libraries by reading the
> gen-make.opts file which is written by the build generator. Here's what one
> from my system looks like:
> -- snip --
> [options]
> --with-berkeley-db = ..\db4-win32
> --with-apr = ..\httpd-2.0.49\srclib\apr
> --with-apr-util = ..\httpd-2.0.49\srclib\apr-util
> --with-apr-iconv = ..\httpd-2.0.49\srclib\apr-iconv
> --with-httpd = ..\httpd-2.0.49
> --with-openssl = ..\openssl-0.9.7d
> --with-zlib = ..\zlib113-win32
> -- snip --

If the only thing we need besides the relative paths to the .libs, is
APR, then we should pull in the equivalent of SVN_APR_LIBS...

Ben Reser <ben@reser.org>
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 28 04:03:07 2004

This is an archived mail posted to the Subversion Dev mailing list.