Clang (bcc32c) is not creating object files

[Michaell 2]

Hello, my project was made with the legacy classic Borland compiler. Now I have tried the Clang compiler (32 bit Windows) after some work all of my *.cpp files can be compiled but after the compile there are only
<fileName>.#00

and

<fileName>.d

instead of 

<fileName>.obj

files present. The compiler options '-o' or '-object' did not change anything. I found this stackoverflow.com thread for some equal problem. It tells (e.g.) to remove the '-cc1' option (I do not use (intentionally) any plugin). I would like to try it, but cannot find it in the Embarcadero C++ Builder project options GUI.

1) Where is the '-cc1' compiler option?

2) What can I do else to get the object files?

Thanks a lot!

Michaell

[Roger Cigol 133]

This is strange: I have not seen this issue before when migrating from Classic to Clang32.

What version of C++ Builder / RAD Studio are you using?

[Michaell 2]

I'm using version 12.2, see also my set tags. Here is an example of a Clang call for 1 file:

bcc32c command line for "_Main\_MainWin.cpp"
  c:\program files (x86)\embarcadero\studio\23.0\bin\bcc32c.exe -cc1 -D _DEBUG -D DEBUG -D FRAMEWORK_VCL -output-dir .\OBJ_test -I
  "c:\program files (x86)\embarcadero\studio\23.0\include" -I D:\... -I "C:\Program Files (x86)\..." -I 
  <pathsRemoved> "c:\program files (x86)\embarcadero\studio\23.0\include" -isystem
  "c:\program files (x86)\embarcadero\studio\23.0\include\dinkumware64" -isystem
  "c:\program files (x86)\embarcadero\studio\23.0\include\windows\crtl" -isystem "c:\program files (x86)\embarcadero\studio\23.0\include\windows\sdk" -isystem 
  "c:\program files (x86)\embarcadero\studio\23.0\include\windows\rtl" -isystem C:\Users\Public\Documents\Embarcadero\Studio\23.0\hpp\Win32 -isystem 
  "c:\program files (x86)\embarcadero\studio\23.0\include\windows\vcl" -isystem "c:\program files (x86)\embarcadero\studio\23.0\include\windows\fmx" -isystem
   C:\Users\Public\Documents\Embarcadero\Studio\23.0\hpp\Win32 -debug-info-kind=standalone -fborland-define-external-types -fcxx-exceptions 
  -fborland-extensions -nobuiltininc -nostdsysteminc -triple i686-pc-windows-omf -emit-obj -mrelocation-model static -masm-verbose -ffunction-sections 
  -fexceptions -fseh -mstack-alignment=16 -fno-spell-checking -fno-use-cxa-atexit -fno-threadsafe-statics -main-file-name _MainWin.cpp -x c++ 
  -std=c++17 -O0 -fmath-errno -tM -tW -o .\OBJ_test\_MainWin.obj --auto-dependency-output -MT .\OBJ_test\_MainWin.obj -tWM -Wno-writable-strings 
  -Wno-format -object _Main\_MainWin.cpp 
Success
Elapsed time: 00:00:05.2

In my output directory "\OBJ_test" and all other directories is no *.o or *.obj present. I guess the Clang compiler has a wrong option defined (as visible above, there are a lot of them), unfortunately I have no experiences with it.

Edited Tuesday at 10:51 AM by Michaell
bcc32c call example inserted

[Roger Cigol 133]

I do recall (vaguely) once having to remove a load of options that were being passed to the clang compiler, without ever understanding where these options had come from.

You need to check that there are no additional options being passed. Project options section: C++ Compiler | Advanced | Other options | Additional options to pass to the compiler

[Michaell 2]

I have "played" for hours with the GUI presented options w/o success, obviously it makes no sense if there is no (full) understanding of its purpose and the Clang (Embarcadero) help is not helping me. I decided then to ask "the forum" in the hope to find an experienced user.

[Roger Cigol 133]

OK - I don't know if I qualify for your definition of "experienced user". But I am trying to help. By solving these sorts or problems we all become more experienced. But there is always more to learn (which is what makes life worth living).

Please do check that you have no unexpected entries in "Additional options to pass to the compiler".

Another thing to check is that you the object files are being created where you want them to be. Check project options: C++ Shared options | Intermediate output.

