|Subject:||Re: [Tinycc-devel] Error: File crti.o/crt1.o Not Found and No Function Renaming|
|Date:||Tue, 17 Sep 2013 07:07:38 -0500|
On Mon, Sep 16, 2013 at 3:58 PM, Thomas Preud'homme <address@hidden> wrote:
> Le lundi 16 septembre 2013 17:41:55, Cayce Pollard a écrit :
> > On Mon, Sep 16, 2013 at 8:18 AM, Thomas Preud'homme
> > Thanks! Not sure how to do that but I'm headed to figure it out.
> > Also, for those struggling with an Android port of tcc that find this
> > mailing list, there's a good explanation of the crt* files here:
> > http://dev.gentoo.org/~vapier/crt.txt
> Just add more call to tcc_add_crt in this function at the right place ;)
You say that as if I knew what I was doing :). I did figure it out (I think) but I replaced the crt1.o and crti.o filenames with crtbegin_dynamic.o and crtend_android.o.
This caused a bunch of other errors, while compiling scm but I think they may be related to the KBOX/libfakechroot setup I'm using.
Here are the errors:
.o debug.o scmmain.o
Putting child 0x5ae38 (scmlit) PID 30398 on the chain.
Live child 0x5ae38 (scmlit) PID 30398
/usr/lib/crtbegin_dynamic.o:1: error: unrecognized file type
tcc: error: file 'crtbegin_dynamic.o' not found
tcc: error: file '/project/arm-cc/sysroot/lib//libgcc_s.so.1' not found
tcc: error: undefined symbol 'errno'
tcc: error: undefined symbol '__divsi3'
tcc: error: undefined symbol '__modsi3'
tcc: error: undefined symbol '__aeabi_uidiv'
tcc: error: undefined symbol '__aeabi_uidivmod'
tcc: error: undefined symbol '__aeabi_idiv'
tcc: error: undefined symbol '__aeabi_idivmod'
Reaping losing child 0x5ae38 PID 30398
make: *** [scmlit] Error 1
Removing child 0x5ae38 PID 30398 from chain.
I think I need to compile tcc with paths relative to the libfakechroot environment, according to this section of the documentation:
LD_LIBRARY_PATH , LD_PRELOAD
Fakechroot is implemented by wrapping system calls. This is accomplished by setting LD_LIBRARY_PATH=/usr/lib/fakechroot and LD_PRELOAD=libfakechroot.so. That library is loaded before the system's C library, and so most of the library functions are intercepted by it. If you need to set either LD_LIBRARY_PATH or LD_PRELOAD from within a fakechroot environment, it should be set relative to the given paths, as in LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/foo/bar/
> > > Why is that relevant? Do you need __func__ to be defined and it's not by
> > > tcc?
> > Nope. Sorry about that. In my original email I wrote that I wanted to
> > indicate to cdefs.h that the compiler implemented C99, but I was looking at
> > the wrong section of the code. What I need to do is implement a function
> > rename for tcc and define __GNUC__ as mentioned in your reply.
> > I assume I take care of defining __GNUC__ with -D?
> Since cdefs.h is probably included from many places that's indeed probably the
> best solution. One thing that could be nice is for you to tell upstream
> (google) that tcc can do renaming and tell them how.
I would do that if I knew how tcc could do renaming. I know it can because you pointed me towards the information on how to implement it, but I don't know the details about how it works.
When I said I was new to porting, I really meant I was new to porting. I'm basically learning while doing right now and most of what I'm doing is trial and error. I know the overall concepts but only have rudimentary knowledge about the nuts and bolts.
> Or maybe ask them to add
> one #elif defined(__RENAME) as to let a chance for non gcc compilers to work
> correctly by just defining a __RENAME macro. Then we could add to tcc such a
> define when compiled for android (or at least you could easily patch tcc
> locally to define this macro).
Not sure what the above means, but I'm going to take a guess. Would it mean changing this:
> 255 #else /* _STANDALONE || _KERNEL */
> 256 #define __RENAME(x) no renaming in kernel or standalone
> 257 #endif
To something like this:
> 255 #else
> 256 #define __RENAME(x) /* must be defined by user's compiler */
> 257 #endif
|[Prev in Thread]||Current Thread||[Next in Thread]|