Okay, you obviously are at least in charge of final linking and the one object that contains, if nothing else, the lib_archive() function.

Yes... I control EVERYTHING! Muahaha. *erm* Sorry.

How do you make the determination of which archiving function to use? If it's logical, then why not just have lib_archive() figure it out and then call lib_archive_cdr() or lib_archive_dvdr() or lib_archive_ftp() or lib_archive_nfs()? That way you don't have to deal with any of this mess.

Well, if I all included them into one library, then the program would be friggin' huge. (Probably a 2-3 meg file.) There's a reason for this, and unfortunately, it's something I canNOT get around.
In the end, I have four exec's. Normally, clients of mine only get ONE version. However, often they'll upgrade, or change their mind. Now instead of uploading to their site a 3 meg files (complete distribution package) for a new version, where the only thing that changes is the lib_archive() function, I'd like to simply upload a *.so file to replace the one they have. Saves time, and is much simpler.

can I have one of the differently named *.so files (like lib_cdr.so, lib_dvd.so, lib_ftp.so, etc etc..) in the lib directory, and will the executable try whatever file is in there until it finds a lib_archive()

I don't understand your question here. If your intent is to have a different one for each possibility, wouldn't each of them have a lib_archive() in it? Or were you planning to move them in and out of there as needed?

Exactly - they'd ALL have a lib_archive, and depending on their "security level" (read: how much they paid) the program would only use the one it was told to. But all the options are there, in case they want to change.

However, I've been looking at this dlopen() function, and I think it is **EXACTLY** what I've been looking for..
From the looks of it, I can tell it what file to look at, and then what function I need the address for, and go from there..

(See, my company is full of "think for the now" programmers and designers. Have of our 'C' department didn't even know what I was talking about when linking to a library. Every time a new version of a core product is available, we always have a complete new distribution package which ranges from 3-5 megs that we have to upload to clients sites via modem. So, when I started my project (completely on the side, mind you. I don't even work for the programming department) the first thing I was going to do was make it modular - so no matter what version a client has, it runs exactly the same way, and if a new option came along, I could easily make a differen source file to make a *.o file, and simply link it in. In fact, that's how I did my DVD version - CD-R was already done. The whole DVD functions took me abour 2 hours to do. They gave me, and paid me for, a week and a half, because that's how long it normally would have taken the other programmers.
Add, on top of that (and one of the reasons why the exec is so bloated in size) the fact that it uses and orriginated from Informix 4GL - which pre-compiles it down to C with their screen-handling and SQL and Form-handling functions, then links it all together. That's how I started learning C. Everything I know I've learned from taking apart created code, looking at man pages, and asking questions. At one point my C functions that I was using in the program were too fast for the Informix's built-in screen handlers, and I had to slow my C down with usleep() statements.
So, in effect, this is new territory for me, but something that's needed to be done for a while, to keep ME sane trying to upgrade all my clients that run this.)

Sorry for ramblin. :P
Thanks!
Me.