Despite being documented as the place for submitting bug reports and
patches, it seems like the sf.net bug tracker isn't get much attention,
so here it is: http://sourceforge.net/p/flac/bugs/400/
During x86-windows builds using mingw or mingw-w64, nasm complains:
nasm.h:83: warning: COFF section names limited to 8 characters: truncating
I think the section .note.GNU-stack stuff aren't needed for win32 and
should possibly be disabled just as they are for aout. There are also
warnings like:
bitreader_asm.nasm:593: warning: label alone on a line without a colon
might be in error
cpu_asm.nasm:118: warning: label alone on a line without a colon might
be in error
fixed_asm.nasm:309: warning: label alone on a line without a colon
might be in error
lpc_asm.nasm:1508: warning: label alone on a line without a colon
might be in error
stream_encoder_asm.nasm:156: warning: label alone on a line without a
colon might be in error
... all of which are for "end" and actually harmless (just annoying.)
I suggest that .note.GNU-stack be limited to elf targets, like:
diff --git a/src/libFLAC/ia32/nasm.h b/src/libFLAC/ia32/nasm.h
index abd01c4..0ae887c 100644
--- a/src/libFLAC/ia32/nasm.h
+++ b/src/libFLAC/ia32/nasm.h
@@ -79,7 +79,7 @@ _%1:
%1:
%endmacro
-%ifndef OBJ_FORMAT_aout
+%ifdef OBJ_FORMAT_elf
section .note.GNU-stack progbits noalloc noexec nowrite align=1
%endif
And the thing is worse with OSX/x86 builds. Tried a linux-hosted cross-
compile, got the following:
nasm.h:83: panic: invalid section name .note.GNU-stack
make[4]: *** [bitreader_asm.lo] Error 1
After commenting out line #83 of nasm.h, got the following:
bitreader_asm.nasm:36: warning: label alone on a line without a colon
might be in error
bitreader_asm.nasm:43: warning: label alone on a line without a colon
might be in error
bitreader_asm.nasm:52: error: The Mach-O output format does not
support any special symbol types
bitreader_asm.nasm:593: warning: label alone on a line without a colon
might be in error
make[4]: *** [bitreader_asm.lo] Error 1
Notice that in both cases, the %error from line #54 of nasm.h does not trigger.
The thing of course can be compiled by configuring --disable-asm-optimizations,
no arguments there, but it would have been better if the configury had disabled
it automagically.
Regards.
--
O.S.