Subj : Re: __turboFloat problem
To   : borland.public.cpp.borlandcpp
From : "Ed Mulroy [TeamB]" <ed@mulroyREMOVETHESECHARS.org>
Date : Wed Sep 10 2003 09:03 am

> bcc32 -c -tWM -DMSC_CORE_BC_EXT example.c

This is C code so you do not want runtime type id or exception handling.
Consider adding the options -RT- -x-

> ilink32 -Tpd c0d32 example,example.pyd,,mypylib
> import32 cw32mt,example
> ? This gives a whole lot more of errors, including the __turboFloat one.

The whole lot more errors are what you should have been seeing all along.
The startup code must be the first object file linked or the target may have
subtle, difficult to troubleshoot problems.

Do the two machines have different compiler versions?

Could one of the machines not have a compiler patch or update installed that
the other one has installed?  If I recall correctly the patches also updated
the libraries.

I do not know the effect of defining the macro MSC_CORE_BC_EXT.

Go to the command line and select the compiler's LIB directory.  Give this
command

  tlib /C cw32mt.lib , cw32mt.lst

Pull the cw32mt.lst file up in an editor and confirm if there is a public
symbol named __turboFloat in that library.

I am uncomfortable with doing this for production code but for the time
being you might consider adding cw32mti.lib AFTER cw32mt.lib in the list of
libraries given to ilink32 (so unresolved items get picked up by the 'i'
version).  Remember that dynamic linked means the RTL DLL's must be on the
machine and, if the exe or dll frees something the other allocated, then
memmgr.lib must be linked BEFORE all but noeh32.lib for both so that the exe
and dll share the same memory manager even if static linked.

..  Ed

> Martin Schneider wrote in message
> news:bjmecg$ktjn2$1@ID-119488.news.uni-berlin.de...
> > ...the startup code must be first in the list of object
> > files.
>
> ilink32 -Tpd c0d32 example,example.pyd,,mypylib
> import32 cw32mt,example
>
> ? This gives a whole lot more of errors, including the __turboFloat one.
>
> > You haven't showed the command lines used to compile ...
>
> bcc32 -c -tWM -DMSC_CORE_BC_EXT example.c
>
> which is _identical_ on both systems. But: linking cw32mti solved
> the problem! Thank you for the idea.
>
> How can this be? Identical source, identical compiler, linker, OS,
> etc, and on one machine you have to do a static link and on the
> other a dynamic one to avoid this error?

.