BusyBox Bug and Patch Tracking
BusyBox
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0005264 [uClibc] Other minor always 10-06-08 01:31 10-08-08 12:03
Reporter chrisz View Status public  
Assigned To uClibc
Priority normal Resolution fixed  
Status closed   Product Version 0.9.30
Summary 0005264: Can not build uClibc with locale support without "make distclean" every time
Description This is a minor issue but is taking up much of my time while trying to sort through problems.

When compiling with locale support, if I don't do a "make distclean" before every build, the compile of uClibc fails with:

extra/locale/gen_wc8bit.c:21:29: error: ./include/bits/uClibc_ctype.h: No such file or directory

I'm sure there is an easier way to get around this problem than a "make distclean" at the root level, but the Makefiles are complicated and I can't find the correct rule to fix this.

Can anyone tell me how to get around this issue in a more sane manner?

Thanks,

Chris
Additional Information
Attached Files

- Relationships

- Notes
(0012804)
carmelo73
10-06-08 01:41

Hi, I've seen this while compiling with make -j 2. Is this your case ?
It seems to be caused by wrong value of top_scrdir when doing parallel compilation.
 
(0012814)
chrisz
10-06-08 04:25

Carmello,

I'm not using parallel compile, but you are correct that the direct cause appears to be gen_wc8bit trying to include ./include/bits/uClibc_ctype.h, when it should be trying to include ../../include/bits/uClibc_ctype.h. This appears to be set in the Makefile.in directory in extra/locale

Interestingly, the reason why it works with a "make distclean" is because the make rules for some reason do not try and build the targets c8tables.h, wctables.h, locale_tables.h, or lt_defines.h

Commenting out the dependencies and associated rules for these targets in extra/locale/Makefile.in allows the compile to complete with no obvious differences from that when you do a "make distclean" at the root.

I am curious to know the purpose of these files.
 
(0012824)
carmelo73
10-06-08 05:33

I usually build with locale support, and never seen this before (unless parallel build).
From which directory do you compile ?

These files are used for creating locale data structured to be included within the libc.so.0, unless you use pregenerated files.
 
(0012834)
chrisz
10-06-08 06:47

Carmello,

Thank you for your assistance with this. I'm not sure how to reconcile what I'm seeing with your experiences. I always try and compile from the top directory of the source tree, in this case uClibc-0.9.30-rc1.

Based on your conviction that the Makefile was correct, I went ahead and restored it to its original form, except I changed line 15 in extra/locale/Makefile.in to read ../../include/bits/uClibc_ctype.h instead of the default $(top_builddir)include/bits/uClibc_ctype.h. I also verified $(top_builddir) is set to "./" at this point in the build process, which concurs with the error message I am seeing "can not open ./include/bits/uClibc_ctype.h".

After making the change, the Makefile works as expected, and gen_wc8bit compiles and runs normally. Just to be sure, I ran make -j 1 to be absolutely certain it was not a parallel compile issue, and I got the same result.

If you have a chance, can you check and let me know what the variable $(top_builddir) is set to in your environment at the time it tries to make gen_wc8bit? I have to believe if it works for you and does not for me, there must be some environmental differences.

Thanks again for your help.

Chris
 
(0012844)
bernhardf
10-06-08 06:55

Can you please try with current trunk? There was a dependency fix applied since the -rc1.

TIA,
 
(0012954)
egtvedt
10-07-08 00:30

The Makefile stuff for locale is tricky, it seems to also miss a "-I." when compiling the stuff in extra/locale/. GCC will actually switch into the directory extra/locale before compiling, so then supplying ./include/bits/uClibc_ctype.h is not the correct path to this include file.

If you add "-I." to the CFLAGS in extra/locale/Makefile.in it gets past this, but then fails later due to path issues.

As mentioned, I also think the top_builddir and top_srcdir is set wrong. Perhaps the main Makefile does some stuff in extra/locale before the Makefile there is included?

I am trying to figure this one out, as this is the only thing stopping me getting locale to work.
 
(0012964)
carmelo73
10-07-08 00:57

In my environment (nptl branch) I don't have problem with top_srcdir and top_buildir as you can see from the log below:

[SNIP]

  LN include/sys/ucontext.h
  LN include/sys/user.h
  LN include/bits/local_lim.h
  LN include/bits/posix_opt.h
gcc ../../extra/locale/gen_wc8bit.c -o ../../extra/locale/gen_wc8bit -O2 -Wall -D__UCLIBC_GEN_LOCALE -DUCLIBC_CTYPE_HEADER='"../../include/bits/uClibc_ctype.h"' -DCTYPE_PACKED=1 -DDO_WIDE_CHAR=1
../../extra/locale/gen_wc8bit.c: In function 'main':
../../extra/locale/gen_wc8bit.c:356: warning: array subscript is above array bounds
../../extra/locale/gen_wc8bit.c:415: warning: array subscript is above array bounds
../../extra/locale/gen_wc8bit.c:481: warning: array subscript is above array bounds
find ../../extra/locale/charmaps -name '*.pairs' | sort > ../../extra/locale/codesets.txt
../../extra/locale/gen_wc8bit `cat ../../extra/locale/codesets.txt`

The only issue appears if trying to do a parallel build as I said.

My branch is aligned with trunk... anyway I'll check again.
 
(0013134)
bernhardf
10-08-08 12:03

This is supposedly fixed in r23626. Please verify and reopen this issue otherwise.
thanks,
 

- Issue History
Date Modified Username Field Change
10-06-08 01:31 chrisz New Issue
10-06-08 01:31 chrisz Status new => assigned
10-06-08 01:31 chrisz Assigned To  => uClibc
10-06-08 01:41 carmelo73 Note Added: 0012804
10-06-08 04:25 chrisz Note Added: 0012814
10-06-08 05:33 carmelo73 Note Added: 0012824
10-06-08 06:47 chrisz Note Added: 0012834
10-06-08 06:55 bernhardf Note Added: 0012844
10-07-08 00:30 egtvedt Note Added: 0012954
10-07-08 00:57 carmelo73 Note Added: 0012964
10-08-08 12:03 bernhardf Status assigned => closed
10-08-08 12:03 bernhardf Note Added: 0013134
10-08-08 12:03 bernhardf Resolution open => fixed
10-08-08 12:03 bernhardf Fixed in Version  => 0.9.30


Copyright © 2000 - 2006 Mantis Group
Powered by Mantis Bugtracker