2

I'm porting an application to Linux, written on IRIX (and successfully ported to AIX (years ago)). One of the issues I found was glwMDrawingAreaWidgetClass is not supported on Linux (use glwDrawaingAreaWidgeClass no 'M'). So I switched it. I built the app on Ubuntu 10.10. Now I'm trying to build on 14.04 (and also tried on 15.10). But I get the following error.

Multiple Definition of glwMDrawingAreaWidgetClass.

I get this for a dozen (or so) files. The thing is .. I am NOT using it.

So in good debugging style I asked: what has changed. The makefiles are the same, the files are the same. It must be the libraries or the compiler (G++).

I have looked everywhere (google search) to find this error. I have not found a solution (or even the problem).

Has anyone noticed this? I suspect its a library issue.
I am using the following libraries to link:..

-lxvw -ldot -lmath -lXm -lXt -lXext -lX11 -lglut -lGLU -lGL -lGLw -lm -lpthread.

The first three are mine. I tried removing glut, GLU, GL, GLw. The either make no difference, or I can't link. I suspect it is GLw.

I am linking statically.

Thanks

Thaddeus
  • 84
  • 6
  • Do you still have an Ubuntu 10.10 environment that compiles it? You could try swapping libraries between that and your current setup to see what works. – Ed Halferty Apr 12 '16 at 02:14
  • Is this actually an error, or just a warning? Please quote the complete message. – Zsigmond Lőrinczy Apr 12 '16 at 03:52
  • It is an error becaue collect2/ld returns an error (see end) Here is a section of the message - occurs multiple times XExec.o: In function `XCommandBox::~XCommandBox()': /c/viewer/src/XExec.c:83: multiple definition of `glwMDrawingAreaWidgetClass' ViewerTestExec.o:/c/viewer/src/ViewerTestExec.c:43: first defined here ViewerExec.o: In function `Executor::initialize()': /c/vps/lib/libxvw.a(XWindow.o): In function `XWindow::XWindow(WindowManager&)': /c/viewer/src/XWindow.c:57: multiple definition of .....collect2: error: ld returned 1 exit status – Thaddeus Apr 12 '16 at 05:35
  • I only use the glwDrawAreaWidgetClass in ONE file. I must be something with the libraries - since it builds without error on ubuntu 10.10 but not 14.04 or 15.10 (these both give me same error) Thanks – Thaddeus Apr 12 '16 at 05:38
  • Most likely it is the new compiler/linker: it is more strict than the old one. You should create a complete, minimal working example that show the problem. – Lorinczy Zsigmond Apr 12 '16 at 05:48
  • I tried setting -std=c++98 (had C++0x) its something with the compiler or libraries – Thaddeus Apr 12 '16 at 06:11
  • I need the package libglwl-mesa-dev in order to have GLwDrawA.h – Thaddeus Apr 12 '16 at 06:20
  • `glw`: [TIL](https://cgit.freedesktop.org/mesa/glw/tree/README) – genpfault Nov 11 '16 at 15:45

2 Answers2

2

Cause

The variable glwMDrawingAreaWidgetClass is being defined in each object file that imports:

#include <Xm/Xm.h>
#include <GL/GLwMDrawA.h>

Is is defined in /usr/include/GL/GLwDrawA.h:

GLAPI WidgetClass glwMDrawingAreaWidgetClass;

GLAPI was extern in RHEL6, before this commit to mesa 3D. As you can see, GLAPI is a macro that is defined as __attribute__((visibility("default"))) when __GCC__ > 4 in /usr/include/gl.h.

Fix

I don't know if this change was proper on glwMDrawingAreaWidgetClass, but modifying /usr/include/GL/gl.h to comment out the macro definition of GLAPI to __attribute__((visibility("default"))) will allow a statement later in the file to set it to extern. This allowed my code to compile.

 #elif (defined(__GNUC__) && __GNUC__ >= 4) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))
-#  define GLAPI __attribute__((visibility("default")))
+//  define GLAPI __attribute__((visibility("default")))
 #  define GLAPIENTRY
 #endif /* WIN32 && !CYGWIN */

...

 #ifndef GLAPI
 #define GLAPI extern
 #endif

Extra

I've made a sample git repository to demonstrate the issue with minimal code, just two object files. I have emailed Dan Nicholson in hopes that he will shed more light on the issue than I can.

Chad Skeeters
  • 1,468
  • 16
  • 19
0

I had the same problem with some code ported from IRIX some time ago. It compiles and links just fine with RedHat 6, but not 7. The only relevant difference, as far as I can tell, is that RedHat 6 uses gcc 4.4, while RedHat 7 uses gcc 4.8.

T. Allison
  • 1
  • 1
  • Hi. I think my problem is similar. I can compile the application on an older linux platform (older gcc) but not on my latest platform (newer gcc). My 'work-around' (for now) is to continue to use the older platform for this one particular application. When I find a solution I'll post it. – Thaddeus Apr 27 '16 at 10:15