[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Rainer Machne
Subject: Re: [Tinycc-devel] tcc library usage, multiple states
Date: Fri, 18 May 2007 17:15:56 +0200
User-agent: Thunderbird (X11/20070302)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]