Bruno Haible <[EMAIL PROTECTED]> writes:
> $ ./configure
> $ make
> $ make clean
> $ make CFLAGS="-g -O0"
> be trapped in the link error: xmalloc.c, compiled with optimization, will
> not define xnmalloc, whereas the main sources, compiled without optimization,
> will require it.
How abou
Bruno Haible <[EMAIL PROTECTED]> wrote:
> These are apparently triggered by the use of $(LIBOBJS) in coreutils'
> lib/Makefile.am. Although it is a bit uncommon to combine pieces of
> gnulib and different pieces from outside gnulib in the same library, I
> think gnulib-tool should support this.
>
>
Paul Eggert wrote:
> whenever you get into trouble, just do "make clean"
> and then make with the CFLAGS you prefer.
Many hackers probably use the same approach... Since "make CFLAGS=..." does
not pass the CFLAGS down to subdirectories, the user of a package with
- its main sources in the main d
Bruno Haible <[EMAIL PROTECTED]> writes:
> If you want to force it to a certain value, I think we can consider a
> --enable/--disable-inlining configure option.
Probably not worth the trouble. I can always configure with CC='gcc
-fno-inline'.
> How would you deal with such a link error situatio
Paul Eggert wrote:
> A downside of this approach is that if I compile the xalloc module
> with optimization (so that it does not bother to to generate a extern
> xmalloc function, but simply assumes it's inline) but then compile an
> xalloc user without optimization (so that it assumes there's an e
Bruno Haible <[EMAIL PROTECTED]> writes:
> AC_C_INLINE and gl_INLINE simply answer two different questions.
A problem I have with gl_INLINE is that it decides the value
HAVE_INLINE once, at configure-time. If I compile most of my package
with optimization, but then recompile some modules without
Jim Meyering wrote:
> It is inaccurate and uncharitable to call that automake work
> short-sighted. The problem is that development on that front seems to
> have stalled. Since that part of automake is incomplete, if you don't
> know the history, I can see how you would think it short-sighted.
O
Eric Blake wrote:
> Is it worth trying to override AC_C_INLINE's definition of inline when we
> detect that inline is not supported, such that inline is redefined to the
> empty string, and uses of inline in headers that are not protected by
> HAVE_INLINE will then cause multiple copy link errors i
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> It sounds like the recent trend to remove uses of AC_LIBSOURCE
>> (in favor of listing source file names in each module-file Files: section)
>> is the reason for at least some of my missing dependencies.
>
> The removal of AC_LIBSOURC
Jim Meyering wrote:
> It sounds like the recent trend to remove uses of AC_LIBSOURCE
> (in favor of listing source file names in each module-file Files: section)
> is the reason for at least some of my missing dependencies.
The removal of AC_LIBSOURCE was indeed a major change - for the better
(mo
Eric Blake <[EMAIL PROTECTED]> writes:
> What I should have done, of course, is:
> #if HAVE_INLINE
> static inline unsigned char to_uchar (char ch) { return ch; }
> #else
> # define to_uchar(C) ((unsigned char) (C))
> #endif
No, let's not go that route! We should keep code simple, and not
sprink
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 11/10/2006 4:14 AM:
>
> Without -O, gcc *does* define __NO_INLINE__, so HAVE_INLINE was not
> defined. However, when compiling (with $CFLAGS containing -O), there
> was no external definition of any function like xnmalloc
Jim Meyering wrote:
> >> but there
> >> is a bug (haven't investigated at all yet) whereby most of the generated
> >> dependencies (lib/.deps/*.Po files) are not included into the Makefile.
I agree with Ralf that it's most likely tied to the issue I reported two
days ago: In summary (thanks Ralf f
Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> Hello Jim,
>
> * Jim Meyering wrote on Fri, Nov 10, 2006 at 03:53:42PM CET:
>>
>> I did not run "make clean", but did ensure that config.h was updated.
>> That alone should have caused all "old" .o files to be rebuilt, but there
>> is a bug (haven't inv
Hello Jim,
* Jim Meyering wrote on Fri, Nov 10, 2006 at 03:53:42PM CET:
>
> I did not run "make clean", but did ensure that config.h was updated.
> That alone should have caused all "old" .o files to be rebuilt, but there
> is a bug (haven't investigated at all yet) whereby most of the generated
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> 2006-11-10 Jim Meyering <[EMAIL PROTECTED]>
>>
>> * m4/inline.m4 (gl_INLINE): Check with the compiler, not cpp,
>> so that relevant options in CFLAGS (like -O, -fno-inline) are
>> taken into account.
>
> Thanks again
Jim Meyering wrote:
> 2006-11-10 Jim Meyering <[EMAIL PROTECTED]>
>
> * m4/inline.m4 (gl_INLINE): Check with the compiler, not cpp,
> so that relevant options in CFLAGS (like -O, -fno-inline) are
> taken into account.
Thanks again! I applied this patch, with added comments, an
The gl_INLINE macro was failing to define HAVE_INLINE,
and that led to link errors when building coreutils with CFLAGS=-O.
gl_INLINE used cpp and $CPPFLAGS, and since the latter doesn't
include $CFLAGS, it missed the critical -O option.
Without -O, gcc *does* define __NO_INLINE__, so HAVE_INLINE w
18 matches
Mail list logo
