- Status Unconfirmed
- Percent Complete
- Task Type Bugs
- Category Infrastructure → Build environment
- Assigned To No-one
- Operating System All players
- Severity Low
- Priority Very Low
- Reported Version Daily build (which?)
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
Opened by Peter D. - 2008-04-20
Last edited by Steve Bavin - 2008-05-08
FS#8913 - compilation error due to GNU core utils BLOCK_SIZE value (and suggested fix)
Hi,
There is a compilation problem when the environment variable BLOCK_SIZE is set. It gave me errors about a comma.
This can be set or cleared systematically or on a command by command basis.
Suggestion one; unset BLOCK_SIZE and its relatives high in the build chain, but be prepared for POSIX to bite with 512 byte blocks.
Suggestion two; set LS_BLOCK_SIZE=1 high in the build chain. (And DF_BLOCK_SIZE=1024 and DU_BLOCK_SIZE=1024 ?)
Suggestion three; edit apps/lang/Makefile so that
$(SILENT)echo “#define MAX_LANGUAGE_SIZE `ls -ln $(OBJDIR)/* | awk ‘{print $$5}’ | sort -n | tail -1`” > $(HEADER)
becomes
$(SILENT)echo “#define MAX_LANGUAGE_SIZE `ls -ln –block-size=1 $(OBJDIR)/* | awk ‘{print $$5}’ | sort -n | tail -1`” > $(HEADER)
or
$(SILENT)echo “#define MAX_LANGUAGE_SIZE `LS_BLOCK_SIZE=1 ls -ln $(OBJDIR)/* | awk ‘{print $$5}’ | sort -n | tail -1`” > $(HEADER)
Suggestion four; just tell people that they are not allowed to have commas in their core utilities output (and be prepared to be bitten badly if the default block size ever changes).
BTW I *like* having thousands separators on my command line, so I have
export BLOCK_SIZE=\'1 export DF_BLOCK_SIZE=\'M
in my /etc/bashrc file.
Thank you for reporting this.
The fix is not quite that simple though. For GNU ls, –block-size or LS_BLOCK_SIZE can be used. But BSD ls (OSX) does not have a –block-size parameter and does not accept a BLOCKSIZE value of 1.
We could use the -k parameter which is recognized by both GNU and BSD ls, but then we’ll lose some ram due to the -k parameter always rounding up to the nearest kilobyte.