🚀 go-pugleaf

"Bob Gonder" <notbg@notmindspring.invalid> wrote in message
news:ncfi01dumn3cn7h27dsm4je1vbkfh7ako1@4ax.com...

> Sorry, in my world, different modules produce different OBJs

Yes, but that doesn't matter in this case.  #define statements are processed
by the precompiler before the compiler then processes the actual source
code.  Once a #define has been declared, it is global for the entire
project, and as such affects all units that are compiled for the project.

> So a module that includes <Indy> and uses Indy functions
> should compile, and a module that contains <winsock> and
> calls naked sock functions should compile.

Not if the Indy unit makes winsock2.h be included by the precompiler before
winsock.h can be included.  Otherwise, winsock2.h prevents winsock.h from
working properly, regardless of which modules it is used in.

> The linker should be able to combine them.

The problem occurs before the linking stage.

> But I wonder how it would decide which Sock.DLL to bind each obj to.

That depends on which .lib files are included into the project.  The
compiler just tells the linker which functions are used.  The linker then
has to decide where those functions are located.

> 'Course, it'd be easier for the OP to just use the winsock2
> functions.

The OP does not have a choice in that matter.  winsock.h is being included
by the VCL.  The OP is mixing Borland's components with Indy's components.

> Or the Indy functions as you mentioned.

That would mean ripping out possible winsock.h-based code and libraries from
the project and just use Indy exclusively.


Gambit