Mac gcc de error de procesador no virtual

Question

Me estoy poniendo estos errores thunk no virtuales sólo en la acumulación de despliegue de mi aplicación. Utiliza un marco privado llamado Lgi. Sobre la base 10.5.8 utilizando XCode 3.1.4 (más reciente para el leopardo?) Las miradas de error como este:

Ld /Users/matthew/Code/Scribe-Branches/v2.00/build/Development/Scribe.app/Contents/MacOS/Scribe normal i386
    cd /Users/matthew/Code/Scribe-Branches/v2.00
    /Developer/usr/bin/g++-4.0 -arch i386 -L/Users/matthew/Code/Scribe-Branches/v2.00/build/Development -F/Users/matthew/Code/Scribe-Branches/v2.00/build/Development -F/Users/matthew/Code/Lgi/build -F/Users/matthew/Code/Scribe-Branches/v2.00/../../Lgi/build/Development -F/Users/matthew/Code/Scribe-Branches/v2.00/../../Lgi/build/Development -F/Users/matthew/Code/Scribe-Branches/v2.00/../../Lgi/build/Deployment -F/Users/matthew/Code/Scribe-Branches/v2.00/../../Lgi/build/Development -F/Users/matthew/Code/Scribe-Branches/v2.00/../../Lgi/build/Deployment -filelist /Users/matthew/Code/Scribe-Branches/v2.00/build/Scribe.build/Development/Scribe.build/Objects-normal/i386/Scribe.LinkFileList -framework Carbon -framework Lgi -o /Users/matthew/Code/Scribe-Branches/v2.00/build/Development/Scribe.app/Contents/MacOS/Scribe
Undefined symbols:
  "non-virtual thunk to GWindow::OnDrop(char*, GVariant*, GdcPt2, int)", referenced from:
      vtable for ScribeWndin ScribeApp.o
      vtable for GShutdownin ScribeApp.o
      vtable for CalendarUiin Calendar.o
      vtable for CalendarViewWndin CalendarView.o
      vtable for CalendarConfigin CalendarView.o
      vtable for ScribeExportin Exp_Scribe.o
      vtable for GNewMailDlgin GNewMailDlg.o
      ....etc for lots of classes....

De todos modos sé que no estoy dejando a los indefinido, ya que hace de enlace de hecho y correr bien en la versión en desarrollo. Ahora, después de googlear el tema de la primera cosa a intentar es cambiar la configuración de optimización, lo que hice ... y no dados. Algunos errores en el enlace.

Así pues, estas funciones virtuales se definen inicialmente en GDragDropTarget, y se ve la herencia de GWindow como esto:

class LgiClass GWindow : public GView
#ifndef WIN32
    , public GDragDropTarget
#endif

(LgiClass ser para la exportación __declspec / importación en Win32)

¿Alguna idea sobre lo que debe probar la próxima?

Por cierto esto es algunas banderas de ejemplo para el marco:

CompileC build/Lgi.build/Deployment/Lgi.build/Objects-normal/i386/GViewCommon.o 
/Users/matthew/Code/Lgi/src/common/Lgi/GViewCommon.cpp normal i386 c++ 
com.apple.compilers.gcc.4_0
cd /Users/matthew/Code/Lgi
/Developer/usr/bin/gcc-4.0 -x c++ -arch i386 -fmessage-length=0 -pipe -Wno-trigraphs 
-fpascal-strings -fasm-blocks -Os -Wreturn-type -Wunused-variable 
-isysroot /Developer/SDKs/MacOSX10.4u.sdk -fvisibility-inlines-hidden 
-mmacosx-version-min=10.4 
-I/Users/matthew/Code/Lgi/build/Lgi.build/Deployment/Lgi.build/Lgi.hmap 
-F/Users/matthew/Code/Lgi/build/Deployment 
-F/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks -Iinclude/common 
-Iinclude/mac -Iinclude/posix -I/Users/matthew/Code/Lgi/build/Deployment/include 
-I/Users/matthew/Code/Lgi/build/Lgi.build/Deployment/Lgi.build/DerivedSources/i386 
-I/Users/matthew/Code/Lgi/build/Lgi.build/Deployment/Lgi.build/DerivedSources 
-DMAC 
-include /var/folders/b4/b4LnxwCQGLCmwy36TH3QuU+++TQ/-Caches-/com.apple.Xcode.503/SharedPrecompiledHeaders/Lgi_Prefix-aukthgaeovjxcucuoascfyqekpzz/Lgi_Prefix.pch -c /Users/matthew/Code/Lgi/src/common/Lgi/GViewCommon.cpp 
-o /Users/matthew/Code/Lgi/build/Lgi.build/Deployment/Lgi.build/Objects-normal/i386/GViewCommon.o

