Mac gcc de error de procesador no virtual
Pregunta
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.
Solución 3
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.
Otros consejos
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
¿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.