Re: [Tinycc-devel] tcc library usage, multiple states

[Rob Landley]

On Friday 18 May 2007 11:15 am, Rainer Machne wrote:
> Hi Rob,
> 
> first: thanks for your help and sorry for the spam filter problems - see 
> below for the response of our sysadmins.
> 
> Temporarily, I just removed the requirement for multiple TCC states in 
> our program, so I don't urgently need it anymore. I just compile the 
> whole thing all together again, even though just one tiny function 
> changes and it would be more elegant to keep also the compiled functions 
> modular ... but we can live with that for the moment.
> 
> >> This also doesn't work for me, although I get different errors:
> >>
> >>  > tcc -L. libtcc_test.c -ltcc1
> >> tcc: file '/usr/lib32/crt1.o' not found
> >> tcc: file '/usr/lib32/crti.o' not found
> > 
> > Sigh.  -L is supposed to add a library, not replace the existing ones.  
> > (Ummm...  lib32?  You're running it on x86-64?)
> 
> No, actually i686. The machine is in principle 64 bit, but was by 
> mistake set up for 32 bit (the only 32bit we currently have). Maybe this 
> causes confusion? (in our network, it's the only well-maintained 32 
> architecture we have, so i am using tcc there - as i didn't want to go 
> through the process of compiling all libraries i need for my project 
> with -m32 on my x86-64).

I'd like to make tcc run on an x86-64 host, which doesn't sound too difficult.  
I'd also like to make it produce x86-64 output which is noticeably more work.

> Actually, crt1.o and crti.o are in /usr/lib, but I get the same error 
> even when explicitly including -L/usr/lib in above command ... ?

Ordering constraints, possibly.

> (please also note that i am a trained biologist, and learning-by-doing 
> about compilation and linking stuff just now)

I've not only tracked lots of this stuff down over the years but I encoded 
rather a lot of it into a wrapper script for gcc which I should really clean 
up at some point.  Both gcc and tcc have approximately the same linking 
requirements...

http://landley.net/hg/firmware?f=6b6822893f99;file=sources/toys/gcc-uClibc.c

> >> However, gcc does it, when I also link to ?dynamic linker/loader? with 
> >> -ldl and not to libtcc1 but to libtcc with
> >>
> >>  > gcc -L. libtcc_test.c -ldl -ltcc
> > 
> > I thought the point of the libc.so linker script was to link 
> > to -ldl "AS_NEEDED".  What distro are you using?
> 
> If that helps you,  I get the following error without -ldl:
> 
> ./libtcc.a(libtcc.o): In function `resolve_sym':
> .../.../tinycc-rl-1.0.0/tcc.h:885: undefined reference to `dlsym'
> ./libtcc.a(libtcc.o): In function `tcc_add_file_internal':
> .../.../tinycc-rl-1.0.0/tcc.c:9079: undefined reference to `dlopen'
> collect2: ld returned 1 exit status
> Exit 1

*shrug*  Ok.

> >>  However, as I get all
> >> your other emails to the list, I think it might have been some temporary
> >> bug in their email filter. ??
> > 
> > You get emails sent by the list's email server because that's coming from 
a 
> > different IP address.  
> 
> I never got your first reply, neither from you nor from the email list. 
> I got all other email list emails since and before then.

The first email I cc'd you, so I don't think the list sent you a copy.  (The 
mailserver can be configured not to send copies to people who are cc'd.  I 
have no control over this, I didn't set up the list.)  The others, I sent 
_just_ to the list.

This one I'm cc'ing you again, so who knows if you'll get it. :)

> > Filtering by mailserver's IP address does not reliably work.  It generates 
> > significant false positives.  My response to these false positives is "oh 
> > well, I didn't have anything of burning importance to say to you anyway, 
I'm 
> > going to go off and do other things".  If your mail server sticks its 
fingers 
> > in its ears when I speak in an attempt to shield you from spam I'm not 
> > sending, this is not my problem.
> >
> 
> Our university sysadmins say they are very sorry and think that this 
> might have happened during a very short period on that day when they had 
> messed up some network mask/ip address ... settings in their spam 
> filter, so that a large range of IP addresses was temporarily blocked. 
> .... grrr.

We'll see.

> Personally, i'd prefer them not do centralized spam filtering at all - 

*shrug*  It works quite well for gmail.

Rob