Ben Reser wrote:
> On Sun, Jun 27, 2004 at 06:41:49PM -0400, Russell Yanofsky wrote:
>> 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.
We're not using perl internals, we're just using a handful of public, well
documented API's that perl provides for extension writers. The API's don't
require us to use weird compiler flags, so we shouldn't use them.
> 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 don't think we should be using -D_FILE_OFFSET_BITS either, see
http://www.contactor.se/~dast/svn/archive-2004-01/0471.shtml
>
> 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.
Maybe it is neccessary for Perl to emulate fork under windows, but we're not
building Perl. We're building the subversion bindings, which do not work
with PERL_IMPLICIT_SYS. PERL_IMPLICIT_SYS causes the perl headers to #define
bunch of posix and standard C functions, which interferes with the Microsoft
headers included by APR.
> 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...
Options like -DPERL_IMPLICIT_SYS and -D_FILE_OFFSET_BITS=64 are pretty
invasive. I can't imagine that perl would require extensions to be built
with them.
>> 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...
On windows, the subversion libraries are currently static so you need to
link against the libraries they depend on.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 28 05:17:03 2004