You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Olaf Hering <ol...@suse.de> on 2008/01/23 14:58:33 UTC
[PATCH] clear LD_RUN_PATH in perl bindings
clear LD_RUN_PATH, it will end up as RPATH in ELF binaries
Patch was added Dec 2005 for 1.3.x, maybe its already obsolete
Makefile.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/Makefile.in
+++ b/Makefile.in
@@ -643,7 +643,7 @@ $(SWIG_PL_DIR)/native/Makefile.PL: $(SWI
./config.status subversion/bindings/swig/perl/native/Makefile.PL
$(SWIG_PL_DIR)/native/Makefile: $(SWIG_PL_DIR)/native/Makefile.PL $(swig-pl_native_Makefile_DEPS)
- cd $(SWIG_PL_DIR)/native; $(PERL) Makefile.PL
+ cd $(SWIG_PL_DIR)/native; $(PERL) Makefile.PL ; for i in `grep -wl ^LD_RUN_PATH Makefile Makefile.[^P]*` ; do sed -i 's@^LD_RUN_PATH.*@LD_RUN_PATH=@' $$i ; done
swig-pl_DEPS = $(SWIG_PL_DIR)/native/Makefile
swig-pl: $(swig-pl_DEPS)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PIE / PIC in a nutshell
Posted by Branko Čibej <br...@xbc.nu>.
Peter Samuelson wrote:
> [Branko Cibej]
>
>> On the other hand, I'd like to hear a bit more about why we'd want to
>> use -fpie, apart from that "security people" like it.
>>
>
> To understand PIE you must understand PIC....
>
Aargh. I know what PIE does, and I know what PIC does, and I'm still
asking: Why would we want to use -fpie in the default compiler flags,
given that said flags can be easily overriden on any system that
supports -fpie?
In other words, if some security-enhanced Linux distro wants to use
-fpie all over the place, well and good. Nobody's stopping them.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
PIE / PIC in a nutshell (was: [PATCH] use -pie in CFLAGS)
Posted by Peter Samuelson <pe...@p12n.org>.
[Branko Cibej]
> On the other hand, I'd like to hear a bit more about why we'd want to
> use -fpie, apart from that "security people" like it.
To understand PIE you must understand PIC....
PIC (position-independent code) lets you share memory-mapped executable
code between processes without hard-coding the address space location.
Shared libraries use PIC so that all instances of the library in all
running processes can use a single copy of the library code in RAM.
This technique is used on most Unix systems, though I _believe_ Windows
DLLs are not PIC and are not shared in memory.
The disadvantage of PIC is that the code itself is somewhat less
efficient, since you have to use lookup tables and registers everywhere
instead of hard-coded addresses. Even so, sharing your RAM between
processes is enough of a win that most people build all shared
libraries as PIC.
Executables don't need to be PIC because you can just hard-code the
address space of the executable code, at link time. You can't easily
do that for the libraries since they're used by multiple
executables.[1]
[1] Well, you can. OSF/1 and perhaps other systems used to get
around this, without PIC, by having a global address space
allocation scheme that the linker could use, and update, each
time you build a new system library. (It helps to have a 64-bit
address space to play in.) But this system was something of a
pain to use, because the allocation file was owned by root, so
you had to 'su' in order to update it for your newly built
library. Nobody's build systems ever seemed to do this
automatically in 'make install', of course.
There's a secondary benefit to PIC in the security world: address space
randomization. Basically, if you can map your code to random locations
each time you start a process, most stack smashing security attacks
become infeasible, because the attacker generally has to have an
educated guess how to jump to, for example, the system() function.
If you want full address space randomization at runtime, foiling a
large class of security attacks, you can build your executables as PIC
... but the efficiency cost is high enough to be unpalatable. Which
brings us to PIE, position-independent executables. PIE provides
position independence without most of the cost of PIC. PIE only works
for executables, not shared libraries, so PIC is still used for the
latter.
Note, you still need an OS runtime that supports address space
randomization, in order for PIE to be of much practical benefit.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] use -pie in CFLAGS
Posted by Branko Čibej <br...@xbc.nu>.
Olaf Hering wrote:
> On Thu, Jan 24, Arfrever Frehtes Taifersar Arahesis wrote:
>
>
>> Are you sure that -fpie etc. are supported by all compilers?
>>
>
> I'm sure all recent gcc versions handle it.
>
But we can test during configure if the compiler is gcc and if it
understands those options.
On the other hand, I'd like to hear a bit more about why we'd want to
use -fpie, apart from that "security people" like it.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] use -pie in CFLAGS
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Olaf Hering <ol...@suse.de> writes:
> On Thu, Jan 24, Arfrever Frehtes Taifersar Arahesis wrote:
>
> > Are you sure that -fpie etc. are supported by all compilers?
>
> I'm sure all recent gcc versions handle it.
That sounds like "no".
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] use -pie in CFLAGS
Posted by Olaf Hering <ol...@suse.de>.
On Thu, Jan 24, Arfrever Frehtes Taifersar Arahesis wrote:
> Are you sure that -fpie etc. are supported by all compilers?
I'm sure all recent gcc versions handle it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] use -pie in CFLAGS
Posted by Arfrever Frehtes Taifersar Arahesis <ar...@gmail.com>.
2008-01-23 16:00:30 Olaf Hering napisał(a):
> Security people like -fpie compiler option.
> I came up with this change. Its used since August 2005.
>
> Makefile.in | 17 ++++++++++-------
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -150,24 +150,27 @@ CXXFLAGS = @CXXFLAGS@ $(EXTRA_CXXFLAGS)
> CPPFLAGS = @CPPFLAGS@ $(EXTRA_CPPFLAGS)
> LDFLAGS = @LDFLAGS@ $(EXTRA_LDFLAGS)
>
> +NOPIECFLAGS = -fno-pie -fno-PIE
> +PIECFLAGS = -fpie -fPIE
> +PIELDFLAGS = -pie
> COMPILE = $(CC) $(CPPFLAGS) $(CFLAGS) $(INCLUDES)
> COMPILE_CXX = $(CXX) $(CPPFLAGS) $(CXXFLAGS) $(INCLUDES)
> -LT_COMPILE = $(LIBTOOL) $(LTFLAGS) --mode=compile $(COMPILE)
> +LT_COMPILE = $(LIBTOOL) $(LTFLAGS) --mode=compile $(COMPILE) $(NOPIECFLAGS)
>
> # special compilation for files destined for mod_dav_svn
> -COMPILE_APACHE_MOD = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CPPFLAGS) $(CFLAGS) $(APACHE_INCLUDES) $(INCLUDES) -o $@ -c
> +COMPILE_APACHE_MOD = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CPPFLAGS) $(CFLAGS) $(NOPIECFLAGS) $(APACHE_INCLUDES) $(INCLUDES) -o $@ -c
>
> # special compilation for files destined for libsvn_swig_* (e.g. swigutil_*.c)
> -COMPILE_SWIG_PY = $(LIBTOOL) $(LTFLAGS) --mode=compile $(SWIG_PY_COMPILE) $(CPPFLAGS) -DSWIGPYTHON $(CFLAGS) $(SWIG_PY_INCLUDES) $(INCLUDES) -o $@ -c
> -COMPILE_SWIG_PL = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CPPFLAGS) $(CFLAGS) $(SWIG_PL_INCLUDES) $(INCLUDES) -o $@ -c
> -COMPILE_SWIG_RB = $(LIBTOOL) $(LTFLAGS) --mode=compile $(SWIG_RB_COMPILE) $(CPPFLAGS) $(CFLAGS) $(SWIG_RB_INCLUDES) $(INCLUDES) -o $@ -c
> +COMPILE_SWIG_PY = $(LIBTOOL) $(LTFLAGS) --mode=compile $(SWIG_PY_COMPILE) $(CPPFLAGS) -DSWIGPYTHON $(CFLAGS) $(NOPIECFLAGS) $(SWIG_PY_INCLUDES) $(INCLUDES) -o $@ -c
> +COMPILE_SWIG_PL = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CPPFLAGS) $(CFLAGS) $(NOPIECFLAGS) $(SWIG_PL_INCLUDES) $(INCLUDES) -o $@ -c
> +COMPILE_SWIG_RB = $(LIBTOOL) $(LTFLAGS) --mode=compile $(SWIG_RB_COMPILE) $(CPPFLAGS) $(CFLAGS) $(NOPIECFLAGS) $(SWIG_RB_INCLUDES) $(INCLUDES) -o $@ -c
>
> # special compilation for files destined for javahl (i.e. C++)
> -COMPILE_JAVAHL_CXX = $(LIBTOOL) $(LTCXXFLAGS) --mode=compile $(COMPILE_CXX) $(JAVAHL_INCLUDES) -o $@ -c
> +COMPILE_JAVAHL_CXX = $(LIBTOOL) $(LTCXXFLAGS) --mode=compile $(COMPILE_CXX) $(NOPIECFLAGS) $(JAVAHL_INCLUDES) -o $@ -c
> COMPILE_JAVAHL_JAVAC = $(JAVAC) $(JAVAC_FLAGS)
> COMPILE_JAVAHL_JAVAH = $(JAVAH)
>
> -LINK = $(LIBTOOL) $(LTFLAGS) --mode=link $(CC) $(LT_LDFLAGS) $(CFLAGS) $(LDFLAGS) -rpath $(libdir)
> +LINK = $(LIBTOOL) $(LTFLAGS) --mode=link $(CC) $(LT_LDFLAGS) $(CFLAGS) $(LDFLAGS) $(PIELDFLAGS) -rpath $(libdir)
>
> # special link rule for mod_dav_svn
> LINK_APACHE_MOD = $(LIBTOOL) $(LTFLAGS) --mode=link $(CC) $(LT_LDFLAGS) $(CFLAGS) $(LDFLAGS) -rpath $(APACHE_LIBEXECDIR) -avoid-version -module $(APACHE_LDFLAGS)
>
Are you sure that -fpie etc. are supported by all compilers?
--
Arfrever Frehtes Taifersar Arahesis
Re: [PATCH] do not use neon.la files
Posted by Arfrever Frehtes Taifersar Arahesis <ar...@gmail.com>.
2008-01-23 16:09:09 Olaf Hering napisał(a):
> We removed most static libs and the .la files.
> Maybe the change below will work for everyone.
>
> Index: build/ac-macros/neon.m4
> ===================================================================
> --- build/ac-macros/neon.m4.orig 2007-10-08 04:23:55.000000000 +0200
> +++ build/ac-macros/neon.m4 2007-11-26 23:12:19.000000000 +0100
> @@ -143,7 +143,7 @@ AC_DEFUN(SVN_NEON_CONFIG,
> test "$svn_allowed_neon" = "any"; then
> svn_allowed_neon_on_system="yes"
> SVN_NEON_INCLUDES=[`$neon_config --cflags | sed -e 's/-D[^ ]*//g'`]
> - NEON_LIBS=`$neon_config --la-file`
> + NEON_LIBS=`$neon_config --libs`
> CFLAGS=["$CFLAGS `$neon_config --cflags | sed -e 's/-I[^ ]*//g'`"]
> svn_lib_neon="yes"
> break
>
-1 until `neon-config --libs` is fixed. Currently it contains LDFLAGS and
libraries which are dependencies of Neon.
It's still broken in Neon trunk.
`neon-config --la-file` doesn't cause any problems.
--
Arfrever Frehtes Taifersar Arahesis
[PATCH] do not use neon.la files
Posted by Olaf Hering <ol...@suse.de>.
We removed most static libs and the .la files.
Maybe the change below will work for everyone.
Index: build/ac-macros/neon.m4
===================================================================
--- build/ac-macros/neon.m4.orig 2007-10-08 04:23:55.000000000 +0200
+++ build/ac-macros/neon.m4 2007-11-26 23:12:19.000000000 +0100
@@ -143,7 +143,7 @@ AC_DEFUN(SVN_NEON_CONFIG,
test "$svn_allowed_neon" = "any"; then
svn_allowed_neon_on_system="yes"
SVN_NEON_INCLUDES=[`$neon_config --cflags | sed -e 's/-D[^ ]*//g'`]
- NEON_LIBS=`$neon_config --la-file`
+ NEON_LIBS=`$neon_config --libs`
CFLAGS=["$CFLAGS `$neon_config --cflags | sed -e 's/-I[^ ]*//g'`"]
svn_lib_neon="yes"
break
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] use ipv4 if the ipv6 address cant be reached
Posted by David Glasser <gl...@davidglasser.net>.
Has anyone familiar with these issues had the chance to review this?
--dave
On Jan 23, 2008 7:06 AM, Olaf Hering <ol...@suse.de> wrote:
>
> Fall back to ipv4 if the host has an ipv6 address,
> but doesnt respond to ipv6 right now.
> This change worked for us.
>
> https://bugzilla.novell.com/show_bug.cgi?id=193350
>
> ---
> subversion/libsvn_ra_svn/client.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> --- a/subversion/libsvn_ra_svn/client.c
> +++ b/subversion/libsvn_ra_svn/client.c
> @@ -145,10 +145,30 @@ static svn_error_t *make_connection(cons
> return svn_error_wrap_apr(status, _("Can't create socket"));
>
> status = apr_socket_connect(*sock, sa);
> + if (!status)
> + goto out;
> + if (sa->family == APR_INET6) {
> + status = apr_sockaddr_info_get(&sa, hostname, APR_INET, port, 0, pool);
> + if (status)
> + return svn_error_createf(status, NULL, _("Unknown hostname '%s'"),
> + hostname);
> +#ifdef MAX_SECS_TO_LINGER
> + /* ### old APR interface */
> + status = apr_socket_create(sock, sa->family, SOCK_STREAM, pool);
> +#else
> + status = apr_socket_create(sock, sa->family, SOCK_STREAM, APR_PROTO_TCP,
> + pool);
> +#endif
> + if (status)
> + return svn_error_wrap_apr(status, _("Can't create socket"));
> +
> + status = apr_socket_connect(*sock, sa);
> + }
> if (status)
> return svn_error_wrap_apr(status, _("Can't connect to host '%s'"),
> hostname);
>
> +out:
> return SVN_NO_ERROR;
> }
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[PATCH] use ipv4 if the ipv6 address cant be reached
Posted by Olaf Hering <ol...@suse.de>.
Fall back to ipv4 if the host has an ipv6 address,
but doesnt respond to ipv6 right now.
This change worked for us.
https://bugzilla.novell.com/show_bug.cgi?id=193350
---
subversion/libsvn_ra_svn/client.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
--- a/subversion/libsvn_ra_svn/client.c
+++ b/subversion/libsvn_ra_svn/client.c
@@ -145,10 +145,30 @@ static svn_error_t *make_connection(cons
return svn_error_wrap_apr(status, _("Can't create socket"));
status = apr_socket_connect(*sock, sa);
+ if (!status)
+ goto out;
+ if (sa->family == APR_INET6) {
+ status = apr_sockaddr_info_get(&sa, hostname, APR_INET, port, 0, pool);
+ if (status)
+ return svn_error_createf(status, NULL, _("Unknown hostname '%s'"),
+ hostname);
+#ifdef MAX_SECS_TO_LINGER
+ /* ### old APR interface */
+ status = apr_socket_create(sock, sa->family, SOCK_STREAM, pool);
+#else
+ status = apr_socket_create(sock, sa->family, SOCK_STREAM, APR_PROTO_TCP,
+ pool);
+#endif
+ if (status)
+ return svn_error_wrap_apr(status, _("Can't create socket"));
+
+ status = apr_socket_connect(*sock, sa);
+ }
if (status)
return svn_error_wrap_apr(status, _("Can't connect to host '%s'"),
hostname);
+out:
return SVN_NO_ERROR;
}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] close racecondition with make -j in header_wrappers.py
Posted by David Glasser <gl...@davidglasser.net>.
On Jan 29, 2008 12:15 PM, Peter Samuelson <pe...@p12n.org> wrote:
>
> [David Glasser]
> > Ah, no wonder it fails for me if I put my swig commands under -j.
> > I'm not too familiar with the SWIG generation process, though; can
> > another commiter review this? Why would "make" be trying to write
> > the same file multiple times anyway? That seems wrong.
>
> From what I can see, it's not that the make process is writing the same
> file multiple times: it is that the output files in question are
> dependencies of other make targets. If your make is threaded, one
> thread might notice a file's existence and decide to build other
> targets that depend on it - even if another thread is still writing to
> the original file. By writing to a different filename then renaming it
> atomically, this won't happen.
>
> ...Though this does seem like it would be a common race condition with
> all kinds of build processes. Perhaps 'make -j' tries to avoid the
> situation, but is thwarted by recursive $(MAKE) invocation, or
> something.
I'd like to see this issue fixed, but I'd still like to see somebody
explain why the same file is being generated multiple times by make
-j... It seems like the right solution would be to not make our build
process do extra work!
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] close racecondition with make -j in header_wrappers.py
Posted by Peter Samuelson <pe...@p12n.org>.
[David Glasser]
> Ah, no wonder it fails for me if I put my swig commands under -j.
> I'm not too familiar with the SWIG generation process, though; can
> another commiter review this? Why would "make" be trying to write
> the same file multiple times anyway? That seems wrong.
Re: [PATCH] close racecondition with make -j in header_wrappers.py
Posted by David Glasser <gl...@davidglasser.net>.
Ah, no wonder it fails for me if I put my swig commands under -j. I'm
not too familiar with the SWIG generation process, though; can another
commiter review this? Why would "make" be trying to write the same
file multiple times anyway? That seems wrong.
--dave
On Jan 23, 2008 7:04 AM, Olaf Hering <ol...@suse.de> wrote:
>
> sometimes make -j fails. I came up with the change below.
> This change is in use since Feb 2006.
> Still applies to trunk.
>
> /usr/bin/python /usr/src/packages/BUILD/subversion-1.3.x/build/generator/swig/header_wrappers.py /usr/src/packages/BUILD/subversion-1.3.x/build.conf /usr/bin/swig /usr/src/packages/BUILD/subversion-1.3.x/subversion/include/svn_auth.h
>
> /usr/src/packages/BUILD/subversion-1.3.x/subversion/bindings/swig/core.i:613: Error: Unable to find 'svn_auth_h.swg'
> /usr/bin/swig -I/usr/src/packages/BUILD/subversion-1.3.x/subversion/bindings/swig -I/usr/src/packages/BUILD/subversion-1.3.x/subversion/bindings/swig/include -I/usr/src/packages/BUILD/subversion-1.3.x/subversion/bindings/swig/proxy -I/usr/src/packages/BUILD/subversion-1.3.x/subversion/bindings/swig/proxy -I/usr/src/packages/BUILD/subversion-1.3.x/subversion/include -I/usr/include -I/usr/include/apr-1 -python -classic -w451 -w305 -o subversion/bindings/swig/python/core.c /usr/src/packages/BUILD/subversion-1.3.x/subversion/bindings/swig/core.i
>
> build/generator/swig/header_wrappers.py | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- a/build/generator/swig/header_wrappers.py
> +++ b/build/generator/swig/header_wrappers.py
> @@ -239,7 +239,7 @@ class Generator(generator.swig.Generator
> self.proxy_filename(base_fname))
>
> # Open the output file
> - self.ofile = open(output_fname, 'w')
> + self.ofile = open(output_fname + "~", 'w')
> self.ofile.write('/* Proxy classes for %s\n' % base_fname)
> self.ofile.write(' * DO NOT EDIT -- AUTOMATICALLY GENERATED */\n')
>
> @@ -264,6 +264,7 @@ class Generator(generator.swig.Generator
>
> # Close our output file
> self.ofile.close()
> + os.rename(output_fname + "~", output_fname)
>
> def process_header_file(self, fname):
> """Generate a wrapper around a header file"""
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[PATCH] close racecondition with make -j in header_wrappers.py
Posted by Olaf Hering <ol...@suse.de>.
sometimes make -j fails. I came up with the change below.
This change is in use since Feb 2006.
Still applies to trunk.
/usr/bin/python /usr/src/packages/BUILD/subversion-1.3.x/build/generator/swig/header_wrappers.py /usr/src/packages/BUILD/subversion-1.3.x/build.conf /usr/bin/swig /usr/src/packages/BUILD/subversion-1.3.x/subversion/include/svn_auth.h
/usr/src/packages/BUILD/subversion-1.3.x/subversion/bindings/swig/core.i:613: Error: Unable to find 'svn_auth_h.swg'
/usr/bin/swig -I/usr/src/packages/BUILD/subversion-1.3.x/subversion/bindings/swig -I/usr/src/packages/BUILD/subversion-1.3.x/subversion/bindings/swig/include -I/usr/src/packages/BUILD/subversion-1.3.x/subversion/bindings/swig/proxy -I/usr/src/packages/BUILD/subversion-1.3.x/subversion/bindings/swig/proxy -I/usr/src/packages/BUILD/subversion-1.3.x/subversion/include -I/usr/include -I/usr/include/apr-1 -python -classic -w451 -w305 -o subversion/bindings/swig/python/core.c /usr/src/packages/BUILD/subversion-1.3.x/subversion/bindings/swig/core.i
build/generator/swig/header_wrappers.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/build/generator/swig/header_wrappers.py
+++ b/build/generator/swig/header_wrappers.py
@@ -239,7 +239,7 @@ class Generator(generator.swig.Generator
self.proxy_filename(base_fname))
# Open the output file
- self.ofile = open(output_fname, 'w')
+ self.ofile = open(output_fname + "~", 'w')
self.ofile.write('/* Proxy classes for %s\n' % base_fname)
self.ofile.write(' * DO NOT EDIT -- AUTOMATICALLY GENERATED */\n')
@@ -264,6 +264,7 @@ class Generator(generator.swig.Generator
# Close our output file
self.ofile.close()
+ os.rename(output_fname + "~", output_fname)
def process_header_file(self, fname):
"""Generate a wrapper around a header file"""
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[PATCH] require java 1.4 or later
Posted by Olaf Hering <ol...@suse.de>.
No idea if that patch will work for everyone.
At least for openSuSE we have to use java 1.4 mode.
Cant remember why.
---
configure.ac | 2 +-
subversion/bindings/javahl/build/build.xml | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
--- a/configure.ac
+++ b/configure.ac
@@ -565,7 +565,7 @@ fi
AC_PATH_PROGS(PYTHON, "$PYTHON", none)
# The minimum version for the JVM runtime for our Java bytecode.
-JAVA_OLDEST_WORKING_VER='1.2'
+JAVA_OLDEST_WORKING_VER='1.4'
# SVN_CHECK_JDK sets $JAVA_CLASSPATH
SVN_CHECK_JDK($JAVA_OLDEST_WORKING_VER)
--- a/subversion/bindings/javahl/build/build.xml
+++ b/subversion/bindings/javahl/build/build.xml
@@ -21,7 +21,7 @@
<target name="compile" unless="junit.path"
description="Compile the Java binding source files">
- <javac compiler="modern" destdir="classes">
+ <javac source="1.4" target="1.4" destdir="classes">
<src path="src"/>
<exclude name="org/tigris/subversion/javahl/tests/**"/>
</javac>
@@ -29,7 +29,7 @@
<target name="compile-tests" if="junit.path"
description="Compile the Java test source files">
- <javac compiler="modern" destdir="classes">
+ <javac source="1.4" target="1.4" destdir="classes">
<src path="src"/>
<classpath path="${junit.path}"/>
</javac>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[PATCH] use -pie in CFLAGS
Posted by Olaf Hering <ol...@suse.de>.
Security people like -fpie compiler option.
I came up with this change. Its used since August 2005.
Makefile.in | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
--- a/Makefile.in
+++ b/Makefile.in
@@ -150,24 +150,27 @@ CXXFLAGS = @CXXFLAGS@ $(EXTRA_CXXFLAGS)
CPPFLAGS = @CPPFLAGS@ $(EXTRA_CPPFLAGS)
LDFLAGS = @LDFLAGS@ $(EXTRA_LDFLAGS)
+NOPIECFLAGS = -fno-pie -fno-PIE
+PIECFLAGS = -fpie -fPIE
+PIELDFLAGS = -pie
COMPILE = $(CC) $(CPPFLAGS) $(CFLAGS) $(INCLUDES)
COMPILE_CXX = $(CXX) $(CPPFLAGS) $(CXXFLAGS) $(INCLUDES)
-LT_COMPILE = $(LIBTOOL) $(LTFLAGS) --mode=compile $(COMPILE)
+LT_COMPILE = $(LIBTOOL) $(LTFLAGS) --mode=compile $(COMPILE) $(NOPIECFLAGS)
# special compilation for files destined for mod_dav_svn
-COMPILE_APACHE_MOD = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CPPFLAGS) $(CFLAGS) $(APACHE_INCLUDES) $(INCLUDES) -o $@ -c
+COMPILE_APACHE_MOD = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CPPFLAGS) $(CFLAGS) $(NOPIECFLAGS) $(APACHE_INCLUDES) $(INCLUDES) -o $@ -c
# special compilation for files destined for libsvn_swig_* (e.g. swigutil_*.c)
-COMPILE_SWIG_PY = $(LIBTOOL) $(LTFLAGS) --mode=compile $(SWIG_PY_COMPILE) $(CPPFLAGS) -DSWIGPYTHON $(CFLAGS) $(SWIG_PY_INCLUDES) $(INCLUDES) -o $@ -c
-COMPILE_SWIG_PL = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CPPFLAGS) $(CFLAGS) $(SWIG_PL_INCLUDES) $(INCLUDES) -o $@ -c
-COMPILE_SWIG_RB = $(LIBTOOL) $(LTFLAGS) --mode=compile $(SWIG_RB_COMPILE) $(CPPFLAGS) $(CFLAGS) $(SWIG_RB_INCLUDES) $(INCLUDES) -o $@ -c
+COMPILE_SWIG_PY = $(LIBTOOL) $(LTFLAGS) --mode=compile $(SWIG_PY_COMPILE) $(CPPFLAGS) -DSWIGPYTHON $(CFLAGS) $(NOPIECFLAGS) $(SWIG_PY_INCLUDES) $(INCLUDES) -o $@ -c
+COMPILE_SWIG_PL = $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CPPFLAGS) $(CFLAGS) $(NOPIECFLAGS) $(SWIG_PL_INCLUDES) $(INCLUDES) -o $@ -c
+COMPILE_SWIG_RB = $(LIBTOOL) $(LTFLAGS) --mode=compile $(SWIG_RB_COMPILE) $(CPPFLAGS) $(CFLAGS) $(NOPIECFLAGS) $(SWIG_RB_INCLUDES) $(INCLUDES) -o $@ -c
# special compilation for files destined for javahl (i.e. C++)
-COMPILE_JAVAHL_CXX = $(LIBTOOL) $(LTCXXFLAGS) --mode=compile $(COMPILE_CXX) $(JAVAHL_INCLUDES) -o $@ -c
+COMPILE_JAVAHL_CXX = $(LIBTOOL) $(LTCXXFLAGS) --mode=compile $(COMPILE_CXX) $(NOPIECFLAGS) $(JAVAHL_INCLUDES) -o $@ -c
COMPILE_JAVAHL_JAVAC = $(JAVAC) $(JAVAC_FLAGS)
COMPILE_JAVAHL_JAVAH = $(JAVAH)
-LINK = $(LIBTOOL) $(LTFLAGS) --mode=link $(CC) $(LT_LDFLAGS) $(CFLAGS) $(LDFLAGS) -rpath $(libdir)
+LINK = $(LIBTOOL) $(LTFLAGS) --mode=link $(CC) $(LT_LDFLAGS) $(CFLAGS) $(LDFLAGS) $(PIELDFLAGS) -rpath $(libdir)
# special link rule for mod_dav_svn
LINK_APACHE_MOD = $(LIBTOOL) $(LTFLAGS) --mode=link $(CC) $(LT_LDFLAGS) $(CFLAGS) $(LDFLAGS) -rpath $(APACHE_LIBEXECDIR) -avoid-version -module $(APACHE_LDFLAGS)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org