EXTRA_DIST and external or outside directories
Is there a way to include a directory which is external or outside of the $(top_srcdir) and which is not involved in the build process? I tried putting the following in my Makefile.am: EXTRA_DIST = $(top_srcdir)/../../perl $(top_srcdir)/../../java But, when I do a 'make dist' it does not attempt to include either of these directories in my tarball. Is this because it ignores anything outside of the toplevel source directory? Is there a work around? Thanks, John Ling
Re: fortran FC patch
Greetings, In http://www.mail-archive.com/[EMAIL PROTECTED]/msg07811.html, Michael Nolta offered a simple patch for `fc' support, and Alexandre's reply suggested that there was unlikely to be a problem including this. This appears not to be in the current CVS sources (on the head, after cvs -z 9 -d :pserver:[EMAIL PROTECTED]:/cvs/automake co automake). Ought I to be surprised? Am I looking in the right place? I ask because I'm working just now on adding support to both autoconf and automake to support preprocessing of Fortran 77, and it makes most sense if I do so on top of the `fc' support rather than the older `f77' support. The preprocessing support is not mine, but Martin Wilck's (see [1]). He submitted patches for this in 2000, but for some reason or another they never made it into the autoconf or automake sources. I'm just adding them now, adjusting them so they're compatible with the current autoconf and automake versions. Given that there isn't a problem with Michael's patches, and given that I don't _really_ want to muck about with the CVS head, would it be reasonable for me to apply Michael's patches to a local copy of automake 1.8.2 and submit the joint patch at some later stage when I've got everything working? No-one _else_ is working on this, are they? All the best, Norman [1] http://sources.redhat.com/ml/autoconf-patches/2000-07/msg00287.html http://sources.redhat.com/ml/automake/2000-07/msg00043.html -- --- Norman Grayhttp://www.astro.gla.ac.uk/users/norman/ Physics and Astronomy, University of Glasgow, UK [EMAIL PROTECTED]
Re: utility programs used during build
Ralf == Ralf Corsepius [EMAIL PROTECTED] writes: If you want a clean way, you'd have to split buildtools and host-packages into separate (sub) packages and write a costomized toplevel configure-script to parse and set the configure options for build- and host- compile packages. Ralf This is the current nominal working principle, as it is applied by Ralf packages which actually support cross-compilation (gcc, newlib, Ralf binutils, gdb etc.). Hmm, I think we're mixing scenarios. In gcc, for instance, ordinarily target libraries are put in their own directories with their own configuration. And there is also a surrounding layer of hackery to deal with multilibs. But that isn't what Warren is talking about. He's talking about a situation where you want to build your package for a different host, but first build some helper programs on the build machine to create other parts of your program. E.g., in gcc there are the gen* family of programs, like genattrtab. These are just incorporated in the gcc source directory along with files that will be compiled for the host machine, not the build machine. My opinion on this is that total separation is easier to implement, but not really cleaner. Clean depends on the needs of the package at hand, sometimes you'd really rather just lump all the sources together. Alexandre's simple solution of overriding _CC and the like is nice. I think at least one part of this must be handled automatically, and that is the selection of EXEEXT, which can differ between build and host. And really my preference would be to have it all done automatically, since that is easier for the user and less error-prone... still, it looks like the same internal mechanisms are necessary to support build compilers and per-target compilers. Anyway, it looks like there's a big job ahead for Warren :-). Tom
Solaris and socket library
I am running on Solaris and I was trying to compile an application that used the libmysqlclient.a library. I encountered an error: Undefined first referenced symbol in file socket /usr/local/mysql4/lib/libmysqlclient.a(libmysql.o) getpeername /usr/local/mysql4/lib/libmysqlclient.a(viosocket.o) setsockopt /usr/local/mysql4/lib/libmysqlclient.a(viosocket.o) getservbyname /usr/local/mysql4/lib/libmysqlclient.a(libmysql.o) getsockopt /usr/local/mysql4/lib/libmysqlclient.a(libmysql.o) shutdown /usr/local/mysql4/lib/libmysqlclient.a(viosocket.o) connect /usr/local/mysql4/lib/libmysqlclient.a(libmysql.o) ld: fatal: Symbol referencing errors. Now the solution was to add a -lsocket to the linking options. But, should this not be something that autoconf or automake suite of tools detect and automatically handle for me? Do I need to manually add this only when I run on Solaris? Now that I do need to handle this. Where is the best place to check the OS environment variable to see if I need to set this as a variable somewhere. I wanted to do something like: ifeq ($(OSTYPE),solaris) export SOCKET = -lsocket endif Do I do this in configure.in somehow or in Makefile.am? Is there a better way anyone can suggest. I would think something like this is a common problem to handle. Thanks, John Ling
Re: Solaris and socket library
Thank you Bob for that very useful bit of knowledge. John Ling - Original Message - From: Bob Friesenhahn [EMAIL PROTECTED] Date: Friday, January 16, 2004 5:14 pm Subject: Re: Solaris and socket library This is an Autoconf issue, not Automake. Adding the following line to your configure.ac file will likely resolve the problem: AC_SEARCH_LIBS([connect],[socket],[],[],[]) It should add -lsocket to LIBS if necessary. Bob On Fri, 16 Jan 2004, John Ling wrote: I am running on Solaris and I was trying to compile an application that used the libmysqlclient.a library. I encountered an error: Undefined first referenced symbol in file socket /usr/local/mysql4/lib/libmysqlclient.a(libmysql.o) getpeername /usr/local/mysql4/lib/libmysqlclient.a(viosocket.o) setsockopt /usr/local/mysql4/lib/libmysqlclient.a(viosocket.o) getservbyname /usr/local/mysql4/lib/libmysqlclient.a(libmysql.o) getsockopt /usr/local/mysql4/lib/libmysqlclient.a(libmysql.o) shutdown /usr/local/mysql4/lib/libmysqlclient.a(viosocket.o) connect /usr/local/mysql4/lib/libmysqlclient.a(libmysql.o) ld: fatal: Symbol referencing errors. Now the solution was to add a -lsocket to the linking options. But, should this not be something that autoconf or automake suite of tools detect and automatically handle for me? Do I need to manually add this only when I run on Solaris? Now that I do need to handle this. Where is the best place to check the OS environment variable to see if I need to set this as a variable somewhere. I wanted to do something like: ifeq ($(OSTYPE),solaris) export SOCKET = -lsocket endif Do I do this in configure.in somehow or in Makefile.am? Is there a better way anyone can suggest. I would think something like this is a common problem to handle. Thanks, John Ling == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
