mirror of
https://git.lyx.org/repos/lyx.git
synced 2024-11-25 02:49:46 +00:00
Fix depcomp and update INSTALL for Tru64.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@3812 a592a061-630c-0410-9148-cb99ea01b6c8
This commit is contained in:
parent
607b4687a0
commit
39787a2e07
@ -1,3 +1,7 @@
|
||||
2002-03-22 Angus Leeming <a.leeming@ic.ac.uk>
|
||||
|
||||
* INSTALL: updated the Problems section for Tru64 Unix.
|
||||
|
||||
2002-03-20 Lars Gullik Bjønnes <larsbj@birdstep.com>
|
||||
|
||||
* Makefile.am (DISTCLEANFILES): be recursive here
|
||||
|
21
INSTALL
21
INSTALL
@ -342,16 +342,37 @@ notify us.
|
||||
repository, due to the tricks used by automake for dependencies. Ask
|
||||
Jean-Marc.Lasgouttes@inria.fr for a workaround.
|
||||
|
||||
Or rather, it may well work if you are using automake 1.5 and autoconf 2.5
|
||||
or greater, but you'll have to patch automake's depcomp first. (Depcomp
|
||||
is a little shell script to automagically work out file dependencies
|
||||
and it's broken for automake 1.5 and Tru64 :-(). The patch is to be found
|
||||
in config/depcomp.diff.
|
||||
Angus 22 March, 2002.
|
||||
|
||||
o On Tru64 Unix, you may have to compile with
|
||||
--with-included-string to work around a Tru64 linker limitation
|
||||
(the STL string template creates names which may be too long). We
|
||||
also had reports that it helps with gcc 2.95.2 on solaris 2.6.
|
||||
|
||||
Using Tru64 Unix 4.0e, the std::string is fine.
|
||||
Angus 22 March, 2002.
|
||||
|
||||
o On Tru64 Unix with cxx, you may have a compilation error in
|
||||
lyx_main.C if you have GNU gettext installed. This is due to a bug
|
||||
in gettext. To solve this, you can either (1) configure with
|
||||
--with-included-gettext or (2) add -D__STDC__ to cxx flags.
|
||||
|
||||
o On Tru64 Unix 4.0e, the STL library routine std::count is broken
|
||||
(/usr/include/cxx/algorithm.cc, line 289 on my machine).
|
||||
It calculates "n" but does not return it! The fix is to add "return n;" to
|
||||
the end of the (4-line long) routine.
|
||||
Angus 22 March, 2002.
|
||||
|
||||
o On Tru64 Unix 4.0e, compilation of support/lyxsum.C dies horribly. The
|
||||
work-around is to use the old version, 1.18, of this routine. Ask
|
||||
Angus Leeming <leeming@lyx.org> for details.
|
||||
Angus 22 March, 2002.
|
||||
|
||||
o According to John Collins <collins@phys.psu.edu>, on SunOS 4.1.3 you may
|
||||
find two sets of X libraries, and they are of course incompatible :-)
|
||||
One is the set provided as part of OpenWindows, and one is the standard
|
||||
|
@ -1,3 +1,9 @@
|
||||
2002-03-21 Angus Leeming <a.leeming@ic.ac.uk>
|
||||
|
||||
* depcomp: fixed bug in dependency tracking for Tru64 Unix.
|
||||
|
||||
* depcomp.diff: the patch is added to the repository, as Lars wishes...
|
||||
|
||||
2002-03-21 Lars Gullik Bjønnes <larsbj@birdstep.com>
|
||||
|
||||
* lyxinclude.m4 (LYX_CHECK_LDR): deleted; to complex does not give us anything.
|
||||
|
@ -198,14 +198,28 @@ aix)
|
||||
;;
|
||||
|
||||
tru64)
|
||||
# The Tru64 AIX compiler uses -MD to generate dependencies as a side
|
||||
# The Tru64 DEC compiler uses -MD to generate dependencies as a side
|
||||
# effect. `cc -MD -o foo.o ...' puts the dependencies into `foo.o.d'.
|
||||
# At least on Alpha/Redhat 6.1, Compaq CCC V6.2-504 seems to put
|
||||
# dependencies in `foo.d' instead, so we check for that too.
|
||||
# Subdirectories are respected.
|
||||
|
||||
tmpdepfile1="$object.d"
|
||||
tmpdepfile2=`echo "$object" | sed -e 's/.o$/.d/'`
|
||||
# This is incorrect as it assumes that $object has a .o extension when
|
||||
# it could well have a .lo one.
|
||||
#tmpdepfile1="$object.d"
|
||||
# This is just bad sed. The /.o$/ should be /\.o/, nonwithstanding the
|
||||
# flawed logic, described above.
|
||||
#tmpdepfile2=`echo "$object" | sed -e 's/.o$/.d/'`
|
||||
|
||||
# The correct way:
|
||||
# Strip the (.o, or .lo) extension from $object
|
||||
# (Same piece of sed magic as used for the AIX compiler above.)
|
||||
stripped=`echo "$object" | sed -e 's,^.*/,,' -e 's/\(.*\)\..*$/\1/'`
|
||||
# Tru64 compiler dependency file.
|
||||
tmpdepfile1="$stripped.o.d"
|
||||
# Compaq CCC V6.2 dependency file.
|
||||
tmpdepfile2="$stripped.d"
|
||||
|
||||
if test "$libtool" = yes; then
|
||||
"$@" -Wc,-MD
|
||||
else
|
||||
|
39
config/depcomp.diff
Normal file
39
config/depcomp.diff
Normal file
@ -0,0 +1,39 @@
|
||||
Index: depcomp
|
||||
===================================================================
|
||||
RCS file: /usr/local/lyx/cvsroot/lyx-devel/config/depcomp,v
|
||||
retrieving revision 1.1
|
||||
diff -u -p -r1.1 depcomp
|
||||
--- depcomp 17 Oct 2001 15:38:58 -0000 1.1
|
||||
+++ depcomp 22 Mar 2002 12:18:23 -0000
|
||||
@@ -198,14 +198,28 @@ aix)
|
||||
;;
|
||||
|
||||
tru64)
|
||||
- # The Tru64 AIX compiler uses -MD to generate dependencies as a side
|
||||
+ # The Tru64 DEC compiler uses -MD to generate dependencies as a side
|
||||
# effect. `cc -MD -o foo.o ...' puts the dependencies into `foo.o.d'.
|
||||
# At least on Alpha/Redhat 6.1, Compaq CCC V6.2-504 seems to put
|
||||
# dependencies in `foo.d' instead, so we check for that too.
|
||||
# Subdirectories are respected.
|
||||
|
||||
- tmpdepfile1="$object.d"
|
||||
- tmpdepfile2=`echo "$object" | sed -e 's/.o$/.d/'`
|
||||
+ # This is incorrect as it assumes that $object has a .o extension when
|
||||
+ # it could well have a .lo one.
|
||||
+ #tmpdepfile1="$object.d"
|
||||
+ # This is just bad sed. The /.o$/ should be /\.o/, nonwithstanding the
|
||||
+ # flawed logic, described above.
|
||||
+ #tmpdepfile2=`echo "$object" | sed -e 's/.o$/.d/'`
|
||||
+
|
||||
+ # The correct way:
|
||||
+ # Strip the (.o, or .lo) extension from $object
|
||||
+ # (Same piece of sed magic as used for the AIX compiler above.)
|
||||
+ stripped=`echo "$object" | sed -e 's,^.*/,,' -e 's/\(.*\)\..*$/\1/'`
|
||||
+ # Tru64 compiler dependency file.
|
||||
+ tmpdepfile1="$stripped.o.d"
|
||||
+ # Compaq CCC V6.2 dependency file.
|
||||
+ tmpdepfile2="$stripped.d"
|
||||
+
|
||||
if test "$libtool" = yes; then
|
||||
"$@" -Wc,-MD
|
||||
else
|
Loading…
Reference in New Issue
Block a user