Ld /Users/matthew/Code/Lgi/build/Lgi.build/Deployment/Lgi.build/Objects-normal/i386/Lgi normal i386
cd /Users/matthew/Code/Lgi
setenv MACOSX_DEPLOYMENT_TARGET 10.4
/Developer/usr/bin/g++-4.0 -arch i386 -dynamiclib -isysroot /Developer/SDKs/MacOSX10.4u.sdk 
-L/Users/matthew/Code/Lgi/build/Deployment 
-F/Users/matthew/Code/Lgi/build/Deployment 
-F/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks 
-filelist /Users/matthew/Code/Lgi/build/Lgi.build/Deployment/Lgi.build/Objects-normal/i386/Lgi.LinkFileList 
-install_name @executable_path/../Frameworks/Lgi.framework/Versions/A/Lgi 
-mmacosx-version-min=10.4 -framework Carbon 
-framework SystemConfiguration -Wl,-single_module -compatibility_version 1 
-current_version 1 -o /Users/matthew/Code/Lgi/build/Lgi.build/Deployment/Lgi.build/Objects-normal/i386/Lgi

Y esto es las banderas de compilación / enlazado de la aplicación:

    CompileC build/Scribe.build/Deployment/Scribe.build/Objects-normal/ppc/IHttp.o 
/Users/matthew/Code/Lgi/src/common/INet/IHttp.cpp normal ppc c++ com.apple.compilers.gcc.4_0
cd /Users/matthew/Code/Scribe-Branches/v2.00
/Developer/usr/bin/gcc-4.0 -x c++ -arch ppc -fmessage-length=0 -pipe -Wno-trigraphs 
-fpascal-strings -Os -mdynamic-no-pic -DMAC -DSCRIBE_APP -isysroot /Developer/SDKs/MacOSX10.4u.sdk 
-mtune=G4 -fvisibility=hidden -fvisibility-inlines-hidden -mmacosx-version-min=10.4 
-I/Users/matthew/Code/Scribe-Branches/v2.00/build/Scribe.build/Deployment/Scribe.build/Scribe.hmap 
-F/Users/matthew/Code/Scribe-Branches/v2.00/build/Deployment -F/Users/matthew/Code/Lgi/build 
-F/Users/matthew/Code/Scribe-Branches/v2.00/../../Lgi/build/Development 
-F/Users/matthew/Code/Scribe-Branches/v2.00/../../Lgi/build/Development 
-F/Users/matthew/Code/Scribe-Branches/v2.00/../../Lgi/build/Deployment 
-F/Users/matthew/Code/Scribe-Branches/v2.00/../../Lgi/build/Development 
-F/Users/matthew/Code/Scribe-Branches/v2.00/../../Lgi/build/Deployment 
-F/Users/matthew/Code/Scribe-Branches/v2.00/../../Lgi/build/Development 
-F/Users/matthew/Code/Scribe-Branches/v2.00/../../Lgi/build/Deployment 
-I/Users/matthew/libpng-1.2.37 -I/Users/matthew/jpeg-6b -I../../Lgi/include/common 
-I../../Lgi/include/mac -I../../aspell-0.60.6/interfaces/cc 
-I/Users/matthew/Code/Scribe-Branches/v2.00/build/Deployment/include 
-IResources -I../Lgi/include/common -I../Lgi/include/mac 
-I/Users/matthew/Code/Scribe-Branches/v2.00/build/Scribe.build/Deployment/Scribe.build/DerivedSources/ppc 
-I/Users/matthew/Code/Scribe-Branches/v2.00/build/Scribe.build/Deployment/Scribe.build/DerivedSources 
-DMAC 
-include /var/folders/b4/b4LnxwCQGLCmwy36TH3QuU+++TQ/-Caches-/com.apple.Xcode.503/SharedPrecompiledHeaders/Scribe_Prefix-ebutivbeomfbzzguhklrzxnwuwzc/Scribe_Prefix.pch 
-c /Users/matthew/Code/Lgi/src/common/INet/IHttp.cpp 
-o /Users/matthew/Code/Scribe-Branches/v2.00/build/Scribe.build/Deployment/Scribe.build/Objects-normal/ppc/IHttp.o

