You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Martin Furter <mf...@rola.ch> on 2010/12/14 11:09:34 UTC
[PATCH]: transform_libtool_scripts.py
Hello
I again fell over transform_libtool_scripts.sh on solaris.
Here's a version in python which reads all the needed information from
build.conf instead of searching the filesystem.
I ran "make check" but it stopped at authz_tests:
[[[
...
Running tests in authz_tests.py [36/87][SKIPPED] Python sqlite3 module required
Don't know what to do about authz_tests.py
]]]
It's right, I don't have the sqlite3 module, but that's not a reason to
stop testing. I'll investigate that later...
There were just two FAIL's in fs-pack-test, the other tests were running
successfully.
Please comment and/or approve for commit.
- Martin
[[[
Replace a disgusting shell script by nice python code.
transform_libtool_scripts.py is more portable and also reads build.conf.
* Makefile.in
(transform-libtool-scripts): Call the python script.
* build/transform_libtool_scripts.sh
Delete.
* build/transform_libtool_scripts.py
New file.
]]]
Re: [PATCH]: transform_libtool_scripts.py
Posted by Arfrever Frehtes Taifersar Arahesis <ar...@gmail.com>.
2010-12-16 21:36:45 Philip Martin napisał(a):
> Stefan Sperling <st...@elego.de> writes:
>
> > make install on OpenBSD is now broken.
> > It's not installing binaries but libtool wrappers:
> >
> > $ svn status
> > /usr/bin/sed: can't load library ''
> > /usr/bin/sed: can't load library ''
> > /home/stsp/svn/prefix/svn-trunk/bin/svn: error: `/home/stsp/svn/svn-trunk/.libs/svn' does not exist
>
> That's because the LD_PRELOAD inserted by the transform script at the
> start of the libtool script subversion/svn/svn is breaking the libtool
> script. So the binary does not get created. It's the same error as the
> failing tests.
>
> > This script is just a wrapper for svn.
> > See the libtool documentation for more information.
> > $ file /home/stsp/svn/prefix/svn-trunk/bin/svn
> > /home/stsp/svn/prefix/svn-trunk/bin/svn: Bourne shell script text executable
> >
> > The svn binary in the prefix is supposed to be an ELF executable.
>
> I don't know what the new script is doing differently from the old
> script.
The old script was using 'sed_append 4 ...' and 'sed_append 5 ...' to append
the new lines after the first 4 lines. This regression has been fixed in r1087779.
--
Arfrever Frehtes Taifersar Arahesis
Re: [PATCH]: transform_libtool_scripts.py
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> I don't know what the new script is doing differently from the old
> script. They both generate a whitespace separated list of libraries.
> The new script should have a more accurate list.
With some help from Stefan. The new script produces:
LD_PRELOAD=""
export LD_PRELOAD
and OpenBSD doesn't handle the empty list. The list is empty because
OpenBSD doesn't have .so files so the -f test removes all the libraries.
It appears to have .so.0.0 files.
It turns out that the old script was also broken on OpenBSD. It
produced:
LD_PRELOAD=""#
export LD_PRELOAD# The svn program cannot be directly executed until all the libtool
The # prevents the export line working which means the empty LD_PRELOAD
is not exported.
Here's a patch:
* build/generator/gen_make.py
(write_transform_libtool_scripts): Look for .so.0 and .so.0.0, don't
write LD_PRELOAD lines if empty.
Index: build/generator/gen_make.py
===================================================================
--- build/generator/gen_make.py (revision 1050098)
+++ build/generator/gen_make.py (working copy)
@@ -493,24 +493,34 @@
case $LIB in
*libsvn_test-*) continue ;;
esac
- if [ -f $LIB ]; then
- if [ -z "$EXISTINGLIBS" ]; then
- EXISTINGLIBS="$LIB"
- else
- EXISTINGLIBS="$EXISTINGLIBS $LIB"
- fi
+ if [ ! -f $LIB ]; then
+ LIB=${LIB}.0
+ if [ ! -f $LIB ]; then
+ LIB=${LIB}.0
+ if [ ! -f $LIB ]; then
+ continue
+ fi
+ fi
fi
+
+ if [ -z "$EXISTINGLIBS" ]; then
+ EXISTINGLIBS="$LIB"
+ else
+ EXISTINGLIBS="$EXISTINGLIBS $LIB"
+ fi
done
- cat "$SCRIPT" |
- (
- read LINE
- echo "$LINE"
- echo "LD_PRELOAD=\\"$EXISTINGLIBS\\""
- echo "export LD_PRELOAD"
- cat
- ) < "$SCRIPT" > "$SCRIPT.new"
- mv -f "$SCRIPT.new" "$SCRIPT"
- chmod +x "$SCRIPT"
+ if [ ! -z "$EXISTINGLIBS" ]; then
+ cat "$SCRIPT" |
+ (
+ read LINE
+ echo "$LINE"
+ echo "LD_PRELOAD=\\"$EXISTINGLIBS\\""
+ echo "export LD_PRELOAD"
+ cat
+ ) < "$SCRIPT" > "$SCRIPT.new"
+ mv -f "$SCRIPT.new" "$SCRIPT"
+ chmod +x "$SCRIPT"
+ fi
fi
fi
}
--
Philip
Re: [PATCH]: transform_libtool_scripts.py
Posted by Philip Martin <ph...@wandisco.com>.
Stefan Sperling <st...@elego.de> writes:
> make install on OpenBSD is now broken.
> It's not installing binaries but libtool wrappers:
>
> $ svn status
> /usr/bin/sed: can't load library ''
> /usr/bin/sed: can't load library ''
> /home/stsp/svn/prefix/svn-trunk/bin/svn: error: `/home/stsp/svn/svn-trunk/.libs/svn' does not exist
That's because the LD_PRELOAD inserted by the transform script at the
start of the libtool script subversion/svn/svn is breaking the libtool
script. So the binary does not get created. It's the same error as the
failing tests.
> This script is just a wrapper for svn.
> See the libtool documentation for more information.
> $ file /home/stsp/svn/prefix/svn-trunk/bin/svn
> /home/stsp/svn/prefix/svn-trunk/bin/svn: Bourne shell script text executable
>
> The svn binary in the prefix is supposed to be an ELF executable.
I don't know what the new script is doing differently from the old
script. They both generate a whitespace separated list of libraries.
The new script should have a more accurate list.
--
Philip
Re: [PATCH]: transform_libtool_scripts.py
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Dec 16, 2010 at 09:19:45PM +0100, Stefan Sperling wrote:
> On Thu, Dec 16, 2010 at 08:02:37PM +0000, Philip Martin wrote:
> > Philip Martin <ph...@wandisco.com> writes:
> >
> > > Philip Martin <ph...@wandisco.com> writes:
> > >
> > >> I suppose we fix it by removing libsvn_test from the list of preload
> > >> libraries.
> > >
> > > It's ugly, but I've hardcoded this for now.
> >
> > It's failing on the OpenBSD buildbot:
> >
> > http://ci.apache.org/builders/svn-openbsd-i386/builds/46
> >
> > START: auth-test
> > /usr/bin/sed: can't load library ''
> > /usr/bin/sed: can't load library ''
> > /usr/bin/sed: can't load library ''
> >
> > Perhaps LD_PRELOAD is coming up empty and OpenBSD doesn't like an empty
> > LD_PRELOAD?
>
> It shouldn't have problems with the variable being empty.
> There must be something wrong with the value of the variable.
> In general LD_PRELOAD is supported:
>
> ld.so recognises a number of environment variables that can be used to
> modify its behaviour as follows:
> [...]
> LD_PRELOAD
> A colon separate list of library names to load before any of the
> regular libraries are loaded. This variable is ignored for set-
> user-ID and set-group-ID executables.
make install on OpenBSD is now broken.
It's not installing binaries but libtool wrappers:
$ svn status
/usr/bin/sed: can't load library ''
/usr/bin/sed: can't load library ''
/home/stsp/svn/prefix/svn-trunk/bin/svn: error: `/home/stsp/svn/svn-trunk/.libs/svn' does not exist
This script is just a wrapper for svn.
See the libtool documentation for more information.
$ file /home/stsp/svn/prefix/svn-trunk/bin/svn
/home/stsp/svn/prefix/svn-trunk/bin/svn: Bourne shell script text executable
The svn binary in the prefix is supposed to be an ELF executable.
Stefan
Re: [PATCH]: transform_libtool_scripts.py
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Dec 16, 2010 at 08:02:37PM +0000, Philip Martin wrote:
> Philip Martin <ph...@wandisco.com> writes:
>
> > Philip Martin <ph...@wandisco.com> writes:
> >
> >> I suppose we fix it by removing libsvn_test from the list of preload
> >> libraries.
> >
> > It's ugly, but I've hardcoded this for now.
>
> It's failing on the OpenBSD buildbot:
>
> http://ci.apache.org/builders/svn-openbsd-i386/builds/46
>
> START: auth-test
> /usr/bin/sed: can't load library ''
> /usr/bin/sed: can't load library ''
> /usr/bin/sed: can't load library ''
>
> Perhaps LD_PRELOAD is coming up empty and OpenBSD doesn't like an empty
> LD_PRELOAD?
It shouldn't have problems with the variable being empty.
There must be something wrong with the value of the variable.
In general LD_PRELOAD is supported:
ld.so recognises a number of environment variables that can be used to
modify its behaviour as follows:
[...]
LD_PRELOAD
A colon separate list of library names to load before any of the
regular libraries are loaded. This variable is ignored for set-
user-ID and set-group-ID executables.
Stefan
Re: [PATCH]: transform_libtool_scripts.py
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> Philip Martin <ph...@wandisco.com> writes:
>
>> Philip Martin <ph...@wandisco.com> writes:
>>
>>> I suppose we fix it by removing libsvn_test from the list of preload
>>> libraries.
>>
>> It's ugly, but I've hardcoded this for now.
>
> It's failing on the OpenBSD buildbot:
>
> http://ci.apache.org/builders/svn-openbsd-i386/builds/46
>
> START: auth-test
> /usr/bin/sed: can't load library ''
> /usr/bin/sed: can't load library ''
> /usr/bin/sed: can't load library ''
>
> Perhaps LD_PRELOAD is coming up empty and OpenBSD doesn't like an empty
> LD_PRELOAD?
The OpenBSD man page
http://www.openbsd.org/cgi-bin/man.cgi?query=ld.so&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html
indicates that LD_PRELOAD is colon, not whitespace, separated. Could
that be it? I don't see the old script using colons.
--
Philip
Re: [PATCH]: transform_libtool_scripts.py
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> Philip Martin <ph...@wandisco.com> writes:
>
>> I suppose we fix it by removing libsvn_test from the list of preload
>> libraries.
>
> It's ugly, but I've hardcoded this for now.
It's failing on the OpenBSD buildbot:
http://ci.apache.org/builders/svn-openbsd-i386/builds/46
START: auth-test
/usr/bin/sed: can't load library ''
/usr/bin/sed: can't load library ''
/usr/bin/sed: can't load library ''
Perhaps LD_PRELOAD is coming up empty and OpenBSD doesn't like an empty
LD_PRELOAD?
--
Philip
Re: [PATCH]: transform_libtool_scripts.py
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> I suppose we fix it by removing libsvn_test from the list of preload
> libraries.
It's ugly, but I've hardcoded this for now.
--
Philip
Re: [PATCH]: transform_libtool_scripts.py
Posted by Philip Martin <ph...@wandisco.com>.
Julian Foad <ju...@wandisco.com> writes:
> The patch committed in 1049944 has broken the Centos buildbot and my
> local tests (in Ubuntu 10.04): all the C tests fail to run. If I try to
> run one manually, the result is:
>
> $ obj-dir/subversion/tests/libsvn_client/client-test --list
> /bin/sed: symbol lookup
> error: /home/julianfoad/build/subversion-c/subversion/tests/.libs/libsvn_test-1.so: undefined symbol: test_funcs
> ls: symbol lookup
> error: /home/julianfoad/build/subversion-c/subversion/tests/.libs/libsvn_test-1.so: undefined symbol: test_funcs
> /bin/sed: symbol lookup
> error: /home/julianfoad/build/subversion-c/subversion/tests/.libs/libsvn_test-1.so: undefined symbol: test_funcs
> mkdir: symbol lookup
> error: /home/julianfoad/build/subversion-c/subversion/tests/.libs/libsvn_test-1.so: undefined symbol: test_funcs
> gcc: symbol lookup
> error: /home/julianfoad/build/subversion-c/subversion/tests/.libs/libsvn_test-1.so: undefined symbol: test_funcs
> rm: symbol lookup
> error: /home/julianfoad/build/subversion-c/subversion/tests/.libs/libsvn_test-1.so: undefined symbol: test_funcs
It's the external commands within the libtool script that are failing,
because the exported LD_PRELOAD libraries apply to all commands and the
external commands don't define test_funcs.
I suppose we fix it by removing libsvn_test from the list of preload
libraries. An alternative would be to define LD_PRELOAD near the end of
the script just before the executable is exec'd. It might be a bit
tricky to get the script to identify the right place.
Another alternative: I suppose it might be possible to define some sort
of weak linker symbol for test_funcs, so that executables that don't
define it still run. I'm not sure if that's possible or portable.
--
Philip
Re: [PATCH]: transform_libtool_scripts.py
Posted by Julian Foad <ju...@wandisco.com>.
On Thu, 2010-12-16 at 11:17 +0000, Philip Martin wrote:
> Martin Furter <mf...@rola.ch> writes:
>
> > On Wed, 15 Dec 2010, Philip Martin wrote:
> >
> >> Martin Furter <mf...@rola.ch> writes:
> >>
> >>> Doing some more testing I found another out that non-existing
> >>> libraries have to be removed from LD_PRELOAD.
> >>
> >> Does this interact with --enable-runtime-module-search? That's the
> >> switch that causes Subversion to load RA/FS modules at runtime rather
> >> than linking them to the binary.
> >>
> >> In the past it was difficult to run the regression tests with this
> >> enabled because the runtime loader would pick installed modules ahead of
> >> the ones in the build directory.
> >
> > Yes, there is some interaction...
> >
> > Everything works fine with my patch but without
> > --enable-runtime-module-search.
> >
> > When I enable it I get the following:
> > $ subversion/svnadmin/svnadmin create foo
> > ld.so.1: svnadmin: fatal: relocation error: file /usr/local/lib/libsvn_fs_fs-1.so.0: symbol svn_fs__path_change2_create: referenced symbol not found
> > svnadmin: Failed to load module for FS type 'fsfs'
> > $
> >
> > Making the installed libs inaccessible leads to the following error:
> > $ subversion/svnadmin/svnadmin create foo
> > ld.so.1: svnadmin: fatal: libsvn_fs_fs-1.so.0: open failed: No such file or directory
> > svnadmin: Failed to load module for FS type 'fsfs'
> > $
> >
> > Looking around I see that libsvn_fs_fs-1.so.0 has been built, and it
> > is also present in LD_PRELOAD in subversion/svnadmin/svnadmin. But the
> > path to it is not in LD_LIBRARY_PATH which is created by libtool.
> >
> > If I add it to LD_LIBRARY_PATH it works fine:
> > $ subversion/svnadmin/svnadmin create foo
> > $
> >
> > So I guess there's another patch needed to fix the LD_LIBRARY_PATH
> > created by libtool.
>
> Your patch hasn't made that worse, and generating the script is an
> improvement, so +1 to commit the current patch.
The patch committed in 1049944 has broken the Centos buildbot and my
local tests (in Ubuntu 10.04): all the C tests fail to run. If I try to
run one manually, the result is:
$ obj-dir/subversion/tests/libsvn_client/client-test --list
/bin/sed: symbol lookup
error: /home/julianfoad/build/subversion-c/subversion/tests/.libs/libsvn_test-1.so: undefined symbol: test_funcs
ls: symbol lookup
error: /home/julianfoad/build/subversion-c/subversion/tests/.libs/libsvn_test-1.so: undefined symbol: test_funcs
/bin/sed: symbol lookup
error: /home/julianfoad/build/subversion-c/subversion/tests/.libs/libsvn_test-1.so: undefined symbol: test_funcs
mkdir: symbol lookup
error: /home/julianfoad/build/subversion-c/subversion/tests/.libs/libsvn_test-1.so: undefined symbol: test_funcs
gcc: symbol lookup
error: /home/julianfoad/build/subversion-c/subversion/tests/.libs/libsvn_test-1.so: undefined symbol: test_funcs
rm: symbol lookup
error: /home/julianfoad/build/subversion-c/subversion/tests/.libs/libsvn_test-1.so: undefined symbol: test_funcs
- Julian
Re: [PATCH]: transform_libtool_scripts.py
Posted by Philip Martin <ph...@wandisco.com>.
Martin Furter <mf...@rola.ch> writes:
> On Wed, 15 Dec 2010, Philip Martin wrote:
>
>> Martin Furter <mf...@rola.ch> writes:
>>
>>> Doing some more testing I found another out that non-existing
>>> libraries have to be removed from LD_PRELOAD.
>>
>> Does this interact with --enable-runtime-module-search? That's the
>> switch that causes Subversion to load RA/FS modules at runtime rather
>> than linking them to the binary.
>>
>> In the past it was difficult to run the regression tests with this
>> enabled because the runtime loader would pick installed modules ahead of
>> the ones in the build directory.
>
> Yes, there is some interaction...
>
> Everything works fine with my patch but without
> --enable-runtime-module-search.
>
> When I enable it I get the following:
> $ subversion/svnadmin/svnadmin create foo
> ld.so.1: svnadmin: fatal: relocation error: file /usr/local/lib/libsvn_fs_fs-1.so.0: symbol svn_fs__path_change2_create: referenced symbol not found
> svnadmin: Failed to load module for FS type 'fsfs'
> $
>
> Making the installed libs inaccessible leads to the following error:
> $ subversion/svnadmin/svnadmin create foo
> ld.so.1: svnadmin: fatal: libsvn_fs_fs-1.so.0: open failed: No such file or directory
> svnadmin: Failed to load module for FS type 'fsfs'
> $
>
> Looking around I see that libsvn_fs_fs-1.so.0 has been built, and it
> is also present in LD_PRELOAD in subversion/svnadmin/svnadmin. But the
> path to it is not in LD_LIBRARY_PATH which is created by libtool.
>
> If I add it to LD_LIBRARY_PATH it works fine:
> $ subversion/svnadmin/svnadmin create foo
> $
>
> So I guess there's another patch needed to fix the LD_LIBRARY_PATH
> created by libtool.
Your patch hasn't made that worse, and generating the script is an
improvement, so +1 to commit the current patch.
--
Philip
Re: [PATCH]: transform_libtool_scripts.py
Posted by Martin Furter <mf...@rola.ch>.
On Wed, 15 Dec 2010, Philip Martin wrote:
> Martin Furter <mf...@rola.ch> writes:
>
>> Doing some more testing I found another out that non-existing
>> libraries have to be removed from LD_PRELOAD.
>
> Does this interact with --enable-runtime-module-search? That's the
> switch that causes Subversion to load RA/FS modules at runtime rather
> than linking them to the binary.
>
> In the past it was difficult to run the regression tests with this
> enabled because the runtime loader would pick installed modules ahead of
> the ones in the build directory.
Yes, there is some interaction...
Everything works fine with my patch but without
--enable-runtime-module-search.
When I enable it I get the following:
$ subversion/svnadmin/svnadmin create foo
ld.so.1: svnadmin: fatal: relocation error: file /usr/local/lib/libsvn_fs_fs-1.so.0: symbol svn_fs__path_change2_create: referenced symbol not found
svnadmin: Failed to load module for FS type 'fsfs'
$
Making the installed libs inaccessible leads to the following error:
$ subversion/svnadmin/svnadmin create foo
ld.so.1: svnadmin: fatal: libsvn_fs_fs-1.so.0: open failed: No such file or directory
svnadmin: Failed to load module for FS type 'fsfs'
$
Looking around I see that libsvn_fs_fs-1.so.0 has been built, and it is
also present in LD_PRELOAD in subversion/svnadmin/svnadmin. But the path
to it is not in LD_LIBRARY_PATH which is created by libtool.
If I add it to LD_LIBRARY_PATH it works fine:
$ subversion/svnadmin/svnadmin create foo
$
So I guess there's another patch needed to fix the LD_LIBRARY_PATH created
by libtool.
- Martin
Re: [PATCH]: transform_libtool_scripts.py
Posted by Philip Martin <ph...@wandisco.com>.
Martin Furter <mf...@rola.ch> writes:
> Doing some more testing I found another out that non-existing
> libraries have to be removed from LD_PRELOAD.
Does this interact with --enable-runtime-module-search? That's the
switch that causes Subversion to load RA/FS modules at runtime rather
than linking them to the binary.
In the past it was difficult to run the regression tests with this
enabled because the runtime loader would pick installed modules ahead of
the ones in the build directory.
--
Philip
Re: [PATCH]: transform_libtool_scripts.py
Posted by Martin Furter <mf...@rola.ch>.
Doing some more testing I found another out that non-existing libraries
have to be removed from LD_PRELOAD.
So here's a new patch.
- Martin
On Wed, 15 Dec 2010, Martin Furter wrote:
>
> Here is version 2 of the patch.
>
> On Tue, 14 Dec 2010, Philip Martin wrote:
>
>> Martin Furter <mf...@rola.ch> writes:
>>
>>> The generated script then has to be included into the tarball. I
>>> believe to remember that there's a script which creates the
>>> tarball. Can anyone give me a pointer where I can find it?
>>
>> tools/dist/dist.sh
>>
>> The tarball is created after autogen.sh has been run; autogen.sh runs
>> gen-make.py.
>
> No changes seem to be needed there since it's run in the sandbox.
>
> - Martin
>
>
> [[[
> Generate build/transform_libtool_scripts.sh from gen-make.py using
> information read from build.conf.
>
> * build/generator/gen_make.py
> (write_transform_libtool_scripts,_get_all_lib_deps):
> New functions which generate transform_libtool_scripts.sh.
> (write): Call write_transform_libtool_scripts.
> * build/transform_libtool_scripts.sh
> Delete.
> ]]]
Re: [PATCH]: transform_libtool_scripts.py
Posted by Martin Furter <mf...@rola.ch>.
Doing some more testing I found another out that non-existing libraries
have to be removed from LD_PRELOAD.
So here's a new patch.
- Martin
On Wed, 15 Dec 2010, Martin Furter wrote:
>
> Here is version 2 of the patch.
>
> On Tue, 14 Dec 2010, Philip Martin wrote:
>
>> Martin Furter <mf...@rola.ch> writes:
>>
>>> The generated script then has to be included into the tarball. I
>>> believe to remember that there's a script which creates the
>>> tarball. Can anyone give me a pointer where I can find it?
>>
>> tools/dist/dist.sh
>>
>> The tarball is created after autogen.sh has been run; autogen.sh runs
>> gen-make.py.
>
> No changes seem to be needed there since it's run in the sandbox.
>
> - Martin
>
>
> [[[
> Generate build/transform_libtool_scripts.sh from gen-make.py using
> information read from build.conf.
>
> * build/generator/gen_make.py
> (write_transform_libtool_scripts,_get_all_lib_deps):
> New functions which generate transform_libtool_scripts.sh.
> (write): Call write_transform_libtool_scripts.
> * build/transform_libtool_scripts.sh
> Delete.
> ]]]
Re: [PATCH]: transform_libtool_scripts.py
Posted by Martin Furter <mf...@rola.ch>.
Here is version 2 of the patch.
On Tue, 14 Dec 2010, Philip Martin wrote:
> Martin Furter <mf...@rola.ch> writes:
>
>> The generated script then has to be included into the tarball. I
>> believe to remember that there's a script which creates the
>> tarball. Can anyone give me a pointer where I can find it?
>
> tools/dist/dist.sh
>
> The tarball is created after autogen.sh has been run; autogen.sh runs
> gen-make.py.
No changes seem to be needed there since it's run in the sandbox.
- Martin
[[[
Generate build/transform_libtool_scripts.sh from gen-make.py using
information read from build.conf.
* build/generator/gen_make.py
(write_transform_libtool_scripts,_get_all_lib_deps):
New functions which generate transform_libtool_scripts.sh.
(write): Call write_transform_libtool_scripts.
* build/transform_libtool_scripts.sh
Delete.
]]]
Re: [PATCH]: transform_libtool_scripts.py
Posted by Martin Furter <mf...@rola.ch>.
Here is version 2 of the patch.
On Tue, 14 Dec 2010, Philip Martin wrote:
> Martin Furter <mf...@rola.ch> writes:
>
>> The generated script then has to be included into the tarball. I
>> believe to remember that there's a script which creates the
>> tarball. Can anyone give me a pointer where I can find it?
>
> tools/dist/dist.sh
>
> The tarball is created after autogen.sh has been run; autogen.sh runs
> gen-make.py.
No changes seem to be needed there since it's run in the sandbox.
- Martin
[[[
Generate build/transform_libtool_scripts.sh from gen-make.py using
information read from build.conf.
* build/generator/gen_make.py
(write_transform_libtool_scripts,_get_all_lib_deps):
New functions which generate transform_libtool_scripts.sh.
(write): Call write_transform_libtool_scripts.
* build/transform_libtool_scripts.sh
Delete.
]]]
Re: [PATCH]: transform_libtool_scripts.py
Posted by Philip Martin <ph...@wandisco.com>.
Martin Furter <mf...@rola.ch> writes:
> The generated script then has to be included into the tarball. I
> believe to remember that there's a script which creates the
> tarball. Can anyone give me a pointer where I can find it?
tools/dist/dist.sh
The tarball is created after autogen.sh has been run; autogen.sh runs
gen-make.py.
--
Philip
Re: [PATCH]: transform_libtool_scripts.py
Posted by Martin Furter <mf...@rola.ch>.
On Tue, 14 Dec 2010, Stefan Sperling wrote:
> On Tue, Dec 14, 2010 at 06:12:54AM -0600, Peter Samuelson wrote:
>>
>> [Martin Furter]
>>> Configure has set SHELL=/bin/bash in Makefile. So this would solve
>>> one of the problems of that script.
>>
>> r1049057.
>>
>>> The other problem is that it does not read build.conf so always when
>>> anyone changes build.conf he has to remember that he may have update
>>> transform_libtool_scripts.sh depending on teh change he made. At the
>>> moment it doesn't process subversion/svnrdump/svnrdump here.
>>
>> Parsing build.conf from the shell wouldn't be impossible or even
>> necessarily difficult ... but you're right, it would still probably
>> make more sense to just generate the script from a template.
>
> Generating the script would be fine indeed.
OK, I'll look into that.
The generated script then has to be included into the tarball. I believe
to remember that there's a script which creates the tarball. Can anyone
give me a pointer where I can find it?
- Martin
Re: [PATCH]: transform_libtool_scripts.py
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Dec 14, 2010 at 06:12:54AM -0600, Peter Samuelson wrote:
>
> [Martin Furter]
> > Configure has set SHELL=/bin/bash in Makefile. So this would solve
> > one of the problems of that script.
>
> r1049057.
>
> > The other problem is that it does not read build.conf so always when
> > anyone changes build.conf he has to remember that he may have update
> > transform_libtool_scripts.sh depending on teh change he made. At the
> > moment it doesn't process subversion/svnrdump/svnrdump here.
>
> Parsing build.conf from the shell wouldn't be impossible or even
> necessarily difficult ... but you're right, it would still probably
> make more sense to just generate the script from a template.
Generating the script would be fine indeed.
Stefan
Re: [PATCH]: transform_libtool_scripts.py
Posted by Peter Samuelson <pe...@p12n.org>.
[Martin Furter]
> Configure has set SHELL=/bin/bash in Makefile. So this would solve
> one of the problems of that script.
r1049057.
> The other problem is that it does not read build.conf so always when
> anyone changes build.conf he has to remember that he may have update
> transform_libtool_scripts.sh depending on teh change he made. At the
> moment it doesn't process subversion/svnrdump/svnrdump here.
Parsing build.conf from the shell wouldn't be impossible or even
necessarily difficult ... but you're right, it would still probably
make more sense to just generate the script from a template.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Re: [PATCH]: transform_libtool_scripts.py
Posted by Martin Furter <mf...@rola.ch>.
On Tue, 14 Dec 2010, Peter Samuelson wrote:
>
> [Martin Furter]
>> I again fell over transform_libtool_scripts.sh on solaris.
>
> Would this patch help on Solaris? I believe autoconf goes to some
> effort to find a reasonable shell, in /usr/xpg4 or whatever.
>
> [[[
> * Makefile.in
> (transform-libtool-scripts): Run with $(SHELL) rather than /bin/sh,
> for systems like Solaris where /bin/sh is not a reasonable POSIX
> shell.
> ]]]
>
> --- Makefile.in
> +++ Makefile.in
> @@ -351,7 +351,7 @@
> local-all: @BUILD_RULES@ @TRANSFORM_LIBTOOL_SCRIPTS@
>
> transform-libtool-scripts: @BUILD_RULES@
> - @$(top_srcdir)/build/transform_libtool_scripts.sh
> + @$(SHELL) $(top_srcdir)/build/transform_libtool_scripts.sh
>
> locale-gnu-pot:
> cd $(abs_srcdir) && XGETTEXT="$(XGETTEXT)" MSGMERGE="$(MSGMERGE)" \
>
> Presumably the same patch could apply to other .sh scripts run from
> Makefile....
Configure has set SHELL=/bin/bash in Makefile. So this would solve one of
the problems of that script.
The other problem is that it does not read build.conf so always when
anyone changes build.conf he has to remember that he may have update
transform_libtool_scripts.sh depending on teh change he made. At the
moment it doesn't process subversion/svnrdump/svnrdump here.
Re: [PATCH]: transform_libtool_scripts.py
Posted by Peter Samuelson <pe...@p12n.org>.
[Martin Furter]
> I again fell over transform_libtool_scripts.sh on solaris.
Would this patch help on Solaris? I believe autoconf goes to some
effort to find a reasonable shell, in /usr/xpg4 or whatever.
[[[
* Makefile.in
(transform-libtool-scripts): Run with $(SHELL) rather than /bin/sh,
for systems like Solaris where /bin/sh is not a reasonable POSIX
shell.
]]]
--- Makefile.in
+++ Makefile.in
@@ -351,7 +351,7 @@
local-all: @BUILD_RULES@ @TRANSFORM_LIBTOOL_SCRIPTS@
transform-libtool-scripts: @BUILD_RULES@
- @$(top_srcdir)/build/transform_libtool_scripts.sh
+ @$(SHELL) $(top_srcdir)/build/transform_libtool_scripts.sh
locale-gnu-pot:
cd $(abs_srcdir) && XGETTEXT="$(XGETTEXT)" MSGMERGE="$(MSGMERGE)" \
Presumably the same patch could apply to other .sh scripts run from
Makefile....
Re: [PATCH]: transform_libtool_scripts.py
Posted by Martin Furter <mf...@rola.ch>.
On Tue, 14 Dec 2010, Stefan Sperling wrote:
> On Tue, Dec 14, 2010 at 11:09:34AM +0100, Martin Furter wrote:
>> Replace a disgusting shell script by nice python code.
>> transform_libtool_scripts.py is more portable and also reads build.conf.
>
> While python is required to create buidscripts for a subversion distribution
> tarball, we do not require python for compiling the tarball.
> Because transform_libtool_scripts is run during 'make' your patch isn't
> going to work.
>
> Can you try to fix the .sh script instead?
Trying to read and parse build.conf from a shell script doesn't sound sane
to me and it would make transform_libtool_scripts.sh even less
maintainable.
What about generating transform_libtool_scripts.sh from gen_make.py ?
Re: [PATCH]: transform_libtool_scripts.py
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Dec 14, 2010 at 11:09:34AM +0100, Martin Furter wrote:
> Replace a disgusting shell script by nice python code.
> transform_libtool_scripts.py is more portable and also reads build.conf.
While python is required to create buidscripts for a subversion distribution
tarball, we do not require python for compiling the tarball.
Because transform_libtool_scripts is run during 'make' your patch isn't
going to work.
Can you try to fix the .sh script instead?
Stefan
Re: Disable transform_libtool_scripts.py by default?
Posted by Arfrever Frehtes Taifersar Arahesis <ar...@gmail.com>.
2010-12-22 15:57:02 Philip Martin napisał(a):
> Philip Martin <ph...@wandisco.com> writes:
>
> > I'd like to disable libtool transformation by default, i.e. make
> > --disable-local-library-preloading the default. The script messes with
> > the internals of libtool and so runs the risk of breaking the build,
> > particularly on less common platforms.
>
> I've made this change in r1051931. Another effect of the libtool
> transformation script, on my Linux machine at least, is that it causes
> the install process to install the binaries as libtool scripts rather
> than directly as ELF executables.
I have fixed this regression in r1087779.
--
Arfrever Frehtes Taifersar Arahesis
Re: Disable transform_libtool_scripts.py by default?
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> I'd like to disable libtool transformation by default, i.e. make
> --disable-local-library-preloading the default. The script messes with
> the internals of libtool and so runs the risk of breaking the build,
> particularly on less common platforms.
I've made this change in r1051931. Another effect of the libtool
transformation script, on my Linux machine at least, is that it causes
the install process to install the binaries as libtool scripts rather
than directly as ELF executables.
--
Philip
Re: Disable transform_libtool_scripts.py by default?
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Fri, Dec 17, 2010 at 4:11 AM, Philip Martin
<ph...@wandisco.com> wrote:
> Martin Furter <mf...@rola.ch> writes:
>
>> I again fell over transform_libtool_scripts.sh on solaris.
>
> Can you tell me what went wrong?
>
> As far as I know the libtool transformation is only needed for one
> thing: to run the executables from within the build directory when using
> the apr_dso_load modules i.e. the option --enable-runtime-module-search
> or the kwallet/gnome-keyring stuff. For a simple build/test/install it
> should not be necessary.
>
> I'd like to disable libtool transformation by default, i.e. make
> --disable-local-library-preloading the default. The script messes with
> the internals of libtool and so runs the risk of breaking the build,
> particularly on less common platforms.
+1
I've found that it chokes on C++ binaries on the object-model branch.
-Hyrum
Re: Disable transform_libtool_scripts.py by default?
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Dec 17, 2010 at 10:11:07AM +0000, Philip Martin wrote:
> I'd like to disable libtool transformation by default, i.e. make
> --disable-local-library-preloading the default. The script messes with
> the internals of libtool and so runs the risk of breaking the build,
> particularly on less common platforms.
+1
If it's not needed by everybody, those who need it should explicitly
enable it.
Disable transform_libtool_scripts.py by default?
Posted by Philip Martin <ph...@wandisco.com>.
Martin Furter <mf...@rola.ch> writes:
> I again fell over transform_libtool_scripts.sh on solaris.
Can you tell me what went wrong?
As far as I know the libtool transformation is only needed for one
thing: to run the executables from within the build directory when using
the apr_dso_load modules i.e. the option --enable-runtime-module-search
or the kwallet/gnome-keyring stuff. For a simple build/test/install it
should not be necessary.
I'd like to disable libtool transformation by default, i.e. make
--disable-local-library-preloading the default. The script messes with
the internals of libtool and so runs the risk of breaking the build,
particularly on less common platforms.
--
Philip