No se realizó un procedimiento de clase definido

gcc x11

Question

Solo quiero compartir cómo encontré la solución al error.

No se realiza procedimiento de clase definido.

cuando se ejecuta una aplicación X / Motif C. Estoy publicando esto porque solo encontré una referencia a este problema durante la búsqueda en línea, y no contenía soluciones.

Me las arreglé para resolver el problema y quería compartir mis hallazgos si vuelves a encontrar este problema ( Aviso: no estoy diciendo que mi solución siempre resuelva este tipo de error).

Problema

Encontré este problema mientras ejecutaba un programa de C simple que usaba los kits de herramientas Motif y X Intrinsics.

$ gcc -Wall -c push.c
$ gcc -Wall -o push push.o -lXt -lXm
$ ./push
Error: No realize class procedure defined

El código fuente de C fue el siguiente:

#include <stdio.h>
#include <Xm/Xm.h>
#include <Xm/PushB.h>
/* Prototype Callback function */
void pushed_fn(Widget, XtPointer, XmPushButtonCallbackStruct *);
int main(int argc, char **argv)
{
Widget top_wid, button;
XtAppContext app;
Display* display;
XtToolkitInitialize();
app = XtCreateApplicationContext();
display = XtOpenDisplay(app, "localhost:10.0","push","push", NULL,0, &argc,argv);
top_wid = XtAppCreateShell(NULL, "Form", applicationShellWidgetClass, display, NULL, 0);
button = XmCreatePushButton(top_wid, "Push_me", NULL, 0);
/* tell Xt to manage button */
XtManageChild(button);
/* attach fn to widget */
XtAddCallback(button, XmNactivateCallback, (XtCallbackProc) pushed_fn, NULL);
XtRealizeWidget(top_wid); /* display widget hierarchy */
XtAppMainLoop(app); /* enter processing loop */
return 0;
}
void pushed_fn(Widget w, XtPointer client_data, XmPushButtonCallbackStruct *cbs)
{
printf("Don''t Push Me!!/n");
}

Answer 1

La respuesta de Martin Simmons (tomada de note ):

Los problemas de orden de enlace son causados ​​por estos dos símbolos:

vendorShellClassRec
vendorShellWidgetClass

que están definidos Y referenciados en ambos -lXm y -lXt . De alguna manera, debe convencer al enlazador para que use las definiciones -lXm para satisfacer las referencias tanto en -lXm como en -lXt . Las definiciones -lXt no deben ser usadas. Para los cargadores dinámicos típicos basados ​​en elfos ( Linux , Solaris , etc.), esto se hace pasando ''-lXm -lXt'' al enlazador, que los agrega como secciones SO_NEEDED al ejecutable. En tiempo de ejecución, el cargador dinámico recopila símbolos de cada sección SO_NEEDED en el orden en que los encuentra, descarta símbolos que ya conoce y luego corrige las referencias en todas las bibliotecas cargadas utilizando esa tabla de símbolos combinados. Para los enlazadores estáticos típicos, también se realiza especificando ''-lXm -lXt'' al enlazador. En este caso, el enlazador extrae algunos .o de -lXm que contienen símbolos referenciados por el usuario y finalmente termina extrayendo -lXm:Vendor.o debido a referencias internas en -lXm . A continuación, hace lo mismo para -lXt , pero no necesita extraer -lXt:Vendor.o porque no define nada que aún no esté definido.

Answer 2

Sospeché que el problema podría estar en el libXt ya que el símbolo XtRealizeWidget está definido en esa biblioteca. Lo miré usando nm pero todo parecía estar bien:

$ nm -D /usr/lib/libXt.so |grep XtRealizeWidget
02b39870 T XtRealizeWidget

La "T" significa que el símbolo está en la sección de texto (código) de los archivos de objetos que componen la biblioteca libXt, por lo que este símbolo está definido. La ruta para las bibliotecas del sistema también era correcta y solo tenía una versión única de libXt.

Entonces pensé que el orden en el que se estaban pasando las bibliotecas al vinculador gcc podría ser la causa y comencé a leer sobre esto, terminando en este hilo de

Después de cambiar el orden de las bibliotecas a:

$ gcc -Wall -o push push.o -lXm -lXt

El problema fue resuelto.

¡Preste atención al orden en el que se transfieren las bibliotecas y al enlazador!