2
votes

After removing the CRT from my DLL I have gotten these weird errors.

Here are they:

  • LNK2001 unresolved external symbol "void __cdecl std::_Xbad_alloc(void)" (?_Xbad_alloc@std@@YAXXZ)
  • LNK2001 unresolved external symbol "void __cdecl std::_Xlength_error(char const *)" (?_Xlength_error@std@@YAXPBD@Z)
  • LNK2001 unresolved external symbol "void __cdecl std::_Xout_of_range(char const *)" (?_Xout_of_range@std@@YAXPBD@Z)
  • unresolved external symbol __dtest
  • unresolved external symbol __fdtest
  • unresolved external symbol __invalid_parameter)noinfo_noreturn
  • unresolved external symbol __stdio_common_vsnprintf_s
  • unresolved external symbol __stdio_common_vsprintf
  • unresolved external symbol __std_terminate

If I understand correctly the Xbad_alloc and Xlength_error are because of the new and delete operators? In that case I create my class instance like this:

class sc_Core
    {
    public:
        static sc_Core *Instance(void);
        func A();
    public:
        void *operator new(size_t si)
        {
            return HeapAlloc(GetProcessHeap(), NULL, si);
        }
        void operator delete(void *pv) throw()
        {
            HeapFree(GetProcessHeap(), NULL, pv);
        }
    private:
        sc_Core(void) { }
        ~sc_Core(void) { }
        sc_Core(const sc_Core&) { }
        sc_Core(sc_Core&&) {}
        sc_Core& operator=(const sc_Core&) {}
        sc_Core& operator=(sc_Core&&) {}
        static sc_Core *p_Instance;
    };

// Global Scope
sc_Core *sc_Core::p_Instance = nullptr;


    sc_Core *sc_Core::Instance(void)
    {
        if (p_Instance == nullptr)
            p_Instance = new sc_Core();

        return p_Instance;
    }

If anyone knows how these occur or how I can fix them it would be very much appreciated!

1
Add the runtime back. There's no good reason to remove it.Rob K
Well Rob, the reason I removed CRT is because I am writing my own OS and would like to support PE files (currently I only support elf) its a small kernel and I will work on my own CRT later, for now all I need is a small PE binary like if it was compiled with nasm or the like.Jason Corick

1 Answers

0
votes

There's nothing weird about those errors.

Compilers are allowed to assume that they can generate code that rely on their runtime libraries. If you're going omit the runtime library at the link step, then you'll have to provide definitions for the missing symbols in your own code.

Turning off certain compiler features may reduce the number of missing symbols. You could try, for example, turning off exception handling support to see if the internal exception classes are still expected. In debug builds, the compiler may expect even more support from the runtime that in release builds.