This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ld: cannot find -lc


I was able to get it to work. The main change I made was to use Linux
Kernel 2.6.27 (the old LTS) instead of 2.6.24

I'll experiment some more to see if this is really the reason why the
GCC build was breaking, but just wanted to mention that this doesn't
appear to be a problem with crosstool-ng.

Thanks,

Razvan.

2010/11/28 Răzvan Surdulescu <surdules@gmail.com>:
> I looked at the crosstool-ng source and found that the script
> crosstoolng-1.9.0/scripts/build/cc/gcc.sh actively changes libgcc.mk
> by removing the "-lc" line using a call to sed, around line 278.
>
> I changed this script and replaced the call to "sed" with:
>
> ? ? ? ?echo "DEBUG: running sed:"
> ? ? ? ?CT_DoExecLog ALL sed -r -i -e 's@-lc@@g' gcc/${libgcc_rule}
>
> Then, I looked at the build.log, and noticed that, after sed runs (and
> correctly modified libgcc.mk by removing the "-lc"), the file
> libgcc.mk is actually generated *again* lower below. Naturally, this
> reintroduces the "-lc" link parameter, and causes the build to fail.
>
> The second time libgcc.mk is generated (after the sed) appears to be
> right after the fixincludes target is executed. In the log, this
> second re-generation of libgcc.mk is preceded by:
>
> ...
> [ALL ?] ? ?rm -f include/README
> [ALL ?] ? ?cp /home/razvans/caanoo/my-ct-ng/targets/src/gcc-4.2.4/gcc/../fixincludes/README-fixinc
> include/README
> [ALL ?] ? ?chmod a+r include/README
> [ALL ?] ? ?echo timestamp > stmp-int-hdrs
> [libgcc.mk is re-generated here]
>
> I don't have time to go deeper into this tonight, but maybe someone
> more knowledgeable about the GCC build process can look into it?
>
> Thanks,
>
> Razvan.
>
> 2010/11/28 Răzvan Surdulescu <surdules@gmail.com>:
>> 2010/11/28 Răzvan Surdulescu <surdules@gmail.com>:
>>>> I installed a clean maverick-32 chroot, and with your .config (extracted
>>>> from the build log), shared core cc builds OK here. It fails in glibc-2.7,
>>>> though.
>>>>
>>>> glibc-2.7 is marked OBSOLETE, and I am not spending time fixing it. If you
>>>> have a fix, then I will apply it, but I won't investigate myself.
>>>>
>>>> I upgraded to glibc-2.8, and the build completed.
>>>
>>> I will try with glibc-2.8 and see if that works. If it does, then I
>>> will try to find a fix for glibc-2.7
>>
>> I tried to build with glibc-2.8, and it fails again, same error (can't
>> find "-lc" when linking). Here is the build log:
>> http://www.sonic.net/~surdules/build.log.gz
>>
>> Looking more closely, the failure happens during the "shared core C
>> compiler", which I think is before the glibc step (this is what was
>> happening before as well, when I was using glibc-2.7).
>>
>> What additional information can I provide to help track this down?
>>
>> I imagine there is some kind of Makefile in the shared cc build that
>> specifies "-lc"; would it help to diff some of my configs/Makefile(s)
>> against the ones that worked for you in the chroot install? I can
>> upload additional files for this purpose if you want.
>>
>> Thanks,
>>
>> Razvan.
>>
>

--
For unsubscribe information see http://sourceware.org/lists.html#faq


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]