Re: problem --enable-shared and --enable-static together
Am Samstag 05 Dezember 2009 13:33:06 schrieb Ralf Wildenhues: Hello Andreas, besides answers already given: * Andreas Otto wrote on Fri, Dec 04, 2009 at 09:41:16AM CET: as you see both *lo and *.o are created. the *.o are useless and just extend the compiling time Q: what can I do to avoid build static libraries ... foo_LIBTOOLFLAGS = -tag=disable-static Q: what is foo? I try tclmsgque_LIBTOOLFLAGS - no change I look into the Makefile and get ... tclmsgque_la-context_tcl.lo: context_tcl.c $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $ (CPPFLAGS) $(tclmsgque_la_CFLAGS) $(CFLAGS) -MT tclmsgque_la-context_tcl.lo - MD -MP -MF $(DEPDIR)/tclmsgque_la-context_tcl.Tpo -c -o tclmsgq ue_la-context_tcl.lo `test -f 'context_tcl.c' || echo '$(srcdir)/'`context_tcl.c ... as you see only $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) are used -I'm confused the info page speek about ... If `LIBRARY_LIBTOOLFLAGS' is not defined, the global `AM_LIBTOOLFLAGS' variable is used instead. ... about LIBRARY_LIBTOOLFLAGS well even the LIBRARY prefix does not work -I'm more confused than I try AM_LIBTOOLFLAGS and get the following error... /bin/sh ../../libtool --tag=CC -tag=disable-static --mode=compile ccache gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -D_DEBUG -I./../libmsgque - I/home/dev1usr/ext/x86_64-suse-linux/thread/include -DUSE_TCL_STUBS - DMQ_IGNORE_EXTERN -g -O3 -Wall -Wcast-align -Wstrict-prototypes - fvisibility=hidden -g -O2 -pthread -MT tclmsgque_la-context_tcl.lo -MD -MP -MF .deps/tclmsgque_la-context_tcl.Tpo -c -o tclmsgque_la-context_tcl.lo `test -f 'context_tcl.c' || echo './'`context_tcl.c libtool: unrecognized option `-tag=disable-static' libtool: Try `libtool --help' for more information. make: *** [tclmsgque_la-context_tcl.lo] Fehler 1 after a look inti the info page I change -tag to --tag .. next try now it works ... summary: change: foo_LIBTOOLFLAGS = -tag=disable-static into AM_LIBTOOLFLAGS = --tag=disable-static than it is fine for a target 'foo'. I use ../libmsgque/*.lo for in-project libraray dependency to avoid to link to my own shared libraray Sounds like you could profit from using convenience archives. 2. executables should build without library dependency. This mean that if configured with --enable-static the static object files should be used and if configureed without the shared object files should be used. Link the program against the library with -static. Hope that helps. Cheers, Ralf
Re: problem --enable-shared and --enable-static together
Am Samstag 05 Dezember 2009 13:33:06 schrieb Ralf Wildenhues: Hello Andreas, besides answers already given: * Andreas Otto wrote on Fri, Dec 04, 2009 at 09:41:16AM CET: as you see both *lo and *.o are created. the *.o are useless and just extend the compiling time Q: what can I do to avoid build static libraries ... foo_LIBTOOLFLAGS = -tag=disable-static for a target 'foo'. I use ../libmsgque/*.lo for in-project libraray dependency to avoid to link to my own shared libraray Sounds like you could profit from using convenience archives. from the info page: 8.3.5 Libtool Convenience Libraries --- Sometimes you want to build libtool libraries that should not be installed. These are called libtool convenience libraries and are typically used to encapsulate many sublibraries, later gathered into one big installed library. - the problem is not be installed the base library from my project is libmsgque and this library is used for the following purpose: 1. installed as library 2. used as base library for a language-extension library 3. used as base library for some test-tools. for 2+3 I don't want to link again the shared libraray of libmsgque 2. executables should build without library dependency. This mean that if configured with --enable-static the static object files should be used and if configureed without the shared object files should be used. Link the program against the library with -static. Hope that helps. Cheers, Ralf
problem --enable-shared and --enable-static together
Hi, I have a project using together the both statements from above to configure. This project hase many different parts includig many shared libraries and executables. Now the problem. 1. I have libraries which are only useful as shared libraries. this libraries are language extension used to dl-open by an programming language. these libraries should not build the static object files example: pkglib_LTLIBRARIES = tclmsgque.la tclmsgque_la_SOURCES = context_tcl.c misc_tcl.c msgque_tcl.c read_tcl.c send_tcl.c \ config_tcl.c service_tcl.c msgque_tcl.h slave_tcl.c \ MqBufferS_tcl.c error_tcl.c # use this if you want to include the libmsgque files into the tclmsgque libraray tclmsgque_la_CFLAGS = -I$(srcdir)/../libmsgque $(TCL_INCLUDE_SPEC) $(TCL_CFLAGS) $(AM_CFLAGS) -DMQ_IGNORE_EXTERN tclmsgque_la_LIBADD = ../libmsgque/*.lo tclmsgque_la_LDFLAGS = -shared -module -avoid-version -no-undefined $(TCL_LIBADD) the following object files are created -rw-rw-r-- 1 dev1usr users 1000 4. Dez 09:27 tclmsgque.la -rw-rw-r-- 1 dev1usr users323 4. Dez 09:27 tclmsgque_la-config_tcl.lo -rw-rw-r-- 1 dev1usr users 154528 4. Dez 09:27 tclmsgque_la-config_tcl.o -rw-rw-r-- 1 dev1usr users326 4. Dez 09:27 tclmsgque_la-context_tcl.lo -rw-rw-r-- 1 dev1usr users 120656 4. Dez 09:27 tclmsgque_la-context_tcl.o -rw-rw-r-- 1 dev1usr users320 4. Dez 09:27 tclmsgque_la-error_tcl.lo -rw-rw-r-- 1 dev1usr users 96240 4. Dez 09:27 tclmsgque_la-error_tcl.o -rw-rw-r-- 1 dev1usr users317 4. Dez 09:27 tclmsgque_la-misc_tcl.lo -rw-rw-r-- 1 dev1usr users 94800 4. Dez 09:27 tclmsgque_la-misc_tcl.o -rw-rw-r-- 1 dev1usr users332 4. Dez 09:27 tclmsgque_la-MqBufferS_tcl.lo -rw-rw-r-- 1 dev1usr users 97688 4. Dez 09:27 tclmsgque_la-MqBufferS_tcl.o -rw-rw-r-- 1 dev1usr users323 4. Dez 09:27 tclmsgque_la-msgque_tcl.lo -rw-rw-r-- 1 dev1usr users 103328 4. Dez 09:27 tclmsgque_la-msgque_tcl.o -rw-rw-r-- 1 dev1usr users317 4. Dez 09:27 tclmsgque_la-read_tcl.lo -rw-rw-r-- 1 dev1usr users 113008 4. Dez 09:27 tclmsgque_la-read_tcl.o -rw-rw-r-- 1 dev1usr users317 4. Dez 09:27 tclmsgque_la-send_tcl.lo -rw-rw-r-- 1 dev1usr users 122192 4. Dez 09:27 tclmsgque_la-send_tcl.o -rw-rw-r-- 1 dev1usr users326 4. Dez 09:27 tclmsgque_la-service_tcl.lo -rw-rw-r-- 1 dev1usr users 88400 4. Dez 09:27 tclmsgque_la-service_tcl.o -rw-rw-r-- 1 dev1usr users320 4. Dez 09:27 tclmsgque_la-slave_tcl.lo -rw-rw-r-- 1 dev1usr users 93392 4. Dez 09:27 tclmsgque_la-slave_tcl.o as you see both *lo and *.o are created. the *.o are useless and just extend the compiling time I use ../libmsgque/*.lo for in-project libraray dependency to avoid to link to my own shared libraray Q: what can I do to avoid build static libraries ... 2. executables should build without library dependency. This mean that if configured with --enable-static the static object files should be used and if configureed without the shared object files should be used. brain_SOURCES = brain.c brain_CFLAGS = -I../theLink/libmsgque -I$(BRAIN_HOME)/include - DMQ_LINK_WITH_LIBRARY_OBJECT_FILES if HAS_STATIC LIBMSQUE = ../theLink/libmsgque/*.o else LIBMSQUE = ../theLink/libmsgque/*.lo endif brain_LDADD = -lz -lbz2 -lrt -lm -lc $(LIBMSQUE) $(BRAIN_HOME)/lib/libtokyocabinet.a I need a HELPER called HAS_STATIC defined in configure.in with AM_CONDITIONAL([HAS_STATIC], [test $enable_static = yes]) Q: Is this OK or is something better is possible ? mfg Andreas Otto
Re: OS independent build results
Hi, this is my solution: this add a new target .vpath_hook to the build environment and this target copy the files/directories listed in VPATH_FILES from the src into the build environment. the copy is necessary because tools like JAR expect the files in the build directory. .vpath_hook is the FIRST target in BUILT_SOURCES to garantee that the copy is done before any furter action are done. 1. acinclude.m4 # # SC_SET_VPATH_HOOK -- # # add support for VPATH build # # Arguments: # none # need variable VPATH_FILES be defined # # Results: # # Add a new variable VPATH_HOOK/CLEANUP/DIST to automake # # AC_DEFUN([SC_SET_VPATH_HOOK], [ AC_MSG_CHECKING([add VPATH hook]) AC_SUBST([VPATH_HOOK], ['@if test ! -f .vpath_files -a $(srcdir) != . ; then (cd $(srcdir) cp -r $(VPATH_FILES) $(abs_builddir);) touch .vpath_files chmod -R u+w $(VPATH_FILES) echo VPATH copy; else true; fi touch .vpath_hook']) AC_SUBST([VPATH_HOOK_CLEANUP], ['-rm -f .vpath_hook; test -f .vpath_files rm -fr .vpath_files $(VPATH_FILES)']) AC_SUBST([VPATH_HOOK_DIST], ['-rm -f $(distdir)/.vpath_hook']) ]) 2. example java Automake.am: ... # ## VPATH setup .vpath_hook: $(VPATH_HOOK) VPATH_FILES = javamsgque javamsgque_MqS.h javamsgque_MqBufferS.h javamsgque_MqS_WAIT.h javamsgque.jar BUILT_SOURCES = .vpath_hook $(mqs_DATA) javamsgque_MqS.h javamsgque_MqBufferS.h MAINTAINERCLEANFILES = $(BUILT_SOURCES) javamsgque_MqS_WAIT.h javamsgque/*.class ... distclean-local: $(VPATH_HOOK_CLEANUP) dist-hook: $(MQS_MAIN) $(VPATH_HOOK_DIST) mkdir $(distdir)/javamsgque chmod u+w $(distdir)/javamsgque cp javamsgque/*.class $(distdir)/javamsgque chmod u+w $(distdir)/javamsgque/*.class !important! is that make clean should not clean the *.class files. I use the MAINTAINERCLEANFILES to clean this files also
OS independent build results
Hi, currently I try to improve my build environment. I want to add OS independent build results like java class files or mono clr libraries/excutable into the distribution 1) the problem is the VPATH build. the files from above are in the srcdir and not in the builddir (1'st location) 2) if one of the prerequisite file are touched (java - *.java, mono - *.cs) the new class or clr file(s) are in the builddir (2'nd location) after the build - now I have 2 locations from which the dist or a other command like the java jar can take the files 3) only for case 2) the VPATH build have to clean up the files 4) for a very special vase VB.NET CLR files can only be compiled on a special OS (Windows). A non-Windows OS should use the dist files and print a WARNING message if a build have to be done is a solution available? one solution would be that vor a VPATH build I can specify a set of dirs/files (in a variable) to COPIED first from the srcdir into the builddir, these copied files have to be removed in a distclean - attention the copy have only be done if the target of the same name is not available mfg Andreas Otto
builddir question
Hi, is a builddir other than . possible ? mfg aotto1968
Re: integration of perl with automake
Am Dienstag 20 Oktober 2009 21:07:35 schrieb Ralf Wildenhues: * Andreas Otto wrote on Tue, Oct 20, 2009 at 08:53:14AM CEST: Am Dienstag 20 Oktober 2009 08:27:01 schrieb Ralf Wildenhues: distclean-local: test -f Net-Msgque/.distclean rm -fr Net-Msgque Won't that also remove files from your package iff source and build tree coincide? I use the flag file Net-Msgque/.distclean to distinguish the VPATH build from the non VPATH build. this flag is only set in the directory I copied from the source into the build tree and clean act on this flag OK, but then 'make distclean' wouldn't remove the files it should remove, if source and build tree coincide, no? Cheers, Ralf Hi, $(PERLMAKEFILE): $(PERLDEPEND) Makefile.am -test ! -d Net-Msgque cp -pr $(srcdir)/Net-Msgque . \ chmod -R u+w Net-Msgque touch Net-Msgque/.distclean cd Net-Msgque @PERL@ Makefile.PL $(PERLCONFIG) non VPATH - build-tree == source-tree = no copy and no flag Net-Msgque.distclean = no distclean remove VPATH - build-tree != source-tree = copy from Net-Msgque done and flag Net-Msgque/.distclean set = distclean remove performed is this does not explain your problem than I don't understand what you mean mfg Andreas Otto
Re: integration of perl with automake
Am Dienstag 20 Oktober 2009 08:27:01 schrieb Ralf Wildenhues: Hello Andreas, thanks for sharing your solution. A couple of comments: * Andreas Otto wrote on Mon, Oct 19, 2009 at 12:20:26PM CEST: if USE_PERL PERLMAKEFILE = Net-Msgque/Makefile PERLDEPEND= Net-Msgque/Makefile.PL Net-Msgque/typemap Net- Msgque/lib/Net/Msgque.pm PERLCONFIG= PREFIX=$(prefix) \ It would be prudent to quote $(prefix), too. INC=-Wall -I. -I../$(top_srcdir)/src \ OBJECT=\$$(O_FILES) ../$(top_builddir)/src/.libs/*.o install-exec-local: cd Net-Msgque $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$(DESTDIR) install Likewise, I'd quote $(DESTDIR) here, or even better, omit DESTDIR=$(DESTDIR) unless Net-Msgque/Makefile initializes it. uninstall-local: rm -f $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/Net/Msgque.pm Please remove the slash between $(DESTDIR) and $(prefix) here and in following lines. Otherwise you risk breaking the installation on w32 with --prefix=C:/foo and empty DESTDIR. Also, again it would be prudent to quote the $(DESTDIR)$(prefix) part of the strings. rm -f $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/auto/Net/Msgque/Msgque.so rm -f $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/auto/Net/Msgque/Msgque.bs rm -f $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/auto/Net/Msgque/autosplit.ix rm -f $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/auto/Net/Msgque/.packlist rm -f $(DESTDIR)/$(prefix)/lib/*/*/*/perllocal.pod rm -f $(DESTDIR)/$(prefix)/share/man/man3/Net::Msgque.3 distclean-local: test -f Net-Msgque/.distclean rm -fr Net-Msgque Won't that also remove files from your package iff source and build tree coincide? Hi, I add your suggestions ... I use the flag file Net-Msgque/.distclean to distinguish the VPATH build from the non VPATH build. this flag is only set in the directory I copied from the source into the build tree and clean act on this flag mfg Andreas Otto
Re: integration of perl with automake
Hi, this is my solution: I have coosen a Makefile.am wrapper and the perl-extension is in a subdirectory of the wrapper. I changed the extension-name to Net::Msgque (as requested by the perl community) the automake configuration is complete (as of my needs) including a VPATH build and including the distclean check. PERL - MakeMaker does not support a VPATH build but a work- around is possible to copy the perl extension directory into the build directory. This have to be cleaned-up in distclean-local. now the Makefile: if USE_PERL PERLMAKEFILE = Net-Msgque/Makefile PERLDEPEND= Net-Msgque/Makefile.PL Net-Msgque/typemap Net- Msgque/lib/Net/Msgque.pm PERLCONFIG= PREFIX=$(prefix) \ INC=-Wall -I. -I../$(top_srcdir)/src \ OBJECT=\$$(O_FILES) ../$(top_builddir)/src/.libs/*.o if DEBUG PERLCONFIG+= OPTIMIZE=-g endif $(PERLMAKEFILE): $(PERLDEPEND) Makefile.am -test ! -d Net-Msgque cp -pr $(srcdir)/Net-Msgque . chmod -R u+w Net-Msgque touch Net-Msgque/.distclean cd Net-Msgque @PERL@ Makefile.PL $(PERLCONFIG) all-local: $(PERLMAKEFILE) cd Net-Msgque $(MAKE) $(AM_MAKEFLAGS) clean-local: $(PERLMAKEFILE) cd Net-Msgque $(MAKE) $(AM_MAKEFLAGS) clean install-exec-local: cd Net-Msgque $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$(DESTDIR) install uninstall-local: rm -f $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/Net/Msgque.pm rm -f $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/auto/Net/Msgque/Msgque.so rm -f $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/auto/Net/Msgque/Msgque.bs rm -f $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/auto/Net/Msgque/autosplit.ix rm -f $(DESTDIR)/$(prefix)/lib/*/site_perl/*/*/auto/Net/Msgque/.packlist rm -f $(DESTDIR)/$(prefix)/lib/*/*/*/perllocal.pod rm -f $(DESTDIR)/$(prefix)/share/man/man3/Net::Msgque.3 distclean-local: test -f Net-Msgque/.distclean rm -fr Net-Msgque endif EXTRA_DIST = \ Net-Msgque/ppport.h \ Net-Msgque/Msgque.xs \ Net-Msgque/lib/Net/Msgque.pm \ Net-Msgque/Makefile.PL \ Net-Msgque/README \ Net-Msgque/t/Net-Msgque.t \ Net-Msgque/Changes \ Net-Msgque/MANIFEST \ Net-Msgque/typemap mfg Andreas Otto
integration of perl with automake
Hi, to build a perl extension it's best to use the perl build-system based on perl Makefile.PL the command create a Makefile in the same directory of Makefile.PL self and in the toplefel-position perlmsgque/Makefile. I can use this makefile in an automake build environment using SUBDIRS += perlmsgque from the toplevel now the problem. a make clean clean the file perlmsgque/Makefile. this is coded in the Makefile.PL create Makefile 1. I need automake code to check if perlmsgque/Makefile is avilable and build this makefile again if missing (after make clean) or extend the toplevel Makefile to do a (cd perlmsgque;perl Makefile.PL) after all make clean was done 2. related to this problem Is the initial build of the perlmsgque/Makefile currently I use the autoconf to do the perl Makefile.PL but I thing it should be better done on need in the toplevel makefile. I hope this is not to complicated - thanks for help mfg aotto1968
I need a hint to integrate a php-extension build into an existing automake
Hi, I want to add a php extension into an allready existing project creating various extensions to other languages as well I use automake/autoconf for build top-level project. My new php extension has the name phpmsgque build in the subdirectory of the same name. The sudirectory is filled with all files necessary to build a php extension php requires the following steps to build an extension, 1. change into the phpmsgque directory 2. run the tool: phpize - this tool create a complete autoconf build environment including configure.in 3. run the command: ./configure --enable-phpmsgque - this create a Makefile 4. now use make for build now my problem: 1. while running the toplevel automake (or autoreconf) I would like to run the tool phpize in the phpmsgque subdirectory to create the php build environment. I have the Makefile.am (not used in the php build) to add instructions to link the both build environments. 2. while run toplevel configure I would like to run the configure script in the phpmsgque subdirectory as well so I looking for an integration of 2 build environments the second question is easy to solve I use AC_CONFIG_SUBDIRS([phpmsgque]) in the toplevel configure.in but the php build environment has no AM_INIT_AUTOMAKE to get a full integration I use the docs from automake info pages to get the info from above to integrate two packages:
binary distribution build with automake
Hi, I missing one target in automake to create a binary distribution Reason: 1. the default prefix is /usr/local - thats ok 2. this prefix is required for libraray rpath feature - thats ok 3. to buid and install a sw in /usr/local is a problem because it belons to root and not to the user ans should not be used in normal sw development what I want 1. a new target binary-dist 2. to create a binary distribution: $(PACKAGE)-$(PACKAGE_VERSION)-$(build).tar.gz - I choose build as hw/os identification string 3. able to use --prefix as system-directory !without! installation requirement mfg Andreas Otto
Re: Example on JNI compilation
Am Samstag 18 April 2009 23:08:58 schrieb LCID Fire: I'm currently stuck with compiling a JNI library, which java does not recognize. I'm not too sure about what options I have to provide to automake and which are already builtin. Does anybody know an example of how a jni lib is built using automake? Hi, in my project: http://libmsgque.sourceforge.net/ you can find a implementation useable as template 1. download the sources 2. go into the javamsgque directory 3. don't forget to add the autoconf macros for JNI from the m4 subdirectory and the acinclude.m4 file mfg Andreas Otto
problem to create a noinst_LTLIBRARIES shared libraray
Hi,
I currently writing a java JNI extension used only for local check and
this library should *not* be installed.
The problem is that I need a shared library for dlopen using java
file: TestMain.java
===
public abstract class TestMain extends MqS.Main {
static {
System.loadLibrary(javatestmsgque);
}
...
===
but automake/libtool only create a *static* library even if the _LDFLAGS
-module is used
file: Makefile.am
===
noinst_LTLIBRARIES = libjavatestmsgque.la
libjavatestmsgque_la_SOURCES = test_java.c TestMain.h
libjavatestmsgque_la_CFLAGS = -I$(top_srcdir)/src $(AM_CFLAGS)
libjavatestmsgque_la_LIBADD = ../src/libmsgque.la
libjavatestmsgque_la_LDFLAGS = -module
===
this are the static libraries created using the noinst_ prefix
buildsubdirectory: .libs
===
-rw-r--r-- libjavatestmsgque.a
lrwxrwxrwx libjavatestmsgque.la - ../libjavatestmsgque.la
-rw-r--r-- libjavatestmsgque_la-test_java.o
===
using the pkglib_ or the lib_ prefix I get the shared libraries
subdirectory: .libs
==
lrwxrwxrwx libjavatestmsgque.la - ../libjavatestmsgque.la
-rw-r--r-- 1libjavatestmsgque.lai
-rw-r--r-- 1libjavatestmsgque_la-test_java.o
lrwxrwxrwx libjavatestmsgque.so - libjavatestmsgque.so.0.0.0
lrwxrwxrwx libjavatestmsgque.so.0 - libjavatestmsgque.so.0.0.0
-rwxr-xr-x 1libjavatestmsgque.so.0.0.0
===
Question: what can I do to get a shared LTLIBRARIES using the noinst
prefix ?
every answer is welcome ...
