185d
Subj : Re: problems with command line linker
To   : borland.public.cpp.borlandcpp
From : JackRosenbloom
Date : Thu Jun 02 2005 10:23 am

Hi Ed,

Thanks for your feedback.  I believe I doing the equivalent to your 
suggestions.  My command lines are too long requiring response files. 
Here's exactly what I am doing:

*********** COMPILE *******************
I have a file called options.cfg which contains a single physical line 
(email broke this into multiple lines)


-c -W- -R -v -vi -dc- -1 -a2 -w-rch -H- -x- -RT- -mm! -Od -N -ff- -R -ml 
-f -dc -Ff=2000 
-IC:\BC45\INCLUDE;C:\URC\KERNEL23\DISPLAY;C:\URC\KERNEL23 
-D__TARGET_ENVIRONMENT__=__PC_DEBUG__


bcc @options.cfg -opc_obj\my_file.obj my_file.cpp

***************** LINK *************************

I have a file called link.rsp


-v -LC:\BC45\LIB -c -Tde  +
c:\bc45\lib\c0l.obj +
c:\projects\plm\src23\pc_obj\appl.obj +
c:\projects\plm\src23\pc_obj\init.obj +
c:\projects\plm\src23\pc_obj\Analog.obj +
c:\projects\plm\src23\pc_obj\Auto_spl.obj +
c:\projects\plm\src23\pc_obj\Delamin.obj +
c:\projects\plm\src23\pc_obj\Diag.obj +
c:\projects\plm\src23\pc_obj\err_str.obj +
c:\projects\plm\src23\pc_obj\events.obj +
c:\projects\plm\src23\pc_obj\evt_gen.obj +
c:\projects\plm\src23\pc_obj\History.obj +
c:\projects\plm\src23\pc_obj\Length.obj +
c:\projects\plm\src23\pc_obj\Len_cntl.obj +
c:\projects\plm\src23\pc_obj\Len_eval.obj +
c:\projects\plm\src23\pc_obj\len_util.obj +
c:\projects\plm\src23\pc_obj\L_opi.obj +
c:\projects\plm\src23\pc_obj\L_table.obj +
c:\projects\plm\src23\pc_obj\Monitor.obj +
c:\projects\plm\src23\pc_obj\plm_evt.obj +
c:\projects\plm\src23\pc_obj\queue.obj +
c:\projects\plm\src23\pc_obj\Relay_io.obj +
c:\projects\plm\src23\pc_obj\repeat.obj +
c:\projects\plm\src23\pc_obj\Report.obj +
c:\projects\plm\src23\pc_obj\rewinder.obj +
c:\projects\plm\src23\pc_obj\Speed.obj +
c:\projects\plm\src23\pc_obj\Status.obj +
c:\projects\plm\src23\pc_obj\Tension.obj +
c:\projects\plm\src23\pc_obj\unwinder.obj +
c:\projects\plm\src23\pc_obj\unw_plm.obj +
c:\projects\plm\src23\pc_obj\Upload.obj +
c:\projects\plm\src23\pc_obj\Utils.obj +
c:\projects\plm\src23\pc_obj\wash_dry.obj +
c:\projects\plm\src23\pc_obj\L_disply.obj +
c:\projects\plm\src23\pc_obj\Control.obj +
c:\projects\plm\src23\pc_obj\Sim_8904.obj +
c:\projects\plm\src23\pc_obj\ten_stab.obj +
c:\projects\plm\src23\pc_obj\Urc2_sim.obj
runonpc.exe,runonpc.map
c:\urc\kernel23\bc_lib\runonpc.lib +
emu.lib + mathl.lib + cl.lib


Tlink @link.rsp

****************************************

Also, I wasn't clear describing one of the errors.  The only duplication 
of symbols between the library and my application code is functions, not 
variables.  I have re-defined some functions to use instead of the 
library's copy of these functions.  The library source code containing 
the redefined functions also contain other functions which are not 
re-defined and needed.  When built from the IDE, this works fine.  The 
required functions not in the application are taken from the library, 
the balance from the application.

I am running this on a winXP machine with 1 GB of RAM.  I deleted the 
object files and re-building doesn't change anything.

Any other ideas?

Thanks!
Jack




Ed Mulroy [TeamB] wrote:

> A public symbol which is supplied in one of the object files but which is 
> duplicated in the library will generate a duplicate symbol warning but not 
> an error - EXCEPT if there is an unresolved external reference (a public 
> symbol which is being used/called by which has not been found) in the same 
> library object file which contains the duplicate symbol.
> 
> It has been too long.  I think a /d (or -d) option is the one that tells 
> tlink.exe to generate warnings about duplicate public symbols.  Try removing 
> that option from the tlink command line.
> 
> Delete the object file that is giving the fixup overflow error and rebuild 
> it.  Make sure the machine has plenty of memory as that could be caused by 
> running low on memory.
> 
> With appropriate substitutions of your target and object file names this 
> make file might build the program.  See if it does the build any better than 
> what you are using.
> 
> Assuming that it is saved as the file name MyMake.mak then a command line to 
> use it would be:
> 
>   make -f mymake.mak
>   (the space after the -f and the extension .mak are optional)
> 
> ----------------------------
> .autodepend
> 
> LIBS=mylib1 mylib2 emu cl
> 
> OBJS=file1.obj file2.obj file3.obj
> 
> target.exe : $(OBJS)
>     tlink /Tde/v/c c0l $(OBJS),target,,$(LIBS)
> 
> .c.obj :
>     bcc -c -v -ml { $< }
> 
> .cpp.obj :
>     bcc -c -v -ml { $< }
> ----------------------------
> 
> .  Ed
> 
> 
>>JackRosenbloom wrote in message
>>news:429e1291$1@newsgroups.borland.com...
>>Hello,
>>
>>I am using borland C++, version 4.52.  I have a 16 bit dos application 
>>which builds and runs fine using the IDE.  I'm using the large memory 
>>model and linking to a library I wrote also built under the IDE (different 
>>project file), also large memory model.
>>
>>I want to build this application using the command line tools ( bcc.exe 
>>and Tlink).  When I do this, the compile works fine but I get two types of 
>>linker errors which don't occur when building the application under the 
>>IDE
>>
>>ERROR 1
>><function name> defined in module control.cpp is duplicated in module 
>>sim_8904.cpp
>>
>>I do have some duplicate names.  There are some routines in the library 
>>which the application is re-defining.  No problem for the IDE.
>>
>>ERROR 2
>>Error: Fixup overflow at OPI_MAIN_TEXT:03F3, target = 
>>__urc_global_ocs_data in library file c:\urc\kernel23\bc_lib\runonpc.lib 
>>in module opi_main
>>
>>The symbol __urc_global_ocs_data is defined public in one module and 
>>extern in numerous files included in the library.  I verified I'm 
>>compiling large by adding this to one application file
>>
>>#if !defined __LARGE__
>>#error WRONG MODEL
>>#endif
>>The file compiles without error
>>
>>Do you have any idea what is wrong?
> 
> 
>

.

0