[prev in list] [next in list] [prev in thread] [next in thread] 

List:       glibc-help
Subject:    glibc port to non-linux platform
From:       jhlaros () sandia ! gov (James Laros)
Date:       2008-10-23 15:36:00
Message-ID: 49009BAD.1090604 () sandia ! gov
[Download RAW message or body]



Carlos O'Donell wrote:
> On Wed, Oct 22, 2008 at 7:12 PM, James Laros <jhlaros@sandia.gov> wrote:
>   
>> The build fails with the following error:
>> make[5]: Leaving directory
>> `/rsc/home/jhlaros/CNW_SVN_glibc/trunk/pe/computelibs/glibc/ctype'
>> make -C ../elf
>> objdir=/rsc/home/jhlaros/CNW_SVN_glibc/trunk/pe/computelibs/glibc/build/cnos64
>> -f Makefile -f ../elf/rtld-Rules rtld-all rtld-modules='rtld-dl-profstub.os
>> rtld-dl-libc.os rtld-dl-open.os rtld-dl-close.os'
>> make[5]: Entering directory
>> `/rsc/home/jhlaros/CNW_SVN_glibc/trunk/pe/computelibs/glibc/elf'
>> ../elf/rtld-Rules:34: *** missing separator.  Stop.
>> make[4]: ***
>> [/rsc/home/jhlaros/CNW_SVN_glibc/trunk/pe/computelibs/glibc/build/cnos64/elf/rtld-dl-profstub.os]
>> Error 2
>> make[3]: ***
>> [/rsc/home/jhlaros/CNW_SVN_glibc/trunk/pe/computelibs/glibc/build/cnos64/elf/rtld-libc.a]
>> Error 2
>> make[2]: *** [elf/subdir_lib] Error 2
>> make[1]: *** [install] Error 2
>> make: *** [glibc_for_catamount_apps] Error 2
>> make[5]: Leaving directory
>> `/rsc/home/jhlaros/CNW_SVN_glibc/trunk/pe/computelibs/glibc/elf'
>> make[4]: Leaving directory
>> `/rsc/home/jhlaros/CNW_SVN_glibc/trunk/pe/computelibs/glibc/elf'
>> make[3]: Leaving directory
>> `/rsc/home/jhlaros/CNW_SVN_glibc/trunk/pe/computelibs/glibc/elf'
>> make[2]: Leaving directory
>> `/rsc/home/jhlaros/CNW_SVN_glibc/trunk/pe/computelibs/glibc'
>>
>>
>> My understanding is this happens because at this point the build should not
>> descend into the subdir elf as evidenced by this in elf/rtld-Rules file
>> lines:
>>
>> ifndef rtld-subdirs
>> error This is makefile is a subroutine of elf/Makefile not to be used
>> directly
>> endif
>>     
>
> This rule guards against rtld-Rules being used by any other Makefile
> from any other directory. Only elf/Makefile may use elf/rtld-Rules.
> This rule is not your problem.
>
>   
>> My guess is that in a typical environment the build will not attempt to
>> enter elf. I have built for a Linux client as a sanity check and in fact the
>> rtld-subdirs at the bottom of build/elf/librtld.mk does not include elf.
>>     
>
> Almost. You are already in elf/, and you re-running a build on a
> subset of the top-level directories (rtld-subdirs) to build the object
> files you need. If elf appears in rtld-subdirs then the rebuild would
> recurse forever. You need to figure out why the rule
> $(objpfx)librtld.mk: in elf/Makefile is adding elf to the rtld-subdirs
> variable.
>
> e.g.
> Why is this:
>         echo rtld-subdirs = `LC_ALL=C sed 's/^rtld-\([^ ]*\).*$$/\1/' $@T \
>                              | LC_ALL=C sort -u` >> $@T
> adding elf to your list of directories.
>   

I believe this is because of the limited environment of my target. Since 
it cannot resolve these symbols they first appear in the librtld.map and 
subsequently in the librtld.mk as you pointed out. If I am correct about 
my assumption the question is how to get around it? I am thinking that 
since the glibc build can't get what it wants, for example 
dlopen/dlclose it is building it to include in its libs. Does this sound 
correct?

Snippet from librtld.map
/rsc/home/jhlaros/CNW_SVN_glibc/trunk/pe/computelibs/glibc/build/cnos64/libc_pic.a(dl-open.os)
                              
/rsc/home/jhlaros/CNW_SVN_glibc/trunk/pe/computelibs/glibc/build/cnos64/libc_pic.a(dl-libc.os) 
(_dl_open)
/rsc/home/jhlaros/CNW_SVN_glibc/trunk/pe/computelibs/glibc/build/cnos64/libc_pic.a(dl-close.os)
                              
/rsc/home/jhlaros/CNW_SVN_glibc/trunk/pe/computelibs/glibc/build/cnos64/libc_pic.a(dl-libc.os) 
(_dl_close)

Which causes the addition of elf as a subdir in librtld.mk.
I think this answers what you asked no?

Thanks for responding
Jim
> Cheers,
> Carlos.
>
>   


[prev in list] [next in list] [prev in thread] [next in thread]