I have seen user-induced lines in Makefile.am like these in a handful
of packages:
${pkgconfig_DATA}: ${top_builddir}/config.status
Given that automake 1.11.1/autoconf 2.68 seem to automatically recreate
files specified in AC_CONFIG_FILES when configure.ac is changed, what is
the actu
On Sunday 2012-01-01 10:24, Stefano Lattarini wrote:
>On 12/31/2011 12:29 AM, Jan Engelhardt wrote:
>>
>> I have seen user-induced lines in Makefile.am like these in a handful
>> of packages:
>>
>Which packages? I need more information if I am
Much to my disappointment, I found that the newly-released libkmod v5
has made the following non-trivial change to its source tree, the latter
of which I want to bring to attention:
commit e479598b7d19ae7be45bf5329d6e4df32d646c16
diff --git a/Makefile.am b/Makefile.am
ind
Hi,
Is there an option to yield an error instead of a warning
if Makefile.in needs to be regenerated, but can't?
The case before me is that iptables's Makefile.am in openSUSE is
patched after tarball extraction. But, due to 1. $PEBKAC not calling
autoreconf, 2. the system having automake-1.12 i
The
help2man: can't get `--help' info from ./aclocal
error seems to have reappeared in automake-1.13.1 (judging from
http://gnu-automake.7480.n7.nabble.com/Man-pages-for-automake-and-aclocal-td11966.html)
help2man is of version 1.40.12.
---
Executing(%build): /bin/sh -e /var/tmp/rp
On Wednesday 2013-01-09 19:11, Stefano Lattarini wrote:
>On 01/09/2013 05:05 PM, Jan Engelhardt wrote:
>>
>> The
>>
>> help2man: can't get `--help' info from ./aclocal
>>
>> error seems to have reappeared in automake-1.13.1 (judging fr
On Wednesday 2013-01-09 22:27, Stefano Lattarini wrote:
>>
>> Now I just have to figure out why someone thought that openSUSE
>> should create the manpages directly...
>>
>Good question
>
>What happens if you do this instead?
>
>help2man -S FSF ./t/wrap/aclocal-1.13 > output.1
>
>Does this fi
Given a Makefile.am with
myprog_LDADD = -pthread
automake will correctly output this warning
Makefile.am:17: error: linker flags such as '-pthread'
belong in 'myprog_LDFLAGS'
It would be nice to also have automake report -l flags in LDFLAGS that
actually belong into L
Using automake-1.13.4, when using the following Makefile.am fragment,
---8<---
bin_PROGRAMS = foo
foo_SOURCES = foo.c bar.k
.k.${OBJEXT}:
gcc -x c -c $< -o $@
--->8---
I observe that bar.o is not built and not linked into foo.
---8<---
> make V=0
CC foo.o
CCLD foo
/usr/lib
On Wednesday 2014-11-12 20:15, Nick Bowler wrote:
>On 2014-11-12 16:58 +0100, Jan Engelhardt wrote:
>> Using automake-1.13.4, when using the following Makefile.am fragment,
>> .k.${OBJEXT}:
>> gcc -x c -c $< -o $@
>> I observe that bar.o is not built and
Greetings.
Consider a Makefile.am like so:
bin_PROGRAMS = aprogram
sbin_PROGRAMS = otherprogram
lib_LTLIBRARIES = library1.la
pkglib_LTLIBRARIES = library2.la
library2_la_LIBADD = library1.la
this will produce, under automake 1.15/1.16, a Makefile.in which
-libLTLIBRARIES
therefore potentially breaking `make install -j`. Rectify this by
depending on install-libLTLIBRARIES not just for bin_PROGRAMS, but
all PROGRAMS and LTLIBRARIES.
Signed-off-by: Jan Engelhardt
---
bin/automake.in | 23 +--
1 file changed, 17 insertions(+), 6
-libLTLIBRARIES
therefore potentially breaking `make install -j`. Rectify this by
depending on install-libLTLIBRARIES not just for bin_PROGRAMS, but
all PROGRAMS and LTLIBRARIES.
Signed-off-by: Jan Engelhardt
---
Also available from https://github.com/jengelh/automake
if that is easier to download
On Sunday 2021-08-29 22:44, Karl Berry wrote:
>Subject: [PATCH v2] automake: add install dep on install-libLTLIBRARIES to
> all
> targets
>
>Thanks. Have you run make check? (In practice, make -j12 check or similar.)
>Always good to make sure nothing old breaks ... -k
# TOTAL: 29
On Tuesday 2021-09-21 19:02, Karl Berry wrote:
>Suppose I want to generate a lex or yacc input file from another file,
>e.g., a CWEB literate program. Is there a way to tell Automake about
>this so that the ultimately-generated parser/lexer [.ch] files are saved
>in srcdir, as happens when [.ly] a
On Tuesday 2021-09-21 22:32, Karl Berry wrote:
>Thanks much. I was thinking I should avoid that since the .[ly] are not
>ultimate sources, but if it works, fine with me.
>
>jan>
>BUILT_SOURCES = foo.y
>foo.y: foo.cweb
>somecommands
>
>That would be sensible, but I failed t
On Tuesday 2022-02-15 07:16, Daniel Herring wrote:
>
> Maybe a next-generation configuration tool should start by defining interfaces
> for user interactions and build tools. This would allow CLI and easy GUI and
> IDE users, integration with multiple build systems, static and dynamic
> probing
On Sunday 2022-03-27 23:22, Karl Berry wrote:
>It seems the basic inconsistency is whether CPPFLAGS is considered a
>"user variable" or not. In earlier eras, it wasn't [...]
In earlier eras of what exactly?
As for make, it never made a distinction between user variables or otherwise,
at least
On Friday 2022-04-29 22:59, Thomas Jahns wrote:
> On 4/27/22 3:49 PM, R. Diez wrote:
>> Is there a way to speed 'automake' up?
>
> While you are probably looking for system-independent advice, the best results
> I've had with speeding up ephemeral builds is to simply use /dev/shm for
> backing st
On Monday 2022-05-02 14:20, Thomas Jahns wrote:
Is there a way to speed 'automake' up?
>>>
>>> [...let] ephemeral builds [..] use /dev/shm [...]
>>
>> There ought to be little difference [...] automake, that's nowhere near as
>> IO-heavy as untarring kernel source archives. It's much more
On Monday 2022-05-02 15:18, Bob Friesenhahn wrote:
> On Mon, 2 May 2022, Jan Engelhardt wrote:
>>
>> Indeed, if a source code package consists of 1 files, then configure
>> produces another 10k files for the stuff in the ".deps" directories.
>> There is n
On Monday 2022-05-02 15:31, Jan Engelhardt wrote:
>> If empty files are ok (assuming they are needed at all), can they be produced
>> with a minimum number of executions of a 'touch' command?
>
>Better yet, they can be produced with the ">>" shell b
On Monday 2022-05-02 22:52, Karl Berry wrote:
>- @echo '# dummy' >$@-t && $(am__mv) $@-t $@
>+ @: >>$@
>
>2) without the mv I fear we are no longer noticing write failure. -k
I see no reason why mv would be so crucial.
Case 1. Lack of permission. The ">" operation is the one that fai
Greetings.
A check was impleneted in rpmlint[1] that verifies that a manual page file such
as "foo.3" has indeed been placed in ${mandir}/man3, and not, say,
${mandir}/man4.
[1]
https://github.com/rpm-software-management/rpmlint/commit/6fe4be934d60119f9a969a8b8198037e3f1c7941
Ironically, that c
On Wednesday 2022-08-31 23:20, Karl Berry wrote:
>
>Should the rpmlint check be adjusted to cater to the GNU FHS?
>
>[..]
>Also, GNU (as an organization) never had anything to do with the FHS,
I just called it GNU FHS to distinguish it from the LF/LSB FHS. Autotools
for example defaults to
On Wednesday 2022-10-05 00:58, Karl Berry wrote:
>
>Nothing has changed in the tests. Nothing has changed in the automake
>infrastructure. Everything worked for me a few weeks ago. Furthermore,
>Jim ran make check with much more parallelism than my machine can
>muster, and everything succeeded fo
On Wednesday 2022-10-05 23:24, Karl Berry wrote:
>
>What troubles me most is that there's no obvious way to debug any test
>failure involving parallelism, since they go away with serial execution.
>Any ideas about how to determine what is going wrong in the parallel
>make? Any way to make parall
On Friday 2022-11-18 22:57, Russ Allbery wrote:
>madmurphy writes:
>
>> However, if at the same time I set also the libfoo_la_CPPFLAGS variable (no
>> matter the content), as in the following example,
>
>> AM_CPPFLAGS = \
>> "-DLIBFOO_BUILD_MESSAGE=\"correctly defined via AM_CPPFLAGS\""
>>
On Saturday 2022-11-19 09:11, madmurphy wrote:
>I guess it does make sense. But then what might be missing to Automake are
>libXXX_la_AM_CFLAGS, libXXX_la_AM_CPPFLAGS and libXXX_la_AM_LDFLAGS
>variables, in which the global AM_CFLAGS, AM_CPPFLAGS and AM_LDFLAGS are
>automatically pasted (whereas t
(With automake 1.16.5), your typical Makefile.am produces a Makefile
like so:
-8<- Makefile
AMTAR = $${TAR-tar}
am__tar = $${TAR-tar} chof - "$$tardir"
am__untar = $${TAR-tar} xf -
dist-gzip: distdir
tardir=$(distdir) && $(am__tar) | eval GZIP= gzip $(GZIP_ENV) -c
>$(distdir).tar.gz
On Monday 2022-11-21 16:22, Thomas Jahns wrote:
>The question consequently is: how would I create a Makefile.am that accounts
>for a list of C sources, when the sources are not yet present/known from the
>perspective of automake?
I don't see that working even without automake. Once make has loa
On Wednesday 2023-02-08 03:39, Dmitry Goncharov wrote:
>
>This rule restores a missing depfile file by creating a file with one
>line '# dummy'. (Next version of automake will create an empty one).
>There must have been a reason for generating such a depfile.
depfiles are created ahead of make s
On Thursday 2023-02-09 22:33, Dmitry Goncharov wrote:
>
>> .Po file contents control when an .o file -- and thus also
>> the .Po file itself -- is remade.
>> If a .Po file has no practical content, there is no indication
>> that it needs to be remade.
>
>Absence of the depfile is such an indicati
On Thursday 2023-02-09 22:53, Dmitry Goncharov wrote:
>
>> If you try this with e.g.
>> OpenBSD make, it will complain.
>
>That's why i asked those questions about portability.
>Do i understand it correctly, that a need to support bmake forces
>automake to abandon a good mechanism to rebuild depf
On Wednesday 2023-03-01 19:50, ljh via Discussion list for automake wrote:
>```
>$ make # NDEBUG=1
>$ make NDEBUG=1
>```
>
>Can I have automake.am to define and convey something like this to the output
>Makefile:
>```
>ifdef NDEBUG # if vs. ifdef
>CPPFLAGS += -DNDEBUG
>CFLAGS += -O3
ed in given list of subdirs.
but whatever it does, it causes the 682x duplication you see.
So it's a curl problem. Here's a patch.
>From 74fa25bb5817f38c36c71820731eede6bc3be311 Mon Sep 17 00:00:00 2001
From: Jan Engelhardt
Date: Thu, 2 Mar 2023 16:08:22 +0100
Subject: [P
On Thursday 2023-03-02 16:12, Jan Engelhardt wrote:
>On Thursday 2023-03-02 09:56, Ilmari Lauhakangas wrote:
>> last year I reported a regression in automake:
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59288
>
>One will find that there is a file m4/xc-am-if
On Friday 2023-03-03 09:36, ljh wrote:
>Jacob Bachmeyer wrote:
>>$ (mkdir test-build; cd ./test-build && ../src/configure --enable-assert ...)
>>
>>$ (mkdir release-build; cd ./release-build && ../src/configure
>>--disable-assert ...)
On Friday 2023-03-03 10:40, ljh wrote:
>--disable-assert is 1/3 of the way
and cd is the other 2/3.
On Friday 2023-03-03 11:13, ljh wrote:
>ifdef is not wrong.
But ifdef is not portable.
On Friday 2023-03-03 13:14, ljh wrote:
>Thanks for the hint. I did not know this before.
>
>Found it here, autoconf manual 16.3:
>> cd to the directory where you want the object files and executables to
>> go and run the configure script. configure automatically checks for
>> the source code in
On Sunday 2023-03-26 14:33, Labeeb Asari wrote:
>
>Basically : compile .c source files with gcc, .cu files with nvcc and
>finally link them together with gcc.
>
>I've tried adding a rule to handle .cu files differently and it does create
>object files for it separately. However while linking, lib
Given
a_SOURCES = aprog/main.c aprog/foo.c aprog/bar.c aprog/baz.c ...
The more source files there are to be listed, the longer that line gets,
the bigger the Makefile.am fragment becomes, etc. I am thinking about
how to cut that repetition down. Current automake likely won't have
anyt
On Monday 2023-07-17 06:55, John Darrington wrote:
>Why not just write it as:
>
>a_SOURCES = aprog/main.c \
> aprog/foo.c \
> aprog/bar.c \
> aprog/baz.c ...
You're missing the point.
If you have a hundred, two hundred source files, all the aprog/ prefixes
(and it's rarely *that* short) a
The regex pattern in function scan_variable_expansions() fails to
report a portability warning when a dollar-escaped dollar sign
precedes the variable:
foo_SOURCES = a.c $$$(patsubst a.c,a,b)
---
lib/Automake/Variable.pm | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --g
The regex pattern in function scan_variable_expansions() fails to
report a portability warning when a dollar-escaped dollar sign
precedes the variable:
foo_SOURCES = a.c $$$(patsubst a.c,a,b)
---
lib/Automake/Variable.pm | 5 +++--
t/dollarvar2.sh | 9 +
2 files changed,
On Saturday 2023-09-30 05:27, Dave Hart wrote:
>I've added code to the ntp.org Makefile.am files to ensure the static
>utility library libntp.a is up-to-date for each program that uses it, to
>ensure the build is correct. When building the project, this adds a bunch
>of extra submake invocations
>I didn't explain sufficiently. The submakes I'm talking about are my
>doing, and I want to conditionalize them on whether
>--enable-dependency-tracking is used.
>
>In for example both ntpq/Makefile.am and ntpd/Makefile.am I'm invoking:
>
>(cd ../libntp && make libntp.a)
Yes and if you didn't do
On Friday 2023-12-01 21:13, Mike Frysinger wrote:
>On 17 Jul 2023 16:51, Karl Berry wrote:
>> Hi Jan,
>>
>> Current automake likely won't have anything in store already,
>>
>> Not that I know of.
>>
>> a_SOURCES = $(addprefix aprog/,main.c foo.c bar.c baz.c)
>>
>> I've often wanted th
On Tuesday 2024-04-09 05:37, Jacob Bachmeyer wrote:
>
>> In principle it could be posible to output something different to
>> describe this stramge situation explicitly. For instance, output "via
>> stdin" as a comment, or output `stdin/../filename' as the file name.
>> (Programs that optimize t
On Thursday 2024-07-18 15:40, Zack Weinberg wrote:
>On Thu, Jul 18, 2024, at 5:09 AM, Tijl Coosemans wrote:
>> Automake 1.17 produces a warning for the use of \# here:
>>
>> https://github.com/ddclient/ddclient/blob/d88e6438efbc53e977546693f6835f7517072a06/Makefile.am#L22
>
>subst = sed \
>
Hi,
I observe that automake gives programs inconsistent .o names. For
example:
Result when running make (beautified here):
Expected result:
CC fifo-unblock.o
CCLD fifo-unblock
CC fifo.o
CC launch.o
CCLD ccgfs-fifo
CC
Hi again :)
in a different project, I have a number of files that have the same
filename, but live in different directories, for example
project/module1/hooks.c
project/module1/m1.c
project/module2/hooks.c
project/module2/m2.c
etc.
project/Makefil
On Aug 9 2007 19:08, NightStrike wrote:
>> Unfortunately, it does not seem like the directory is encoded into the
>> object file, hence automake will fail on me since it wants to use
>> hooks.o for both hooks.c files.
>>
>> Is it currently possible to make the directory part of the object name,
>>
Hi,
is there any real difference between $(var) and ${var}, and is the
latter as much POSIX as the first?
thanks,
Jan
--
On Aug 17 2007 22:48, Andreas Schwab wrote:
>Jan Engelhardt <[EMAIL PROTECTED]> writes:
>
>> is there any real difference between $(var) and ${var}, and is the
>> latter as much POSIX as the first?
>
>Depends on the context. For a shell there is a big difference be
Hi,
in the testcase at http://jengelh.hopto.org/f/am.tar.bz2 ,
liba.la does not get installed. What is the cause of this and
how could I fix it?
thanks,
Jan
==
$ ./configure --prefix=$PWD/rt
$ make install
CC a.lo
CC b.lo
CCLD libb.la
CCLD liba.la
CC
Hi,
in a simple Makefile.am with
SUBDIRS = foo
bin_PROGRAMS = bar
how can I achieve that bar will be compiled before operation descends
into foo/?
thanks,
Jan
On Dec 25 2007 17:58, Jan Engelhardt wrote:
>in a simple Makefile.am with
>
> SUBDIRS = foo
> bin_PROGRAMS = bar
>
>how can I achieve that bar will be compiled before operation descends
>into foo/?
Nevermind, just found it in the info pages :)
Something as simp
le.am.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
# All rights are handed to the automake team.
---
automake.in | 91 ++--
lib/am/depend2.am |6 +++
lib/am/library.am |5 +-
lib/am/ltlibrary.am |1
lib/am
On Thursday 2008-10-23 19:20, Ralf Wildenhues wrote:
>
>Anyway, when we use nonconforming constructs then it's probably safer if
>they are default-off, so the developer can choose to enable it and knows
>the limitation. I suppose we can have an Automake option 'silent' or so
>(better name suggest
On Monday 2008-10-27 08:19, Neel Basu wrote:
>On Sunday 26 Oct 2008 11:41:26 pm Ralf Wildenhues wrote:
>
>> $(top_builddir)/cgi++/libcgixx.la:
>> cd $(top_builddir)/cgi++ && $(MAKE) $(AM_MAKEFLAGS) libcgixx.la
>>
>> in the Makefile.am files that need it. If the cgi++ directory has
>> BU
On Friday 2008-10-24 03:19, Jan Engelhardt wrote:
>On Thursday 2008-10-23 19:20, Ralf Wildenhues wrote:
[...]
I noticed that AM_VERBOSE_YACC is not used when in the .l.c and
.y.c rules. Do you know why?
>>> ## In fast-dep mode, we can always use -o.
>>> ## For non-
and at runtime through `make V=level`
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
---
automake.in | 134
lib/am/depend2.am | 21
lib/am/lex.am |3 -
lib/am/library.am |4 -
lib/am/ltlibrary.
Hi,
for shared libraries, it is possible to use
myshared_so_LDFLAGS = -module
to tell automake not to warn about the missing "lib" prefix.
For static libraries however, something like that does not
work since there is no ld involved, and automake warns
about the missing lib prefix. Is the
On Monday 2008-11-10 20:53, Bob Friesenhahn wrote:
> On Mon, 10 Nov 2008, Jan Engelhardt wrote:
>
>> for shared libraries, it is possible to use
>> myshared_so_LDFLAGS = -module
>> to tell automake not to warn about the missing "lib" prefix.
>> For
Hi,
the automake info page has this to say about distcleancheck:
> If you want `distcleancheck' to ignore built files that have not
>been cleaned because they are also part of the distribution, add the
>following definition instead:
>
> distcleancheck_listfiles = \
> find -type f -e
Hi,
here's a problem I just cannot figure out on my own -- distcheck always
fails on data using the following test files:
---<8--- Makefile.am
AUTOMAKE_OPTIONS = foreign subdir-objects
noinst_DATA = foo.txt
--->8---
---<8--- configure.ac
AC_INIT([foo], [0])
AM_INIT_AUTOMAKE([-Wall])
AC_CONFIG
Hi Ralf,
On Friday 2008-11-28 06:25, Ralf Wildenhues wrote:
>* Jan Engelhardt wrote on Thu, Nov 27, 2008 at 11:12:24PM CET:
>>
>> ---<8--- Makefile.am
>> AUTOMAKE_OPTIONS = foreign subdir-objects
>> noinst_DATA = foo.txt
>
>> make distcheck
>
>&
commit 6f949a61df1cfc778ab91de037b611bd8bad3735
Author: Jan Engelhardt <[EMAIL PROTECTED]>
Date: Thu Nov 27 23:28:35 2008 +0100
Add LZIP support
---
ChangeLog | 10 ++
Makefile.in |8 +++-
automake.in |3 ++-
doc/automak
On Friday 2008-11-28 17:21, Bob Friesenhahn wrote:
> Since LZIP support has appeared apparently out of the blue (no
> prior discussion on this list), and Automake already had LZMA
> support, can someone please explain LZIP vs LZMA and why we now
> have at least two LZMA compressed targets?
See h
On Friday 2008-11-28 19:38, Bob Friesenhahn wrote:
> On Fri, 28 Nov 2008, Jan Engelhardt wrote:
>
> It was my impression that Automake adopted LZMA utils without fully
> evaluating the impact. My own package is now distributing .lzma
> packages.
It's only great until somet
On Friday 2008-11-28 20:05, Ralf Wildenhues wrote:
>> 14:04 yaguchi:../test/obj > make distcheck V=2
>> [...]
>> make[1]: Entering directory `/dev/shm/test/obj/foo-0/_build'
>> depbase=`echo foo.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
>> gcc -DPACKAGE_NAME=\"foo\" -DPACKAGE_TARNAME=\"foo\"
On Friday 2008-11-28 20:37, Ralf Wildenhues wrote:
>> When you graph git://dev.medozas.de/pam_mount with `gitk --all` for example,
>> you may find that practice between 0.40--0.43 or 0.45--0.47.
>
>[...] Another thing that bothers me when merging from stable to
>master is that I'm not used to deve
On Friday 2008-11-28 21:37, Bob Friesenhahn wrote:
>
>> > If an archive format was ever offered before, the feeling is that
>> > it must continue to be offered for the rest of time.
>>
>> *sigh* well, everybody is entitled to do his own liking and
>> if that's providing all formats just because.
>
On Saturday 2008-11-29 10:06, Jim Meyering wrote:
>Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>> On Friday 2008-11-28 17:21, Bob Friesenhahn wrote:
>>> Since LZIP support has appeared apparently out of the blue (no
>>> prior discussion on this list), and Automake
On Saturday 2008-11-29 17:04, Bob Friesenhahn wrote:
> On Sat, 29 Nov 2008, Jim Meyering wrote:
>>
>> I have been following lzma-utils development closely for some time,
>> and my impression is that xz obviates lzip. I would not want to
>> encourage use of lzip without a convincing argument to th
On Saturday 2008-11-29 17:30, Ralf Wildenhues wrote:
>> On Friday 2008-11-28 21:37, Bob Friesenhahn wrote:
>> >
>> > It makes sense to me that periodically Automake maintainers make an
>> > evaluation (and with the blessing of the FSF) intentionally
>> > deprecate generation of certain archive typ
On Sunday 2008-11-30 01:52, NightStrike wrote:
>Is the following kosher?
It will produce two 32-bit libraries on all architectures where
gcc defaults to a 32-bit output.
>shell32src=libsrc/shell32.c
>
>lib32_LIBRARIES += lib32/libshell32.a
>lib32_libshell32_a_SOURCES = $shell32src
>lib32_libshe
On Sunday 2008-11-30 02:24, Jan Engelhardt wrote:
>On Sunday 2008-11-30 01:52, NightStrike wrote:
>
>>Is the following kosher?
>
>It will produce two 32-bit libraries on all architectures where
>gcc defaults to a 32-bit output.
(In other words, you are missing -m64. And
On Sunday 2008-11-30 18:07, NightStrike wrote:
>>>
Is the following kosher?
>>>
>>>It will produce two 32-bit libraries on all architectures where
>>>gcc defaults to a 32-bit output.
>>
>> (In other words, you are missing -m64. And perhaps some logic
>> so that lib64 is not built in pure 32-bi
On Wednesday 2008-11-05 09:38, Jan Engelhardt wrote:
>
>third round here of the automake-tranquility patch from me.
>Updates from previous attempts:
>1. using am__ prefix
>2. removed the strange find_link_verbose() function
>3. verbosity selectable in configure.ac too
>
Hi,
at the moment, the pam_mount project uses the following hack to
workaround a libtool warning message:
# Makefile.am (abridged)
bin_PROGRAMS = mount.crypt
mount_crypt_SOURCES = nlt-loop.c ...
lib_LTLIBRARYES = pam_mount.la
pam_mount_la_SO
Hi,
is there a chance automake and/or libtool would support -fPIE for
executables, much like libtool unconditionally turns on -fPIC for shared
libraries?
Hi Ralf,
On Tuesday 2008-12-09 07:15, Ralf Wildenhues wrote:
>* Jan Engelhardt wrote on Tue, Dec 09, 2008 at 12:11:52AM CET:
>>
>> is there a chance automake and/or libtool would support -fPIE for
>> executables, much like libtool unconditionally turns on -fPIC for shared
On Tuesday 2008-12-09 19:50, Ralf Wildenhues wrote:
>> >Just using
>> > ./configure CFLAGS=-fPIE
>> >
>> >should work fine, or put it in target_CFLAGS if you only want some
>> >targets to be PIE. Be sure to use recent Libtool, so that libraries
> ^^^
On Wednesday 2008-12-10 16:04, Bob Friesenhahn wrote:
> On Wed, 10 Dec 2008, Tom Browder wrote:
>>> * Tom Browder wrote on Wed, Dec 10, 2008 at 01:38:53AM CET:
>>> > Is it "legal" to use the "+=" operator in lieu of "\" when listing
>>> > members of a variable in Makefile.am's?
>>>
>>> Yes. In t
On Thursday 2008-12-11 21:38, Monty Taylor wrote:
>Hey all,
>
>I'm wondering if there is a best practice for getting paths such as
>locaeldir or datadir into source code. As it stands now in the Makefile
>I've got:
>
>prefix= /usr/local
>datarootdir= ${prefix}/share
>localedir = ${datarootdir}/lo
On Monday 2008-12-15 08:32, William Pursell wrote:
>Jan Engelhardt wrote:
>
>> third round here of the automake-tranquility patch from me.
>> Updates from previous attempts:
>
>I've been looking through the archive and haven't
>noticed any followup on
On Monday 2008-12-15 21:19, William Pursell wrote:
>
>Thanks for this Jan, it is really nice functionality. I don't
>know if this is a portability issue, but I think it would be nice
>to change $< to $? in this section:
>
>> +'am__1verbose_CCLD_1 = @echo " CCLD" $@ "<-" $<;',
>
On Monday 2008-12-15 21:48, Jan Engelhardt wrote:
>On Monday 2008-12-15 21:19, William Pursell wrote:
>>
>>Thanks for this Jan, it is really nice functionality. I don't
>>know if this is a portability issue, but I think it would be nice
>>to
On Monday 2008-12-22 21:36, Ralf Wildenhues wrote:
>> >On Monday 2008-12-15 21:19, William Pursell wrote:
>>
>> >The make info pages mention that $? expands to “all the prerequisites
>> >that are newer than the target”, and that sounds like there could be
>> >more than just the .c file.
>> >
>> >I
On Friday 2009-01-02 17:33, Matěj Týč wrote:
>Hello,
>I would like to use the AM_COND_IF macro in my configure.ac, but when I
>run autoreconf, I get an error message saying that the macro couldn't be
>found anywhere.
I could not find it in the manual either, so the macro is probably
not the righ
Hi,
given a configure.ac which defines AM_INIT_AUTOMAKE([-Wall]),
running `automake -Wnone` still produces the warnings I had with -Wall.
I think command line should override any earlier flags.
Hi,
I reckon that %-style suffix rules (e.g. "%.o: %.c") are rather
unportable, but I wonder how the old-fashioned suffix rule for
%.1: %.1.php
would look like.
On Friday 2009-01-02 20:26, Matěj Týč wrote:
>> I could not find it in the manual either, so the macro is probably
>> not the right one to start with.
>
>It is in the manual, of course (that's where I have found it). Look
>here:
>http://sources.redhat.com/automake/automake.html#Conditionals
Ah o
On Friday 2009-01-02 20:57, Matěj Týč wrote:
>> Did you try regenerating the aclocal files?- usually done by `autoreconf
>> -fi`.
>
>Yes, I tried it and it did not help, I still get the error. Are there
>any files where the macro is supposed to be defined to check?
>
Grepping in the automake tre
On Tuesday 2009-01-20 10:37, Lorenzo Bettini wrote:
> Hi
>
> I'd need to use the function
>
> g_find_program_in_path ()
>
> in glib, if glib is found in the system...
>
> which is the best way of doing that? using the pkconfig or some specific
> macro
> provided by glib itself?
Yes,
PKG_CONFI
On Sunday 2009-01-25 05:46, Adam Nielsen wrote:
>
>>> x86_64-pc-linux-gnu/bin/ld:
>>> .../lib64/libboost_system-mt-1_37.a(error_code.o): relocation R_X86_64_32S
>>> against `a local symbol' can not be used when making a shared object;
>>> recompile with -fPIC
>>> .../lib64/libboost_system-mt-1_37
On Monday 2009-01-26 01:23, Adam Nielsen wrote:
> x86_64-pc-linux-gnu/bin/ld:
> .../lib64/libboost_system-mt-1_37.a(error_code.o): relocation R_X86_64_32S
> against `a local symbol' can not be used when making a shared object;
> recompile with -fPIC
> .../lib64/libboost_syste
1 - 100 of 150 matches
Mail list logo
