Game Development Community

gcc3.2 oddness

by Luigi Rosso · in Technical Issues · 01/30/2003 (5:18 pm) · 7 replies

I've just recently started shifting most of my cgi work to C++. Things were going fine till I tried to include Mysql++ into my projects. I had to update my gcc compiler to 3.2, update all the Mysql++ sources to gcc3.2 compatible, finally compiled it all. This is the first time I did this on linux, forgive me if I'm stating the obvious.

Now unfortunately I get undefined references in objects like ccUCHpZr.o to std::ios_base::Init::Init and so on. Looks like some library isn't linking properly? It compiles fine if I only include stdio without the mysql++ header files.

If I compile it with g++, things go fine, but when I try to run the binary I get: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory.

I'm sure I compiled libstdc though, in fact libstdc++.so.5 is located in /usr/local/lib.

Can anyone shed some light?

Thanks,

Luigi

#1
01/30/2003 (6:25 pm)
The g++ compile is working it just can't find gcc3's libstdc++.

Make sure /usr/local/lib is in your /etc/ld.so.conf file. Then run ldconfig -v as root. Then try to run the binary again.

If you still get errors you may need to set LD_LIBRARY_PATH to include /usr/local/lib
#2
01/30/2003 (6:53 pm)
Excellent! I'd tried adding /usr/local/lib to my ld.so.conf file. But I didn't know how to make the changes take effect (didn't want to reboot the machine, it's not local).

It runs fine now when I include the mysql++ headers. I get compiler errors when trying to use the objects defined in the headers though. Still a bad library link? Here's what the errors looks like:

/tmp/ccoh4h3u.o: In function 'main':
/tmp/ccoh4h3u.o(.text+0x45): undefined reference to 'MysqlConnection::MysqlConnection[in-charge](char const*, char const*, char const*, char const*, bool)'
/tmp/ccoh4h3u.o(.text+0x67): undefined reference to 'MysqlConnection::~MysqlConnection [in-charge]()'
collect2: ld returned 1 exit status
#3
01/30/2003 (10:19 pm)
to update your libs, you have to run 'ldconfig' as root.

Also, it seems that the linker can't find your mysql/mysql++ libs...you may want to check where they are as well. If you compiled them by hand, they might also be in /usr/local/lib, which should be solved if you run ldconfig
#4
01/31/2003 (1:56 am)
I'm doing everything as root. I'd already resolved /usr/local/lib/ and that fixed the shared library problem for libstdc++.so.5. I'm going to try to see if I can find in which lib those functions are located.
#5
01/31/2003 (3:30 am)
I managed to get it to work, simply told it to link the mysql++ lib. I'd incorrectly assumed the header file would've done that automatically.

Works swell, thanks for the help!
#6
05/01/2003 (6:00 pm)
I don't want to start a flame, or an argument that can go down in flames at all. But...

Why code CGI programs in C++? In fact, why code CGI programs whatsoever? Your turnaround time for complicated CGI development will be much longer than if you chose to use something such as modperl, or php under apache. PHP was made for web programming, and perl has some really good web modules, such as HTML::Mason.

CGI has serious performance problems, due to the child-spawning for each request. Unless of course, you are building native apache handlers (which from your post, doesn't seem to be the case).

Honestly, the time it will take you to learn the basics behind a scripting language such as perl or php in a web environment will be well-spent. You will find that you have a much easier to maintain system. And if there really is a need for C/C++ in that environment, consider building your logic/code as modules for PHP, or perl, and then use it from within the scripting languages.
#7
05/02/2003 (3:10 am)
I do use PHP for web development (simple and powerful) but certain costly operations (for example search word processing for indexed search engines, or any lengthy database optimizations/modifications which need to be run on, for example, large ecommerce sites) would be better done in the background and as quickly/efficiently as possible.

The processes are only spawned when needed (for example a submission to the database, in a forum it'd be a post...if you've ever seen phpbb you'll note posting takes quite a bit of time on large forums, that's due to the posting script updating the search engine and stalling the user...it'd be much better to simply call the script through a shell command and return. Even more efficient, evoke a compiled binary).

You could just as well use PERL (and compile it if you wish) but why? I don't need all the functionality, all I need (in this case) is a connection to MySQL and I can handle the rest of the processing without other libraries. I'm not doing anything extremely complex which would save development time in PHP or PERL. Anything which can be done that way should be but if I can get the extra performance at no time loss, then why not? And if the tradeoff is some extra dev time for a faster and more efficient system then I wouldn't even judge it a time loss.