Включая двоичный blob из objcopy в MinGW 32 и 64

Question

Я использую objcopy для преобразования текстового файла в объектный файл для связывания с моей DLL с помощью MinGW и MinGW-64. С MinGW все работает нормально, но с MinGW-64 я получаю ошибки формы «неопределенная ссылка на« binary_src_glsl_RGBtoHSV_glsl_end ». Исходный файл называется RGBtoHSV.glsl и находится в папке binary \ src \ glsl. В выводе objcopy имя переменной _binary_src_glsl_RGBtoHSV_glsl_end. Мой код для доступа к переменным для этого файла выглядит следующим образом:

extern "C" const char binary_src_glsl_RGBtoHSV_glsl_start; 
extern "C" const char binary_src_glsl_RGBtoHSV_glsl_end; 
const std::string RGBtoHSV = std::string(&binary_src_glsl_RGBtoHSV_glsl_start, &binary_src_glsl_RGBtoHSV_glsl_end-&binary_src_glsl_RGBtoHSV_glsl_start); 

Если изменить имена переменных, так что у них есть undercore впереди, например:

extern "C" const char _binary_src_glsl_RGBtoHSV_glsl_start; 

Затем этот символ найден в MinGW-64, но не в MinGW (32 бит). Я попробовал параметр -remove-remove-leading-char для objcopy, но это не повлияло. Насколько я могу судить, мои варианты заключаются в том, чтобы либо добавить подчеркивание к именам переменных, сгенерированным objcopy, с помощью «--prefix-symbol _» при создании для 32 бит MinGW, и в этом случае указанное имя переменной будет работать в 32 и 64 бит.

Есть ли еще одно решение этой проблемы? В идеале я хотел бы что-то вдоль линий

extern "C" fix_underscore_problem const char binary_src_glsl_RGBtoHSV_glsl_start; 

Где fix_underscore_problem волшебная команда, чтобы исправить подчеркивание проблемы.

Update (2012-07-01): Используя советы, приведенные в Adding leading underscores to assembly symbols with GCC on Win32? я изменен заголовочный файл использовать

extern "C" const char binary_src_glsl_RGBtoHSV_glsl_start asm("_binary_src_glsl_RGBtoHSV_glsl_start"); 

Это, кажется, чтобы решить эту проблему, но теперь мне интересно, как это портативный. Есть ли эквивалентный синтаксис, доступный в MSVC или стандартном способе C++ для этого?

Answer 1

Ну, я решил проблему, вроде, определяя макрос, который при необходимости создает переменную с ведущим подчеркиванием. Затем он создает функцию, которая возвращает указатель на переменную. Имя функции всегда будет именем, переданным макросу, поэтому остальная часть моего кода может просто использовать это имя функции. Макрос:

#define GPUFW_STR(x) #x 

#if defined(__GNUC__) | defined(__MINGW32__) | defined(__MINGW64__) 
    //GCC and MinGW allow one to use the asm keyword to give a variable a 
    //specific label, overriding the label used at compile time. 
    #define GPUFW_BINARY_BLOB_EXTERN(T,x) extern "C" const T x asm(GPUFW_STR(_ ## x)); static const T* at_ ## x = &x; 
#else 
    #if defined(_MSC_VER) 
     #if defined(_WIN32) 
      //Visual C++ does not seem to have a method to specify a different 
      //label for a variable at link time, but in 32-bit Windows 
      //extern "C" variables have a leading underscore anyway. 
      #define GPUFW_BINARY_BLOB_EXTERN(T,x) extern "C" const T x; static const T* at_ ## x = &x; 
     #else 
      //64-bit Visual C++ does not prepend an underscore to extern "C" 
      //variable names, causing many problems here. Hence define the 
      //external variable as _x. 
      #define GPUFW_BINARY_BLOB_EXTERN(T,x) extern "C" const T _##x; static const T* at_ ## x = &_ ## x; 
     #endif 
    #else 
     //Unknown compiler. 
     #warning Your compiler was not recognised by GPUFW. Binary blob inclusion may produce linker errors. 
     #if defined(_WIN64) 
      //On 64-bit Windows most compilers seem to stick to the Visual C++ 
      //naming conventions. 
      #define GPUFW_BINARY_BLOB_EXTERN(T,x) extern "C" const T _##x; static const T* at_ ## x = &_ ## x; 
     #else 
      //If all else fails, hope that the compiler uses a leading underscore. 
      #define GPUFW_BINARY_BLOB_EXTERN(T,x) extern "C" const T x; static const T* at_ ## x = &x; 
     #endif 
    #endif 
#endif 

Я бы по достоинству оценил любые предложения по улучшению этого решения. Особенно я могу добавить к ветке, которая занимается компиляторами, отличными от GCC и MSVC, поскольку у меня нет опыта с ними.

В качестве побочного примечания я также попытался использовать ld для создания объектного файла, содержащего мой текст, но это было связано с той же проблемой, что независимо от того, какой вариант я использовал, я не смог удалить ведущее подчеркивание.