Quick update: Compiling tcc with paths relative to libfakechroot definitely did not work. Got all of the previous undefined symbol errors and more. I also got /usr/lib/crtbegin_dynamic.o:1: error: unrecognized file type tcc: error: file 'crtbegin_dynamic.o' not found tcc: error: file 'crtend_android.o' not found tcc: error: file '/project/arm-cc/sysroot/lib//libgcc_s.so.1' not found On Sep 17, 2013 7:07 AM, "Cayce Pollard" <[email protected]> wrote:
> > > On Mon, Sep 16, 2013 at 3:58 PM, Thomas Preud'homme <[email protected]> > 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 > > <[email protected]>wrote: > > > > > > 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 > > environment > > 257 #endif > > To something like this: > > 255 #else > > 256 #define __RENAME(x) /* must be defined by user's compiler */ > > 257 #endif > > > > > > > Le lundi 16 septembre 2013 17:41:55, Cayce Pollard a écrit : > > On Mon, Sep 16, 2013 at 8:18 AM, Thomas Preud'homme > <[email protected]>wrote: > > > > 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 ;) > > > > 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. 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). > > Best regards, > > Thomas >
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
