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

[Rainer Machne]

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).

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 ... ?

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


> > In file included from libtcc_test.c:6:
> > In file included from /usr/include/stdlib.h:438:
> > In file included from /usr/include/sys/types.h:270:
> > /usr/include/bits/pthreadtypes.h:69: identifier expected
> >
> > 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


> > If my address still doesn't work for you, you could CC it to "a9404947
> > ... unet.univie.ac.at" and "rainer.machne ... univie.ac.at" (with ...
> > replaced by @), but that is the same email server.
> And the attempts I made to send to that bounced too.

Still? Please confirm if this still happens! As said below, sysadmins 
told us that this was a temporary problem. Use rmachne ... lo-res.org 
instead.

> >  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.


You don't get anything sent to your email server from
> my email server because the IP address my mail server is on changed last year 
> (when it went from DSL to FIOS), and the new IP address was apparently at one 
> point dynamically handed out by an ISP for DHCP.  This has not been the case 
> since it was moved to FIOS use, and it's not _my_ problem to convince your 
> mail server that I'm _not_ a spammer.
>
> 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.

Personally, i'd prefer them not do centralized spam filtering at all - 
at least not without individual consent. We have quite good filters here 
locally at our institute. I guess they are worried about some viruses 
spreading internally ... blabla. we are using linux here, so ... but 
anyways ...

Thanks, Rainer