Re: Broken system web pages - ideas?

2003-09-23 Thread L. D. Marks
Let me expand slightly on my concept, by giving three (trivial?) suggestions for what could be included: a) Check that gcc, g++ and g77 are all the same version. b) At least for Linux, check that /etc/ld.so.conf contains /usr/local/lib, then run /sbin/ldconfig -v and check that there are not any b

Re: Broken system web pages - ideas?

2003-09-23 Thread Kevin Ryde
"L. D. Marks" <[EMAIL PROTECTED]> writes: > > 2) Duplicate, and inconsistent gcc/g++/g77 compilers The c++ compiler for some reason always seems a good candidate for breakage on systems I see. I think bad installations are outside the scope of autoconf, but you can always have configure che

Re: Broken system web pages - ideas?

2003-09-23 Thread Dr. David Kirkby
"L. D. Marks" wrote: > > While testing a package on a number of systems, it > has become clear to me that they are often "broken" > in non-obvious ways. As just two examples that I > have come across: > 1) Users not having permissions to shared libraries > 2) Duplicate, and inconsi

Re: Copying vs m4_including macro files

2003-09-23 Thread Alexandre Duret-Lutz
On Mon, Sep 22, 2003 at 06:12:50PM +0100, Gary V. Vaughan wrote: [...] > I was hoping to remove acinclude.m4 and use m4_include in aclocal.m4 by > switching to CVS automake, but currently the contents are still copied to > aclocal.m4 if they are not in the same directory as configure.ac. Wherever

Broken system web pages - ideas?

2003-09-23 Thread L. D. Marks
While testing a package on a number of systems, it has become clear to me that they are often "broken" in non-obvious ways. As just two examples that I have come across: 1) Users not having permissions to shared libraries 2) Duplicate, and inconsistent gcc/g++/g77 compilers Has any

LDADD problem on Redhat 8.0 (automake 1.6.3)

2003-09-23 Thread Randall Hopper
Is this Makefile.am source valid? LDADD = ../dira/liba.la ../dirb/libb.la if WITH_MY_FEATURE else LDADD += ../dirc/libc.la endif A Makefile.am in our project that contains the above works fine on automake 1.7.2-32 (SuSE 8.2) but generates an invalid Makefile on automake 1.6.3 (Redhat 8

LDADD problem on Redhat 8.0 (automake 1.6.3)

2003-09-23 Thread Leonard mckinley
A Makefile.am in our project that contains the following works fine on automake 1.7.2-32 (SuSE 8.2) but generates an invalid Makefile on automake 1.6.3 (Redhat 8.0). The Makefile has a bunch of uncommented @TRUE@ lines followed by commented out lib names, right before LDADD which is empty. First,

Copying vs m4_including macro files

2003-09-23 Thread Gary V. Vaughan
Gentle Reader: I want to minimise duplication of macros among directories in CVS libtool. Libtool-1.5 was released with libtool.m4 and ltdl.m4, but due to idiosyncracies in the build process, these files were copied to acinclude.m4 in no less than 10 directories. Running aclocal then copied the

RE: Compiling 32-bit code on 64-bit HP-UX

2003-09-23 Thread Boehne, Robert
Martin, Even on a 64-bit capable machine, aCC defaults to 32-bit libraries. Having config.guess return hppa2.0w does not change the output that is produced, aCC will produce whatever you tell it to (32-bit by default). When you're running a configure script you want to set both (for C) CPPFLAGS a

Compiling 32-bit code on 64-bit HP-UX

2003-09-23 Thread Martin Frydl
Hello, I'm trying to create 32-bit shared libraries on 64-bit PA-RISC 2.0 (HP-UX 11) with aCC compiler. I have several libraries and executables in my project. When I run them from build directory, everything works fine. However, when I run make install and delete build directory, the execut

Automake 1.7.7 released

2003-09-23 Thread Alexandre Duret-Lutz
We're pleased to announce the release of Automake 1.7.7. This is a bug fix release. The list of bug fixes is appended. You can find the new release here: ftp://sources.redhat.com/pub/automake/automake-1.7.7.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.7.7.tar.gz within a fe

Re: Compiling 32-bit code on 64-bit HP-UX

2003-09-23 Thread Kevin Ryde
Martin Frydl <[EMAIL PROTECTED]> writes: > > - config.guess does not use CFLAGS when making compilation checks but > this can be "fixed" by providing necessary flags directly in CC > variable I think the cpu type guessed is supposed to depend only on the system, not on an intended compiler mode.