tags 10878 patch
close 10878
thanks
On 02/25/2012 08:25 PM, Stefano Lattarini wrote:
I'll close this report by tomorrow if there are no further objection.
Bug closed.
Thanks,
Stefano
On Feb 26, 2012, Stefano Lattarini stefano.lattar...@gmail.com wrote:
Hi! Thanks for the report, and sorry for the delay.
Let's try to tackle these issues one by one ...
ERROR: self-check-cleanup
=
...
find: dummy.dir: Permission denied
rm: dummy.dir: Permission
tags 10889 notabug
close 10889
thanks
Hi Lou, thanks for the report.
On 02/26/2012 04:05 PM, Lou Picciano wrote:
Build is on OpenIndiana 151a2 (illumos/née OpenSolaris)
Some output of a recent build of automake-1.10 - it requested
I send it to you!
Automake 1.10 is five years old, no longer
On 02/27/2012 03:38 AM, P. Martin wrote:
$ mkdir a a/b
$ chmod 000 a/b
Oops, my bad. I meant this:
$ mkdir a a/b
$ chmod 000 a
$ find a -type d ! -perm -700 -exec chmod u+rwx '{}' \;
$ echo exit status: $?
Sorry for the confusion and for the time I've made you waste, and thanks
for
On 02/26/2012 10:02 AM, Stefano Lattarini wrote:
- many other projects (linux, git itself) seems to use them, and I
believe there's a reason for this (even if I've failed to find it
so far);
Here it is -- point 12 at:
tags 10878 patch
close 10878
thanks
On 02/25/2012 08:25 PM, Stefano Lattarini wrote:
I'll close this report by tomorrow if there are no further objection.
Bug closed.
Thanks,
Stefano
Stefano Lattarini wrote:
On 02/26/2012 10:02 AM, Stefano Lattarini wrote:
- many other projects (linux, git itself) seems to use them, and I
believe there's a reason for this (even if I've failed to find it
so far);
Here it is -- point 12 at:
On 02/22/2012 10:30 AM, Stefano Lattarini wrote:
On 02/22/2012 10:25 AM, Tim Retout wrote:
Adding a README file will cause us problems if automake-1.11 and
automake-1.12 (say) are installed on the same system - who owns the
README?
Good point. Let's just drop my patch for now.
But the
Some versions of the BSD Korn shell wrongly bail out when the
'errexit' shell flag is active and the left-hand command in a
list fails and that list is the *last* command of an entry
in a case statement.
* tests/defs (gcc, g++, gcj): Work around that.
---
tests/defs |3 +++
1 files changed,
* tests/Makefile.am (do_subst): Also substitute '@AWK@'.
* tests/defs-static.in ($AWK): New, user-overridable and defaulting
to the substituted '@AWK@'.
* tests/defs (fetch_tap_driver): When the shell+awk implementation
of the TAP driver is required, export AM_TAP_AWK to point to a
properly
* tests/parallel-tests-many.test: Use perl, not awk, to write the
Makefile.am with (deliberately) overly long TESTS content, as some
inferior awk implementations (e.g., Solaris 10 /usr/bin/awk) are
unable to handle the long lines used there and die with errors like:
awk: string too long near line
Eric Blake skrev 2012-02-23 23:42:
On 02/23/2012 02:48 PM, Stefano Lattarini wrote:
* lib/Makefile.am (installcheck-local): To verify that the installed
scripts are actually executable, simply use 'test -x', instead of
resorting to perl and its '-x' file operator. Today, 'test -x'
should
I thought that as long as one used .la libraries, automake+libtool
was supposed to handle all the grotty stuff like rpath automatically,
adding -rpath $(libdir) if you depend on libraries installed to libdir
and libdir isn't on the system library search path. [Yeah, I also
know some people hate
On 02/26/2012 03:47 PM, Miles Bader wrote:
I thought that as long as one used .la libraries, automake+libtool
was supposed to handle all the grotty stuff like rpath automatically,
adding -rpath $(libdir) if you depend on libraries installed to libdir
and libdir isn't on the system library
2012年2月27日0:58 Peter Johansson troj...@gmail.com:
On which system do you experience this? I've seen this problem on
Fedora and the problem was that the linker search path and the dynamic
loader search path were different. IIUC libtool sets -rpath if a used library
is outside linker path.
On 2/26/12 11:31 PM, Miles Bader wrote:
I think it's desirable that it just work wherever it gets installed,
and no matter who installs it (e.g. prefix=$HOME should work, and
shouldn't require setting LD_LIBRARY_PATH).
In my case it did work with prefix=$HOME because in that case -rpath was
Hello, all. In GRUB2 we have following problem: If
program_transform_name=s,grub,grub2 then
pkglibdir=$libdir/grub2 but pkgdatadir=$datadir/grub2
Is it intended or is it a bug? Is it likely to change in future versions?
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
2012年2月27日1:46 Peter Johansson troj...@gmail.com:
I think it's desirable that it just work wherever it gets installed,
and no matter who installs it (e.g. prefix=$HOME should work, and
shouldn't require setting LD_LIBRARY_PATH).
In my case it did work with prefix=$HOME because in that case
2012年2月27日9:41 Bob Friesenhahn bfrie...@simple.dallas.tx.us:
Just using the command: sudo ldconfig
after installing my package makes everything work!
This is a function that libtool normally performs if it is used properly.
I did: sudo make install
Is that not using it properly?
-miles
Miles Bader mi...@gnu.org writes:
2012年2月27日9:41 Bob Friesenhahn bfrie...@simple.dallas.tx.us:
This is a function that libtool normally performs if it is used properly.
I did: sudo make install
Is that not using it properly?
Something needs to run libtool --mode=finish. I thought
2012年2月27日16:21 Russ Allbery r...@stanford.edu:
This is a function that libtool normally performs if it is used properly.
I did: sudo make install
Something needs to run libtool --mode=finish. I thought Automake normally
arranged to run that at the end of make install. Is that not
21 matches
Mail list logo
