Re: Future plans for Autotools
On 21/1/21 9:15 am, Zack Weinberg wrote: Now we've all had a while to recover from the long-awaited Autoconf 2.70 release, I'd like to start a conversation about where the Autotools in general might be going in the future. Clearly any future development depends on finding people who will do the work, but before we worry about that I think we might want to figure out what work we _want_ to do. ... Agree with all that. The biggest problem i had that wasted the most time is that none of the documentation gave a good overview of the sequence of steps the main perl script did to process the files and produce the output, and intermediate files involved. Using a language like C++ where a step-by-step debugger like gdb can be used would have been good. Having a nuts and bolts low level detail of how it all works makes one much more productive. I'm talking of real software engineering ppl that understand compilers and not programmers that are really artist dabbling users. It is the real engineers that are more motivated to understand and be contributors. As a result, i only gradually got proficient over a few years, and having to comprehend a large manual on ancient shell variants and study M4 didn't help. M4 is easy if there's a decent tutorial readily available. Currently one needs to download other manuals and tutorials to get a good idea of it, and it's a big step for starting programmers. I understand mostly how things work, but got bogged down in understanding the perl script. If i mastered it all, i'd think more about what can be changed or improved. I did one early iteration of a tool that did the functions of 'make' using an input description of the files one wanted in a project. It also had its own shell implementation. Users would need a copy of that shell installed. An idea was to have the users script automatically build and install the shell in a location the user or system dictated. Another option was an automatic download from a trusted place. I could get more done if i had another go at it, but i'm too busy on a different tool. If GNU paperwork gets in the way, just bypass it and release new stuff as BSD. Then it's truly free.
Re: debbugs, and a FAQ, for Autotools
On 20/02/11 06:10, Ralf Wildenhues wrote:
Hi Russell,
* Russell Shaw wrote on Mon, Feb 14, 2011 at 12:00:14AM CET:
I'd ask more about how the internals of ./configure and autoconf works.
Can you formulate more specific questions?
And questions on how to make bison get handled without being forced to
mimic standard yacc.
I've added that question there now (without answer so far).
Thanks,
Ralf
Hi,
I'm not in autoconf debugging mode atm, so i'll have to ask more detailed
things some other time.
Looking through a ./configure script, i see lots of things being done
with file descriptors 5 and 6. What is going on here? eg:
## ##
## Autoconf initialization. ##
## ##
# ac_fn_c_try_compile LINENO
# --
# Try to compile conftest.$ac_ext, and return whether this succeeded.
ac_fn_c_try_compile ()
{
as_lineno=${as_lineno-$1} as_lineno_stack=as_lineno_stack=$as_lineno_stack
rm -f conftest.$ac_objext
if { { ac_try=$ac_compile
case (($ac_try in
*\* | *\`* | *\\*) ac_try_echo=\$ac_try;;
*) ac_try_echo=$ac_try;;
esac
eval ac_try_echo=\\$as_me:${as_lineno-$LINENO}: $ac_try_echo\
$as_echo $ac_try_echo; } 5
(eval $ac_compile) 2conftest.err
ac_status=$?
if test -s conftest.err; then
grep -v '^ *+' conftest.err conftest.er1
cat conftest.er1 5
mv -f conftest.er1 conftest.err
fi
$as_echo $as_me:${as_lineno-$LINENO}: \$? = $ac_status 5
test $ac_status = 0; } {
test -z $ac_c_werror_flag ||
test ! -s conftest.err
} test -s conftest.$ac_objext; then :
ac_retval=0
else
$as_echo $as_me: failed program was: 5
sed 's/^/| /' conftest.$ac_ext 5
ac_retval=1
fi
eval $as_lineno_stack; test x$as_lineno_stack = x { as_lineno=; unset
as_lineno;}
as_fn_set_status $ac_retval
} # ac_fn_c_try_compile
Re: debbugs, and a FAQ, for Autotools
On 14/02/11 05:12, Ralf Wildenhues wrote: [ Cross post; Reply-To and Mail-Followup-To set. Please followup to the automake list only, to avoid excessive spammage. Thank you. ] Hello everyone, I've been advertising debbugs before, I think we should be a good example. So, two proposals: 1) Autoconf and Libtool should also use debbugs. bug-automake has switched a few months ago, and I find it helpful to avoid losing reports. Given that we never have enough time on our hands, it becomes more important to not lose track. See http://debbugs.gnu.org/ and linked pages for details. 2) Autotools should have a FAQ document. Not of the sort of the FAQ chapter that answers seven random questions and that has a 1 year+ latency until it is updated, but one that answers both totally-newbie kinds of questions that get asked over and over again, or cross-tool bug questions like the infamous libtool echo problem (which was due to an incompatible m4sugar change). A document that, ideally, eventually obsoletes many of the third-party here's how autotools work, in quick kinds of pages. See e.g., this most recent thread which made the need so clear again: http://thread.gmane.org/gmane.comp.sysutils.automake.patches/5672 For (2) I'd suggest a wiki if we GNU the infrastructure, but something like a new page http://www.gnu.org/software/automake/Autotools-FAQ.html would certainly be good. (And yes, I've been arguing against wikis in the past. I was wrong. Sue me.) Now, I have very little spare time on my hands. Any volunteers on managing such a document? Any people interested in contributing answers or even only questions? I wouldn't mind handing out commit privs to any of the regulars on these lists. I'd ask more about how the internals of ./configure and autoconf works. And questions on how to make bison get handled without being forced to mimic standard yacc. I'm not in the mode of autoconf hacking atm though.
Re: default -g ??!?
On 20/11/10 06:10, MK wrote: I have a FOSS project distributed by debian, and for quite I've been using this in the Makefile.am under install-data-am: -strip --strip-all $(bindir)/executable Since I could not find a way to prevent the project being built -g, and there is no need for this. Use dh_strip However, I have a new release and my packager at debian is now saying they do not want strip used in makefiles. How can I prevent -g from being used? The normal debian packages are stripped by dh_strip, or not when the debug-symbols debs are made. Therefore, the debian packager wants control over that. Therefore, you don't need to worry about stripping.
Re: builddir
On 15/11/10 01:10, Ralf Wildenhues wrote: Hello Russell, * Russell Shaw wrote on Sun, Nov 14, 2010 at 02:49:07AM CET: In a Makefile.in generated by automake 1.9.6, it defines top_builddir ok, but builddir is used but not defined in there. This causes problems, because the automake manual says: — Variable: builddir Rigorously equal to ‘.’. Added for symmetry only. Automake 1.9.6 is very old. Presumably you're using an ancient version of Autoconf too, please state which. Normally I'd say upgrade and retry, but I might look at this if you post a small reproducer. Hi, I had a closer look at my system and found the debian alternatives system was pointing at an old version. I set it right now thanks.
builddir
Hi, In a Makefile.in generated by automake 1.9.6, it defines top_builddir ok, but builddir is used but not defined in there. This causes problems, because the automake manual says: — Variable: builddir Rigorously equal to ‘.’. Added for symmetry only.
Re: Building prog first
Steffen Dettmer wrote:
On Mon, Mar 22, 2010 at 4:44 PM, Reuben Thomas r...@sc3d.org wrote:
Not true. automake does not have explicit support for building
programs with the host compiler when cross-compiling, but I
have done this successfully in the past when I needed precisely
to build a program on the host when cross compiling, using
binutils's BFD_CC_FOR_BUILD macro. It's a pity some version of
this macro isn't in autoconf, or even autoconf-archive; I shall
do the latter.
I guess this is a hack and a burden to maintain.
When cross-compiling, why compiling a local tool?
Isn't the correct way to natively compile the local tool,
then use it to cross-compile the package?
This illustrates a weirdness of autotools: poor support for
installing interpreted languages, and also conversely for
build-time compiled programs.
Yes, also for coffee-cooking there is poor support only. :-)
I don't think build-time compiled C programs shall be suppored
while cross compiling. I think it already is complex enough.
Otherwise you had to do all checks twice and end up in many
variables with confusing names, and those who are not
cross-compiling probably accidently will mix them.
I though of perl, but (A), i don't like slow tools,
(I think Perl is fast)
(C), i find making build-programs
in C much more concise than scripting and i can debug it in ddd/gdb.
You can debug Perl in DDD.
This is interesting, as it doesn't match mine or
commonly-reported experience (translating my build-time
programs from C to Perl made them shorter, easier to read and
fix, and no slower to run, although I wasn't doing more than
grepping 15k lines of C and writing some of it back out again).
$ time perl -e \
'for($n=0;$n45;$n++) { printf %08d %60s EOL\n, $n, ; }' x
real0m0.713s
$ cat x.c
#include stdio.h
int main(void)
{
int n;
for(n=0; n45;n++) {
printf(%08d %60s EOL\n, n, );
}
return 0;
}
$ time make x
gcc -Wall -Wmissing-prototypes -fstrict-aliasing -D_GNU_SOURCE -ansi
-ggdb -ggdb x.c -o x
real0m0.076s
$ time ./xx2
real0m0.301s
so 713ms vs. 377 ms.
Interesting that up to around 100k Perl is even faster:
$ time perl \
-e 'for($n=0;$n10;$n++) { printf %08d %60s EOL\n, $n, ; }' x
real0m0.167s
$ time make x
real0m0.081s
$ time ./xx2
real0m0.079s
(of course those figures are far away from being exact; they just prove
how fast perl is: same magnitude as C)
Hi,
I'd think that printf() in perl would be mapped to the same printf()
in C lib stdio, and because this is the dominant code, the times are
similar.
What i had in mind is the efficiency of regular expression execution
in perl, compared to hard-coded parsing in C.
I will try perl in ddd/gdb some time.
Re: Building prog first
Steffen Dettmer wrote: * On Sun, Mar 21, 2010 at 10:27 AM, Ralf Wildenhues wrote: noinst_PROGRAMS = unimain unimain_SOURCES = unimain.c unidata.tab.c: unimain$(EXEEXT) /usr/share/unicode/UnicodeData.txt ./unimain$(EXEEXT) $ $@ BTW, execution of built programs like this makes your package unsuitable for cross-compilation. Just so you're aware of that. Assuming unidata.tab.c is a C-code table containing the information from UnicodeData.txt, I think it could be better to generate it by some shell code (maybe inside the Makefile.am, saving a tool) or to use perl (for the price of adding perl to the build dependencies) or, if UnicodeData rarely changes, add unidata.tab.c to the package and have some `maintainer only' helper target to build it (with unidata.tab.c as distributed source file). People who don't care about unidata.tab.c can build the package even without UnicodeData.txt (if this makes any sense, I don't know what this is for of course :)) I though of perl, but (A), i don't like slow tools, (B), unidata.tab.c is 5.6MBytes and 450k lines long, (C), i find making build-programs in C much more concise than scripting and i can debug it in ddd/gdb. The size of unidata.tab.c precludes distributing it. I could do more work on compacting it, but i have already done that to a degree.
Building prog first
Hi, I want the unimain program built first, then use it to generate unidata.tab.c, which is then compiled and linked into librunicode.la bin_PROGRAMS = unimain unimain_SOURCES = unimain.c lib_LTLIBRARIES = librunicode.la librunicode_la_SOURCES = runicode.c runicode.h #nodist_librunicode_la_SOURCES = unidata.tab.c #BUILT_SOURCES = unidata.tab.c unidata.tab.c: /usr/share/unicode/UnicodeData.txt ./unimain $ $@ How do i get unimain built first? I get the error: make all-am make[1]: Entering directory `/home/russell/librunicode/src' ./unimain /usr/share/unicode/UnicodeData.txt unidata.tab.c /bin/bash: ./unimain: No such file or directory make[1]: *** [unidata.tab.c] Error 127 make[1]: Leaving directory `/home/russell/librunicode/src' make: *** [all] Error 2
Re: Building prog first
Ralf Wildenhues wrote: Hello Russell, * Russell Shaw wrote on Sun, Mar 21, 2010 at 07:06:00AM CET: I want the unimain program built first, then use it to generate unidata.tab.c, which is then compiled and linked into librunicode.la bin_PROGRAMS = unimain unimain_SOURCES = unimain.c unidata.tab.c: /usr/share/unicode/UnicodeData.txt ./unimain $ $@ Then you need a dependency from unidata.tab.c on unimain: unidata.tab.c: unimain$(EXEEXT) /usr/share/unicode/UnicodeData.txt ./unimain$(EXEEXT) $ $@ Furthermore, please don't hard-code absolute paths like /usr/share/unicode/UnicodeData.txt in your makefiles. Make them configurable by configure. Maybe your users don't have root rights on their system but have the file installed below their home somewhere? Ok. I did: AC_CHECK_FILE([/usr/share/unicode/UnicodeData.txt], [], []) In configure, i get: if test x$ac_cv_file__usr_share_unicode_UnicodeData_txt = xyes; then : fi Shouldn't this be: if test x$ac_cv_file__usr_share_unicode_UnicodeData_txt = xyes; then : fi
Re: Building prog first
Ralf Wildenhues wrote: * Russell Shaw wrote on Sun, Mar 21, 2010 at 09:26:44AM CET: Ralf Wildenhues wrote: * Russell Shaw wrote on Sun, Mar 21, 2010 at 07:06:00AM CET: bin_PROGRAMS = unimain unimain_SOURCES = unimain.c unidata.tab.c: unimain$(EXEEXT) /usr/share/unicode/UnicodeData.txt ./unimain$(EXEEXT) $ $@ Ok, that works thanks:) However, make install installs unimain into /usr/local/bin How do i stop this program from being installed? Use noinst_PROGRAMS instead of bin_PROGRAMS. Be encouraged to read the fine manual. But it is somewhat big, and i had already searched through the online one a lot first. It is no wonder it takes noobs so long to get productive. BTW, execution of built programs like this makes your package unsuitable for cross-compilation. Just so you're aware of that. Ok. I assume then that you can't build the tool for the host system while the generated files are compiled for the target system?
Re: Building prog first
Ralf Wildenhues wrote: * Russell Shaw wrote on Sun, Mar 21, 2010 at 11:18:03AM CET: Ralf Wildenhues wrote: Use noinst_PROGRAMS instead of bin_PROGRAMS. Be encouraged to read the fine manual. But it is somewhat big, and i had already searched through the online one a lot first. It is no wonder it takes noobs so long to get productive. I'm not sure how to help that. If more documentation makes people less likely to look at it, then what would you suggest in order to improve upon the situation? Is the documentation not structured well enough? Does the Autotools Introduction chapter in the Automake manual not help get a basic grasp? I agree that the initial learning steps may not be easy for Automake, but I don't see how to make Automake a lot easier without also ripping out much of the functionality. So turning that knob is fairly unlikely. Hi, I was limping along for years learning autoconf/make in bits until this tutorial came out Autotools: a practitioner's guide to Autoconf, Automake and Libtool http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool I realized a lot of useful things after that. The main thing that makes it easy is that a real project is stepped through with lots of side discussions, and high-level overviews put things in to perspective. I'd really like to have a hard-copy book of that tutorial. After that, i could understand the autoconf manual. I was on dos/windows up to nearly yr2000 or so, so i had to learn unix programming, shell programming, make-file programming, m4, how unix processes work etc, to be able to look in generated Makefiles and configure and see from that what errors i was making in configure.ac and automake.am. Learning too many things simultaneously, but i know now. BTW, execution of built programs like this makes your package unsuitable for cross-compilation. Just so you're aware of that. Ok. I assume then that you can't build the tool for the host system while the generated files are compiled for the target system? First off, allow me to clarify the nomenclature as it is used in GNU software: - the build system is the one you run configure and 'make all' on, - the host system is the one that the programs which 'make all' normally generates and installs, will run on later, - the target system does not exist. Never. Unless your package happens to be a compiler or linker (or similar). Then, the target system is the one for which your installed compiler/linker will generate code for. With that, your sentence above should have been Ok. I assume then that you can't build the tool for the build system while the generated files are compiled for the host system? Not straight-forwardly, no. Once you've got your basic package working and cross compilation support is the only thing missing, please come back and we'll explain. Ok. Thanks for the help. -- regards, Russell
Re: Building prog first
Alfred M. Szmidt wrote: Have you tried reading `(automake) Autotools Introduction'? It is part of the automake manual. Hi, I printed out all the autotools manuals and have read every page of them more than once. It was a while ago, so it's easy to forget things. Searching the online manual isn't all successful at times, but i've figured out a fair bit of it now.
BUILT_SOURCES
Hi, BUILT_SOURCES has no effect. gran.proc.tab.c should be built first, but it doesn't happen. eerat isn't even run: bin_PROGRAMS = appmain appmain_SOURCES = appmain.c nodist_appmain_SOURCES = gran.proc.tab.c BUILT_SOURCES: gran.proc.tab.c gran.proc.tab.c: gran.spec eerat $ -o gran Automake is 1.9.6 on debian/unstable Inspecting the generated Makefile doesn't seem to do anything with BUILT_SOURCES.
Re: BUILT_SOURCES
Simon Richter wrote: Hi, On Fri, Dec 18, 2009 at 12:07:40AM +1100, Russell Shaw wrote: BUILT_SOURCES: gran.proc.tab.c BUILT_SOURCES is a variable, not a target. Ok Thanks Simon. Should be '=' instead of ':'. I knew that, but i didn't type what i mean ;)
Re: Shared library location
Ralf Wildenhues wrote: Hello Russell, * Russell Shaw wrote on Fri, Jun 05, 2009 at 06:42:16PM CEST: In my code that isn't installed, i dlopen my.so: ~/home/russ/myproj/src/libdir/my.so When i make install, i want the dlopen to get my.so from a system location: /usr/lib/my.so What make variable can i utilize that has a value dependent on whether the package is installed or not? Typically, projects that create modules use libtool to do so, and use libtool --mode=execute -dlopen libdir/my.la ./program ... to run an uninstalled program, while they use program ... to run an installed program. The former ensures that dlopening my.so will find the uninstalled library. Should you not use libtool, you could still use wrapper scripts for your uninstalled programs to prefer uninstalled libraries, config files, etc. The Automake package does this too, with the tests/automa...@version@ and tests/acloc...@version@ wrappers. Hi, I figured it out by making the program look for a header file #define that happens to be deleted for an installed header file. I edited the header file using an install-data-hook. It's a bit tedious using libtool --mode=execute -dlopen libdir/my.la ./program when doing many edit-compile cycles and interacting with gdb etc.
Re: Shared library location
Russell Shaw wrote: Ralf Wildenhues wrote: Hello Russell, * Russell Shaw wrote on Fri, Jun 05, 2009 at 06:42:16PM CEST: In my code that isn't installed, i dlopen my.so: ~/home/russ/myproj/src/libdir/my.so When i make install, i want the dlopen to get my.so from a system location: /usr/lib/my.so What make variable can i utilize that has a value dependent on whether the package is installed or not? Typically, projects that create modules use libtool to do so, and use libtool --mode=execute -dlopen libdir/my.la ./program ... to run an uninstalled program, while they use program ... to run an installed program. The former ensures that dlopening my.so will find the uninstalled library. Should you not use libtool, you could still use wrapper scripts for your uninstalled programs to prefer uninstalled libraries, config files, etc. The Automake package does this too, with the tests/automa...@version@ and tests/acloc...@version@ wrappers. Hi, I figured it out by making the program look for a header file #define that happens to be deleted for an installed header file. I edited the header file using an install-data-hook. I found that doesn't work how i wanted. Ignore.
Shared library location
Hi, In my code that isn't installed, i dlopen my.so: ~/home/russ/myproj/src/libdir/my.so When i make install, i want the dlopen to get my.so from a system location: /usr/lib/my.so What make variable can i utilize that has a value dependent on whether the package is installed or not?
Convenience programs
Hi, In /proj/keysyms, i have a Makefile.am and it generates a genkeysyms program in C. /proj/src contains a Makefile.am and it generates source files in this directory using ../keysyms/genkeysyms, then uses these sources in the rest of the compile. /proj/src/Makefile.am has: keysyms.tab.include: ../keysyms/genkeysyms ../keysyms/genkeysyms make distcheck reports: ../keysyms/genkeysyms make[3]: ../keysyms/genkeysyms: Command not found How do i get /proj/keysyms/genkeysyms built first? Do i add(?): ../keysyms/genkeysyms: make -C ../keysyms
Re: Convenience programs
John Calcote wrote: Russell, On 4/1/2009 4:47 AM, Russell Shaw wrote: ... proj/Makefile.am should contain: SUBDIRS = ... keysyms ... src ... Just makesure keysyms is given before src in that list. Thanks, it works now:)
Re: GNU Make Extensions
Bob Friesenhahn wrote: On Wed, 10 Dec 2008, NightStrike wrote: Ok, so again, I should be allowed to accept that *potential* risk as being far less than the current situation of *actual* risk which is causing problems. If I knew anything about Perl, I'd just do it myself, but alas, the automake source confounds me :( There is a philosophical stance that the software we develop is intended for the software users rather than the software developer. There is a problem if build behavior is different for the user than for the software developer. It seems that increasingly there is an idea among software developers and maintainers that software developer satisfaction is more important than user satisfaction. Damn right there is, or i'd just be developing for Redmond. Only with low development agro will developers be more motivated to fix users problems. If that wasn't the case, i'd be programming in assembler. Software lasts longer than any individual maintainer or developer and so GNU build tools should strive to preserve the freedom of that software by ensuring that end users are provided with the same facilities that the original developers had available. This includes the list of files which are included in the package.
Re: CLEANFILES
Cédric Lucantis wrote: Le samedi 04 août 2007, Russell Shaw a écrit : Hi, I'm using automake 1.9.6. In automake.am, i have: CLEANFILES: *.tab.c *.tab.h *.tab.callback However, in the generated makefile, CLEANFILES appears, but is not referenced anywhere. Therefore, make clean doesn't work as it should. Hi, CLEANFILES is not a target but a user variable, so should have something like this instead : CLEANFILES = $(wildcard *.tab) $(wildcard *.tab.h) ... (I think the wildcard command is better than a shell expansion, but I'm not sure it makes a difference in that case. See info make for more about that) I found the problem was i had CLEANFILES: instead of CLEANFILES=.
Library locations
Hi, In automake.am, i have: System_LTLIBRARIES = system.la system_la_SOURCES = modules/System/system.c system_la_LDFLAGS = -module This compiles ok. However, it puts system.la in the top level src directory. I want it to be like: System_LTLIBRARIES = modules/System/system.la modules_System_system_la_SOURCES = modules/System/system.c modules_System_system_la_LDFLAGS = -module That makes modules/System/system.la ok, but it still puts system.o and system.lo in the top level src directory. That means the program won't work in the uninstalled state, because dlopen is looking for system.o as modules/System/system.o.
Re: Library locations
Braden McDaniel wrote: On Mon, 2007-08-06 at 03:49 +1000, Russell Shaw wrote: Hi, In automake.am, i have: System_LTLIBRARIES = system.la system_la_SOURCES = modules/System/system.c system_la_LDFLAGS = -module This compiles ok. However, it puts system.la in the top level src directory. I want it to be like: System_LTLIBRARIES = modules/System/system.la modules_System_system_la_SOURCES = modules/System/system.c modules_System_system_la_LDFLAGS = -module That makes modules/System/system.la ok, but it still puts system.o and system.lo in the top level src directory. Look again. That's entirely inconsistent with my experience with automake's (1.10) behavior. The object file generated from the above should be modules/System/modules_System_system_la-system.lo. That means the program won't work in the uninstalled state, because dlopen is looking for system.o as modules/System/system.o. That seems unlikely. dlopen should be looking for system.so. I don't imagine it cares about the location of system.o. Hi, I have: AUTOMAKE_OPTIONS = subdir-objects System_LTLIBRARIES = modules/System/system.la modules_System_system_la_SOURCES = modules/System/system.c modules_System_system_la_LDFLAGS = -module and now it works better with: modules/System/system.la modules/System/system.lo modules/System/system.o generated.
Re: Library locations
Ralf Wildenhues wrote: Hello Braden, Russell, * Braden McDaniel wrote on Sun, Aug 05, 2007 at 08:27:07PM CEST: On Mon, 2007-08-06 at 03:49 +1000, Russell Shaw wrote: I want it to be like: System_LTLIBRARIES = modules/System/system.la modules_System_system_la_SOURCES = modules/System/system.c modules_System_system_la_LDFLAGS = -module That makes modules/System/system.la ok, but it still puts system.o and system.lo in the top level src directory. The latter feature is governed by the Automake option subdir-objects. Note that the option has existed for a long time, but its functionality has been improved lately, e.g., for non-C sources. See the NEWS file for details. Hi, I forgot about that option. Look again. That's entirely inconsistent with my experience with automake's (1.10) behavior. The object file generated from the above should be modules/System/modules_System_system_la-system.lo. Then you have subdir-objects set. That means the program won't work in the uninstalled state, because dlopen is looking for system.o as modules/System/system.o. That seems unlikely. dlopen should be looking for system.so. I don't imagine it cares about the location of system.o. I agree with Braden here, dlopen should not care about object positions and things should work with subdir-objects and without. If you have a failure setup, please show us how to reproduce it. I have: AUTOMAKE_OPTIONS = subdir-objects System_LTLIBRARIES = modules/System/system.la modules_System_system_la_SOURCES = modules/System/system.c modules_System_system_la_LDFLAGS = -module AM_LDFLAGS = -export-dynamic and now it works better with: modules/System/system.la modules/System/system.lo modules/System/system.o generated. However, the shared object that dlopen requires is in a new .libs directory: modules/System/.libs/system.o modules/System/.libs/system.so modules/System/.libs/system.so.0 modules/System/.libs/system.so.0.0.0 Dlopen fails because it is looking for modules/System/system.so When installed, i'll have the install location at: /usr/lib/$(pkglibdir)/System/system.so Should i just have dlopen look for modules/System/.libs/system.so and modules/System/system.so and use the first one that succeeds, or is there a cleaner way for avoiding this?
Re: Library locations
Ralf Wildenhues wrote: Hello Braden, Russell, * Braden McDaniel wrote on Sun, Aug 05, 2007 at 08:27:07PM CEST: On Mon, 2007-08-06 at 03:49 +1000, Russell Shaw wrote: I want it to be like: System_LTLIBRARIES = modules/System/system.la modules_System_system_la_SOURCES = modules/System/system.c modules_System_system_la_LDFLAGS = -module That makes modules/System/system.la ok, but it still puts system.o and system.lo in the top level src directory. The latter feature is governed by the Automake option subdir-objects. Note that the option has existed for a long time, but its functionality has been improved lately, e.g., for non-C sources. See the NEWS file for details. Hi, I forgot about that option. Look again. That's entirely inconsistent with my experience with automake's (1.10) behavior. The object file generated from the above should be modules/System/modules_System_system_la-system.lo. Then you have subdir-objects set. That means the program won't work in the uninstalled state, because dlopen is looking for system.o as modules/System/system.o. That seems unlikely. dlopen should be looking for system.so. I don't imagine it cares about the location of system.o. I agree with Braden here, dlopen should not care about object positions and things should work with subdir-objects and without. If you have a failure setup, please show us how to reproduce it. I have: AUTOMAKE_OPTIONS = subdir-objects System_LTLIBRARIES = modules/System/system.la modules_System_system_la_SOURCES = modules/System/system.c modules_System_system_la_LDFLAGS = -module AM_LDFLAGS = -export-dynamic and now it works better with: modules/System/system.la modules/System/system.lo modules/System/system.o generated. However, the shared object that dlopen requires is in a new .libs directory: modules/System/.libs/system.o modules/System/.libs/system.so modules/System/.libs/system.so.0 modules/System/.libs/system.so.0.0.0 Dlopen fails because it is looking for modules/System/system.so When installed, i'll have the install location at: /usr/lib/$(pkglibdir)/System/system.so Should i just have dlopen look for modules/System/.libs/system.so and modules/System/system.so and use the first one that succeeds, or is there a cleaner way for avoiding this? Also, what's the best way to determine from within the program whether it is currently installed or not?
CLEANFILES
Hi, I'm using automake 1.9.6. In automake.am, i have: CLEANFILES: *.tab.c *.tab.h *.tab.callback However, in the generated makefile, CLEANFILES appears, but is not referenced anywhere. Therefore, make clean doesn't work as it should.
Re: CLEANFILES
Cédric Lucantis wrote: Le samedi 04 août 2007, Russell Shaw a écrit : Hi, I'm using automake 1.9.6. In automake.am, i have: CLEANFILES: *.tab.c *.tab.h *.tab.callback However, in the generated makefile, CLEANFILES appears, but is not referenced anywhere. Therefore, make clean doesn't work as it should. Hi, CLEANFILES is not a target but a user variable, so should have something like this instead : CLEANFILES = $(wildcard *.tab) $(wildcard *.tab.h) ... It makes no difference because the whole point of a user variable is that CLEANFILES should be used by the makefile, but for some reason it isn't. (I think the wildcard command is better than a shell expansion, but I'm not sure it makes a difference in that case. See info make for more about that) I've read that. I used CLEANFILES many months ago and it worked ok. Now it doesn't.
Re: aclocal search path
Ralf Wildenhues wrote: Hello Russell, * Russell Shaw wrote on Sun, Sep 17, 2006 at 03:00:29PM CEST: Does aclocal have a way to add m4 directories using an environment variable? AFAIK no, but you can add directories using the -I flag. On debian, it only looks in /usr/share/aclocal. I want it to look in /usr/local/share/aclocal too. aclocal -I /usr/local/share/aclocal should work. If you use autoreconf, you can use the environment variable $ACLOCAL (but note that the first -I flag is special, so if your toplevel Makefile.am contains ACLOCAL_AMFLAGS, that may make a difference). I couldn't find the source for aclocal in the automake tree. It's in the file aclocal.in. Hi, I found from looking at aclocal.in, i can put a file called dirlist in /usr/share/aclocal, containing the path: /usr/local/share/aclocal. When you compile a project from source and have libraries it needs already installed in /usr/local, then the autogen.sh scripts they have will not see /usr/local/share/aclocal. It is impractical to manually do aclocal -I for these cases. The aclocal -I path should be initialized from an environment variable, like it is for autoreconf.
aclocal search path
Hi, Does aclocal have a way to add m4 directories using an environment variable? On debian, it only looks in /usr/share/aclocal. I want it to look in /usr/local/share/aclocal too. I couldn't find the source for aclocal in the automake tree.
pkgsysconfdir
Hi, There is pkgdatadir, pkglibdir, and pkgincludedir. Wouldn't it make sense to have a pkgsysconfdir too?
Re: Exec install location
Ralf Wildenhues wrote: Hello Russel, * Russell Shaw wrote on Tue, Sep 05, 2006 at 04:21:20PM CEST: What do i put into Makefile.am to get a program installed into /usr/bin? (I just read the autoconf and automake manuals) Nothing, you just ./configure --prefix=/usr or, if you want only /usr/bin but everything else below /usr/local, ./configure --bindir=/usr/bin Hope that helps. Yes it did. When i do make distcheck, is there a way to get a list of where all the files get installed?
Re: Exec install location
Ralf Wildenhues wrote: Hello Russel, * Russell Shaw wrote on Tue, Sep 05, 2006 at 04:21:20PM CEST: What do i put into Makefile.am to get a program installed into /usr/bin? (I just read the autoconf and automake manuals) Nothing, you just ./configure --prefix=/usr or, if you want only /usr/bin but everything else below /usr/local, ./configure --bindir=/usr/bin Hope that helps. Yes it did. When i do make distcheck, is there a way to get a list of where all the files get installed? Also, how do i install a directory of data files? I tried: dist_pkgdata_DATA = sysdefaults/avk/ i get (from make distcheck): /usr/bin/install: omitting directory `../../src/sysdefaults/avk/' because /usr/bin/install didn't have the -d option.
Copying a file after each subdirectory build
Hi, I have lots of libraries and programs in separate directories, each with its own configure.ac and Makefile.am. What can i put into Makefile.am so that after each library is built, it will copy its header file and object file to another directory in the project tree? I want all the library headers in a header directory and library objects in an objects directory, in the same layout that they will be installed on the host system. I also want the rest of the programs in the project to be linked to them during the project make.
Re: GNU ftp crack and config.{sub,guess}
Paul D. Smith wrote: I'm still waiting for _ANY_ kind of response here. Doesn't anyone know or care about config.guess or config.sub anymore? From automake manual: config.guess config.sub These programs compute the canonical triplets for the given build, host, or target architecture. These programs are updated regularly to support new architectures and fix probes broken by changes in new kernel versions. You are encouraged to fetch the latest versions of these files from ftp://ftp.gnu.org/gnu/config before making a release. locate config.guess ... /usr/share/doc/config.guess # This script attempts to guess a canonical system name similar to # config.sub. If it succeeds, it prints the system name on stdout, and # exits with 0. Otherwise, it exits with 1. # # The plan is that this can be called by configure scripts if you # don't specify an explicit build system type.
gthread linking
Hi, In configure.am, i have: AM_PATH_GTK_2_0(2.0.0,,,gthread) AM_PATH_GLIB_2_0(2.0.0,,,gthread) but i still get linker errors: gcc -g -O2 -o iongen main.o gui.o eventfifo.o event.o xmalloc.o -Wl,--export-dynamic -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 gui.o(.text+0xfc): In function `gui': /home/.../iongen/src/gui.c:72: undefined reference to `g_thread_init' collect2: ld returned 1 exit status I've tried running autoreconf (2.57).
