56

I have been updating code fomr an old legacy project build using C++ Builder 2010 to compile with C++ Builder 10 Seattle. I have mostly had to change paths, a lot of dupIgnore to TDuplicates::dupIgnore, reimport some components like MSXML and MSMQ etc.

First for a bunch of subprojects that the main project uses in the form of bpl's and dll's and finally the code of the main project compiles.

But... it fails a linking :P

[ilink32 Error] Fatal: Unable to open file 'TYPES.OBJ'

I have tried to find info about potential issues and many mention making sure System is supplied in the Unit Scope under the Delphi Compiler settings. But that is already present for this project. What else could be causing this?

For information. Compiled using "classic" bcc32 compiler for now.

Include Path:

$(BDSINCLUDE)\windows\vcl;$(BDSINCLUDE)\dinkumware;

Library Path: 

$(BDSLIB)\$(PLATFORM)\$(Config);$(BDSLIB)\$(PLATFORM)\Release\psdk;
Johan
  • 74,508
  • 24
  • 191
  • 319
inquam
  • 12,664
  • 15
  • 61
  • 101
  • 1
    You could try to refresh the include (.h) and pragma (.cpp) lists by deleting or commenting them. When you save they are generated automatically again. Linker erro does occur after compiling the exe, right? – Kerem Oct 13 '15 at 13:59
  • 1
    I'm not sure I understand what you mean by "lists"? I'm guessing you just mean the normal include and pragma directives? They are quite a few in quite a number of files if that is what you mean. And how would the ide know which ones to "recreate" when you include files from all over the place? – inquam Oct 14 '15 at 10:58
  • 1
    Sorry for the inaccurate description. Some of the include and pragma direcitves are added automatically when you put a component on a form. I faced this problem when I portet an older application to XE2 because some of the include direktives changed. – Kerem Oct 14 '15 at 11:24
  • Does this help: https://community.embarcadero.com/forum/programming/1425-ilink32-error-fatal-unable-to-open-file-types-obj It says you should delete some pragma with TYPES – Emil Vatai Nov 16 '16 at 01:00
  • 1
    Where in your project files the types.obj mentioned? – Dmitry T. Dec 09 '16 at 09:10
  • 2
    When transitioning from one version of the development environment to another, removing the project file (to some place for safe keeping in case you want to recall it) and letting the environment create a new one sometimes cleans up some issues that can result in linking problems; something to try in case you haven't already. – Tim D Dec 22 '16 at 01:28
  • I was getting the same error. The problem, in my case, was in a destructor that was not declared in the implementation. After that, the error went gone. – carloswm85 Aug 11 '18 at 00:56

4 Answers4

1

I think you should find string TYPES.OBJ in all files in your project, after you need remove this string from found files. Before this do not forget to make a backup project directory.

I had a similar problem when I convert old project from BCB5 to BCB 6. When I deleted the string with ".obj" filename from project file with ".bpr" extension my problem was solved.

String in Project1.bpr project file was like:

<OBJFILES value="Unit1.obj Types.obj"/>

after modification:

<OBJFILES value="Unit1.obj"/>
Rufat
  • 536
  • 1
  • 8
  • 25
0

I would follow the advice given by Tim D first. Whenever I start using a newer version of a compiler 90% of of importing old projects is due to me directly including code/header/object files and creating a blank version then copying over afterwards 99% of the time fixes it.

After making sure the data was created fresh, then importing your old data over it, I would check for legacy incompatibility issues. You are on the right path with changing your "lists". I also recommend you make sure that all your code is rewritten for the new compiler in mind. This helps with both code compatibility and streamlining for running the finished project.

Lastly, I would check that all your extra data (files that aren't pure code such as header files) are still recognizable too the compiler currently being used. (Legacy can cause this to be finicky.)

Gulp Dragondawn
  • 101
  • 3
  • 10
0

Looks like the compiler is getting TYPES.OBJ but not able to open as which may happen due to multiple factors(like C++ is platform dependent.. TYPES.cpp might be build in different OS) You can for sure resolve the problem my building TYPES.cpp.. Also be aware the libs this CPP is importing should be compateble even// If you still get the error please go ahead with full build.. Or check link.rsp or use nm command to find dependent oblect and build all of them.

Akshay
  • 15
  • 3
0

For me I was including Spin in Delphi which caused the error ilink64 error fatal: unable to open file 'vcl.samples.spin.o'.

So I deleted Spin & included Vcl.Samples.Spin instead in the Pascal code and the linker was satisfied. This error was caused only on C++ Builder not in Delphi.

KeyC0de
  • 4,728
  • 8
  • 44
  • 68