[Michaell 2]

36 minutes ago, Roger Cigol said:

1) Please do check that you have no unexpected entries in "Additional options to pass to the compiler".

2) Another thing to check is that you the object files are being created where you want them to be. Check project options: C++ Shared options | Intermediate output.

1) I'm not able to see unexpected options because I'm not aware what expected options are. I checked the existing options and I guess they are OK.

2) As I wrote above: The missing files are nowhere, i.e. also not in '...\Win32\Debug\' which is currently set in 'C++ Shared options | Intermediate output'.
FYI: I have removed my '...\OBJ_test\' folder and cleaned the related project option, i.e. I expect now the object files in '...\Win32\Debug\'.

[Roger Cigol 133]

24 minutes ago, Michaell said:

I'm not able to see unexpected options because I'm not aware what expected options are. I checked the existing options and I guess they are OK

In all my projects I have NO entries in the "Additional compiler options"  So if you have something there and you don't know what it is I would suggest try deleting it. 

[Michaell 2]

I already deleted most of them, until it was no longer compiling. 

[Roger Cigol 133]

2 minutes ago, Michaell said:

I already deleted most of them, until it was no longer compiling. 

It should compile with no additional options specified by the user - what do you see in this box ?

 

[Michaell 2]

-tWM -o

The '-o' was inserted by me. Due to this I tried again to remove all "Additional Options to pass to the compiler". Now it is really empty and it still compiles. Whatever the problem at my 1st try was, now its gone but it does not help for the original problem.

[Michaell 2]

The help for the bcc32c.exe can be obtained via the CLI:

...\bin\bcc32c.exe -cc1 --help

It list these two object file related options (and others which are may be also relevant?):

-emit-obj

-mincremental-linker-compatible

I tried both but again no success, I really do not get it. 😕

Btw.: One of my initial questions was "Where is the '-cc1' compiler option?" (to try to remove it). The now available help tells that this is always the 1st parameter i.e. must be present.

[Michaell 2]

Is this my problem?:

Quote

Object and Library File Format

• BCC32 and its associated tools use OMF in .obj and .lib files.
• Clang-enhanced C++ compilers use ELF in .o and .a files.

This difference means, for example, that when you migrate a 32-bit Windows applications you must change references to .lib and .obj files to be .a and .o, respectively.

If yes, what has to be changed in the project options?

[Roger Cigol 133]

Good morning @Michaell

 

I will be honest: All of my projects used by customers are either Win 32 VCL using the Classic compiler (ie the old established projects) or Win 64 VCL using the "modern" clang compiler.

 

So actually I have little "working" experience with the Clang 32 bit compiler. When I have upgraded a project from Classic I have gone first to the clang 32 compiler and then on to the Clang 64 "modern" compiler. 

I don't recall any migration being a real headache - although it's never a simple rebuild without doing anything !

 

I have today used RAD Studio 12.3 Enterprise to create a brand new C++ VCL 32 bit project. This uses a single form. It uses TEdit, TButton etc and also some of my own VCL components (which are written in C++ and are installed into the ide at design time).

 

I use static linking for all packages, for the delphi run time and the delphi run time library (I do this for all projects I ship - I do recall in the past finding issues with my own components when I try to link at run time).

 

I now have  a working project.

 

I can change between "Classic" and "Clang32" simply by selecting which compiler in the project options C++ compiler check box. The only other thing I have to do is manually change the library path to point to the directory with

my *.lib file that contains the code for my own components (I have two builds of this - one done using the Classic and one done using the Clang32 <both have the same extension *.lib so I put them in different directories> - if I don't do this the project compiles ok but the linker reports loads of warnings saying

that the library is built with the wrong compiler. 

 

I don't have any settings in the "additional options to pass to the compiler".

 

I do have to do a full rebuild each time I swap the compiler type (completely reasonable!).

 

All my source code, including the project file is in D:\Projects\Cigol quick test scratch\c code x

 

For both cases the object code is output in D:\Projects\Cigol quick test scratch\c code x\Win32\Debug

 

For both cases the object code files have a *.obj extension

 

19 hours ago, Michaell said:

Clang-enhanced C++ compilers use ELF in .o and .a files.

I think this only applies to the Clang 64 bit compilers