Ld /Users/matthew/Code/Scribe-Branches/v2.00/build/Scribe.build/Deployment/Scribe.build/Objects-normal/i386/Scribe 
normal i386
cd /Users/matthew/Code/Scribe-Branches/v2.00
setenv MACOSX_DEPLOYMENT_TARGET 10.4
/Developer/usr/bin/g++-4.0 -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk 
-L/Users/matthew/Code/Scribe-Branches/v2.00/build/Deployment 
-F/Users/matthew/Code/Scribe-Branches/v2.00/build/Deployment 
-F/Users/matthew/Code/Lgi/build 
-F/Users/matthew/Code/Scribe-Branches/v2.00/../../Lgi/build/Development 
-F/Users/matthew/Code/Scribe-Branches/v2.00/../../Lgi/build/Development 
-F/Users/matthew/Code/Scribe-Branches/v2.00/../../Lgi/build/Deployment 
-F/Users/matthew/Code/Scribe-Branches/v2.00/../../Lgi/build/Development 
-F/Users/matthew/Code/Scribe-Branches/v2.00/../../Lgi/build/Deployment 
-F/Users/matthew/Code/Scribe-Branches/v2.00/../../Lgi/build/Development 
-F/Users/matthew/Code/Scribe-Branches/v2.00/../../Lgi/build/Deployment 
-filelist /Users/matthew/Code/Scribe-Branches/v2.00/build/Scribe.build/Deployment/Scribe.build/Objects-normal/i386/Scribe.LinkFileList 
-mmacosx-version-min=10.4 -framework Carbon -framework Lgi 
-o /Users/matthew/Code/Scribe-Branches/v2.00/build/Scribe.build/Deployment/Scribe.build/Objects-normal/i386/Scribe

Undefined symbols:
"non-virtual thunk to GWindow::OnDrop(char*, GVariant*, GdcPt2, int)", referenced from:
    vtable for ScribeWndin ScribeApp.o
    vtable for GShutdownin ScribeApp.o

No estoy seguro de cuál pertinentes, de modo que todos ellos publicados.

Answer 1

He hecho un pequeño marco de ejemplo y aplicación que siga todas las jerarquías mismos patrones / clase que yo uso en mi aplicación principal, con miras a hacer un simple ejemplo del problema. Pero eso compilado y vinculado. No podía estar seguro de si eso era porque me había cortado demasiado código de él, o porque la recreación de los archivos de proyecto en la versión actual de XCode habían solucionado el problema.

Así que tratar de aislar cuáles de esos casos era cierto que vuelve a crear toda mi proyecto de la estructura desde cero (avance rápido algunas horas) y que se basa en el modo y los vínculos con mi aplicación sin errores (no despliegue) "Release"! Eh? Ooooooooooooook.

Esto significa que el archivo de proyecto se ha roto de alguna manera que no es fácilmente visible en las opciones. Me diff'd todas las opciones contra un proyecto de nueva creación y es bastante 1: 1. Nada obviamente diferente. Por lo tanto, algo que no está visible en el archivo de opciones. Un problema que tenía no se está dando cuenta de que las opciones del proyecto son realmente diferentes a las opciones de destino. Ahora que sé que debe buscar en los dos lugares que puedo ver donde algunos "definido por el usuario" opciones son cada vez más en el camino.

El archivo de proyecto de edad ha pasado por varias actualizaciones del sistema operativo y numerosas mejoras XCode ... supongo que es posible algunas de las mejoras han entrado en conflicto y mal estado del proyecto. Así que gracias por la lectura y por tus comentarios.

Actualización: Bueno después de conseguir el modo de "Release" para compilar, adivina qué? Sí depuración NO compilar. ARRRRGGGGGGGHHHHH !! Así que he copiado sobre toda la configuración de la estructura de manera que la versión de depuración es exactamente la misma que la versión de lanzamiento tanto para Target y Proyecto. Eso no significa enlace. Se sigue trabajando ...

Resulta que la última diferencia entre la liberación y versiones de depuración de la aplicación, es que estoy definiendo "_DEBUG" para la versión de depuración. Que cambia en varias cosas como afirma y algunos API de depuración adicional es. Ahora tengo que trabajar cuál de los que está causando el error de enlace.

Answer 2

Encontrados este anuncio de Matt, es de suponer que alguien en Apple: http : //lists.apple.com/archives/unix-porting/2003/Dec/msg00107.html

En ella, Matt dice:

  

[A thunk no virtual es] una interna   detalle de implementación utiliza para C ++   jerarquías de clases que implican   herencia múltiple. Usted no está haciendo   nada malo; esto es un compilador   error. Sabemos que tenemos que solucionarlo.   Por el momento, la mejor solución   que conocemos es usar el mismo   nivel de optimización para vincular contra   una biblioteca que utilizó para compilar el   biblioteca.

     

(Usted podría también considerar no exportar   interfaz de un C ++ de una biblioteca. Nosotros   trabajar muy duro para asegurarse de que el C   Objetivo y C ABI se mantiene igual   de una versión del compilador a la siguiente,   pero hacemos tal promesa para C ++.)

      --Matt

Así que tal vez están tratando de utilizar una biblioteca de C ++ que fue compilado por un compilador diferente versionado-C ++? El C ++ ABI no se define tan portátil que parece.

Reid

Answer 3

¿Por qué no cambiar los parámetros del compilador de la compilación de producción a los que utiliza para el desarrollo y poco a poco volver a cambiarlos para parecerse a la producción de banderas que utiliza ahora una en el tiempo hasta que se captura el que causa el problema?

A continuación, se puede mirar esta bandera en el manual de gcc y cavar más profundo.