#Why have many differences for object file generated by "MinGW Clang++" and "Visual Studio CL"?

1 messages · Page 1 of 1 (latest)

little vapor
#

Are they normal?

/* hellofirst.cpp */

#include <iostream>

using namespace std;

void hellofirst() {
    cout << "The first hello\n";
}

/*hellosecond.cpp*/

#include <iostream>

using namespace std;

void hellosecond() {
    cout << "The second hello\n";
}

/* twohellos.cpp */

void hellofirst (void);
void hellosecond (void);

int main() {
    hellofirst();
    hellosecond();

    return 0;
}

$ ls
hellofirst.cpp  hellosecond.cpp  twohellos.cpp

$ clang++ -c hellofirst.cpp hellosecond.cpp

$ ls
hellofirst.cpp  hellofirst.o  hellosecond.cpp  hellosecond.o  twohellos.cpp

$ cl -c hellofirst.cpp hellosecond.cpp

$ ls
hellofirst.cpp  hellofirst.o hellofirst.obj  hellosecond.cpp  hellosecond.o hellosecond.obj  twohellos.cpp
pseudo dagger
#

What is your problem?

barren otter
#

What "msys2 bug" are you observing?

acoustic merlin
#

Which Clang build are you using (clang64 or mingw64 or ...)?

acoustic merlin
#

I don't know what Dumpbin is smoking, but if you do dumpbin /all hellofirst.obj, you'll see it has a lot in it. Long results with nm or objdump -t as well.

little vapor
#

hellofirst.o is genereated by clang64, why have so many .pdata$_ZNKSt3** and .text$_ZNSt3** in the hellofirst.o?

However, hellofirst.obj is generated by cl, why have no many these in the hellofirst.obj?

barren otter
#

I really don't get it

little vapor
#

I have uploaded a attachment, do you not see it?

barren otter
little vapor
#

why have so many .pdata$_ZNKSt3** and .text$_ZNSt3**?

acoustic merlin
#

Try dumpbin /all hellofirst.obj. You'll see it does contain a lot of stuff.

#

I don't know why Dumpbin shows less on the .obj file by default.

bleak trellis
#

i think the question being asked here is sort of self explanatory

#

the obj files are different because they are different compilers developed in parallel over decades

#

and they do not have to have any kind of consistent ABI in this case

barren otter
#

gcc and cl use different name mangling schemes for C++, that's one difference

#

For the most part C is compatible between them though

#

You just need to be careful not to share CRT objects if they are different

little vapor
#

But I have another crazy problem:

my@DESKTOP CLANG64
$ ldd hello-clang.dll
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffb474b0000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ffb467a0000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ffb44bb0000)
        msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ffb47080000)
        ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7ffb44940000)
        libc++.dll => /clang64/bin/libc++.dll (0x7ffb2a210000)
        advapi32.dll => /c/WINDOWS/System32/advapi32.dll (0x7ffb472f0000)
        sechost.dll => /c/WINDOWS/System32/sechost.dll (0x7ffb473c0000)
        bcrypt.dll => /c/WINDOWS/System32/bcrypt.dll (0x7ffb451b0000)
        RPCRT4.dll => /c/WINDOWS/System32/RPCRT4.dll (0x7ffb46f30000)
        CRYPTBASE.DLL => /c/WINDOWS/SYSTEM32/CRYPTBASE.DLL (0x7ffb44070000)
        bcryptPrimitives.dll => /c/WINDOWS/System32/bcryptPrimitives.dll (0x7ffb45090000)

my@DESKTOP CLANG64
$ ldd hello-msc.dll
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffb474b0000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ffb467a0000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ffb44bb0000)
        msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ffb47080000)

Based on the same code, hello-clang.dll is generated by clang, hello-msc.dll is generated by cl.

I use ucrt C Library environment, why are they depend on msvcrt.dll?

acoustic merlin
#

Use Ntldd. Ldd is not good at normal Windows binaries.

little vapor
#

Is your own opinion? or what docs is it based on?

acoustic merlin
#

Based on experience.

  1. If you use Ntldd, Depencency walker, Process monitor or just look at the import table (Dumpbin, Objdump...), you'll see consistent results.
  2. If you use Cygwin's Ldd, you'll see weird results that don't match those from point 1.
native tulip
#

If ldd is not used correctly for Windows binaries, then ldd should write about the fact that it cannot work correctly and therefore display the message "use ntldd" - do I think this is logical or not?

#

So what binaries is Cygwin's Ldd used for?

acoustic merlin
#

For Cygwin (msys – /usr/bin/) binaries.

acoustic merlin
little vapor
#

Another question: how to check dll depend on msvcrt.dll or ucrtbase.dll?

acoustic merlin
#

Same as for .exe.

little vapor
# 
$ ntldd hello-clang.dll
        libc++.dll => not found
        KERNEL32.dll => C:\WINDOWS\SYSTEM32\KERNEL32.dll (0x0000019ac2210000)

it do not show msvcrt.dll or ucrtbase.dll, why?

native tulip
acoustic merlin
#

I suppose it doesn't directly use the C standard library since it's using the C++ standard library.

bleak trellis