elisp files

[Ralf Wildenhues]

Hello,

forgive my ignorance on the subject: what are the (desired) semantics of
elisp files?

Currently, you trip over Automake bugs when you use lisp files in
subdirs (with or without subdir-objects):
  lisp_LISP = sub/am.el

or use nobase_:
  nobase_lisp_LISP = sub/am.el

Elias reported part of this to bug-automake in
.

Now my questions:

- is the elisp installation tree hierarchical, in that it is useful to
  have nobase_ support as above (where the files would be installed to
  $(lispdir)/sub/am.el and $(lispdir)/sub/am.elc)?

- with the first line above, should the .elc file be compiled in sub or
  in the toplevel, and should the answer to this question depend on
  whether subdir-objects are used or not?

- assuming elisp compilation generally needs to see all files in a
  directory (gathering from the elisp-comp script), do you think that
  when listing lisp files from subdirectories in lisp_LISP, would it be
  useful to assume they are independently compilable, or interdependent?

- if interdependent, is there a way I can get emacs (and any other tool
  that may serve as lisp compiler) to output .elc files in
  subdirectories?

Thanks,
Ralf

Re: silent-rules

[Ralf Corsepius]

On 10/06/2009 09:52 PM, Ralf Wildenhues wrote:

[ adding automake@ ]

Hello Ralf,

* Ralf Corsepius wrote on Tue, Oct 06, 2009 at 05:49:52PM CEST:

a) AM_SILENT_RULES are harmful (I know, you know that I think about
this (mal-) "feature" this way - Working around the issues they are
causing in Fedora packaging is a major nuissance.)


Could you expand on this nuisance a bit more?

I did so several times before.

Anyway, ...

The problem is verifying "correctness of building" packages in batches.

i.e. to monitor/inspect CFLAGS, CPPFLAGS, LDFLAGS etc. in compiler calls 
etc. for correctness


(NB: A package, which compiles without warning doesn't mean it is being 
built correctly.)



What work does it cause except for using --disable-silent-rules at
configure time or V=1 at make time?

Exactly this is the problem.

It means automake is pushing around package maintainers to modify their 
packages to automake's behavioral changes.


As many package maintainers are no autotools' specialists, this is a 
non-trivial problem.


Ralf

Re: Difficulty cross-compiling

[Ralf Corsepius]

On 10/12/2009 08:26 PM, William Tracy (wtracy) wrote:

Hello,



I'm trying to cross-compile a library that uses GNU Autotools (Google
Coredumper, to be specific) for PPC using the MontaVista tool chain. The
sequence of commands I'm following is:



$ ./configure --host=ppc CC=/path/to/gcc CXX=/path/to/g++


Normally, a cross-toolchain's tools are called -

i.e.
* one normally doesn't have to set CC nor CXX.

* the value being passed to --host is the tool prefix and therefore must 
match the tool-prefix being used by your toolchain.


Ralf

RE: Difficulty cross-compiling

[William Tracy (wtracy)]

This is a semi-embedded Linux system that I am trying to build for.

MontaVista is a Linux distribution that also provides a cross-compiling
toolchain--their own builds of the GNU toolchain, really. Their build
follows their own interesting naming convention, which isn't making this
simpler. >_<

Thanks for the reply, though.

---
William Tracy

-Original Message-
From: John Calcote [mailto:john.calc...@gmail.com] 
Sent: Monday, October 12, 2009 12:00 PM
To: William Tracy (wtracy)
Cc: automake@gnu.org
Subject: Re: Difficulty cross-compiling

You don't state your target OS, only the CPU architecture, and I'm not 
familiar with MontaVista, so I'm not sure I'm helping here. But if your 
target platform is AIX, or anything like it, you may be experiencing 
AIX-library-naming-difference syndrome - a sense of disorientation 
associated with not being able to find your AIX shared libraries after 
building. ;-)

The default library extension for some versions of AIX is .a. These .a 
files contain the equivalent of standard Unix static /and dynamic/ 
libraries. Thus, on AIX/PPC, .a files are dynamically loaded just like 
.so files on Solaris or Linux. The .a files also contain the static 
objects linked into a binary when static linking is requested.

Regards,
John

Re: Difficulty cross-compiling

[John Calcote]

Hi William,

On 10/12/2009 12:26 PM, William Tracy (wtracy) wrote:

I'm trying to cross-compile a library that uses GNU Autotools (Google
Coredumper, to be specific) for PPC using the MontaVista tool chain. The
sequence of commands I'm following is:

$ ./configure --host=ppc CC=/path/to/gcc CXX=/path/to/g++

$ make

$ [next step would normally be "make install"]

For a normal (not cross-compile) configuration, issuing "make" causes a
.libs/ directory to be generating containing .a, .o, and .so files (and
variants thereof). When I cross-compile for PPC, the directory is
created and populated with a .a file, but no .so files. I can see .o and
.lo files being generated, so the code *is* getting compiled, but the
linking stage gets skipped. When I review the make output, there are no
error messages or warnings-the commands related to the .so files are
simply missing.
   


You don't state your target OS, only the CPU architecture, and I'm not 
familiar with MontaVista, so I'm not sure I'm helping here. But if your 
target platform is AIX, or anything like it, you may be experiencing 
AIX-library-naming-difference syndrome - a sense of disorientation 
associated with not being able to find your AIX shared libraries after 
building. ;-)


The default library extension for some versions of AIX is .a. These .a 
files contain the equivalent of standard Unix static /and dynamic/ 
libraries. Thus, on AIX/PPC, .a files are dynamically loaded just like 
.so files on Solaris or Linux. The .a files also contain the static 
objects linked into a binary when static linking is requested.


Regards,
John

Difficulty cross-compiling

[William Tracy (wtracy)]

Hello,

 

I'm trying to cross-compile a library that uses GNU Autotools (Google
Coredumper, to be specific) for PPC using the MontaVista tool chain. The
sequence of commands I'm following is:

 

$ ./configure --host=ppc CC=/path/to/gcc CXX=/path/to/g++ 

$ make 

$ [next step would normally be "make install"]

 

For a normal (not cross-compile) configuration, issuing "make" causes a
.libs/ directory to be generating containing .a, .o, and .so files (and
variants thereof). When I cross-compile for PPC, the directory is
created and populated with a .a file, but no .so files. I can see .o and
.lo files being generated, so the code *is* getting compiled, but the
linking stage gets skipped. When I review the make output, there are no
error messages or warnings-the commands related to the .so files are
simply missing.

 

I've tried additionally manually specifying paths for the other
components of the GNU toolchain (linker, assembler, etc.) and, at the
suggestion of the people on the CLFS mailer, I've tried running
./configure with -enable-shared="yes" -enable-static="no". None of these
suggestions have helped.

 

*Summary*: When I try to cross-compile, make mysteriously and silently
skips one or more parts of the build. (If I build for the same
architecture, it works fine.)

 

I've tried diff-ing the Makefiles generated by ./configure for the
different architectures, and they look the same (other than the paths to
the compiler executables being different). I've also tried grepping the
Makefiles for the relevant commands that I see in the output; I get no
matches in either Makefile, so Autotools is doing something arcane here.

 

Any input would be appreciated.

 

---

William Tracy