Hi guys.

my gcc compiler was just fine for C/C++ programs. I have recently
updated to mandrake 10.0 (from 9.2) and it seems I have misinstalled
something. C programs still compile fine, but C++ programs get all the following
error from ld :

/home/bahram/tmp/ccGA3otm.o(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
collect2: ld returned 1 exit status

Now, I have no idea what this `__gxx_personality_v0' is. None of my old programs
compile anymore. Even the simplest test like printing "hello world" fails to compile.

Thank you if you have read this post till there, and even more thank if you can help.

Please check which g++ packages you have installed.

use g++ instead of gcc - that's the problem i had.

Thank you. Yes, that solves the problem.

I know you may make g++ to compile it

hello, I have the same question.
My OS is redhat AdvanseServer3.0, kernel is Linux 2.4.21-4, share lib is libstdc++-2-libc6.1-1-2.9.0.so and libstdc++-3-libc6.2-2-2.10.0.so . I want to install slurm with maui. I do accoring to that the document describes. After make and make install When I typed \'slurmctld -D\', the porcess exited, and error is reported:

------------slurmctld version 0.4.22 started 1
debug3: plugin_peek: dlope(/usr/local/slurm/lib/slurm/sched_wiki.so): /usr/local/slurm/lib/slurm/sched_wiki.so: undefined symbol: __gxx_personality_v0
error: cannot find scheduler plugin for sched/wiki
error: cannot resolve scheduler plugin operations
fatal: failed to initialize scheduling plugin

so I fail to run slurm with maui.

I use g++ instead of gcc, the error is still occur.

Not exactly. Well, the answer is very different.

Since you use g++, that's not the problem. I think it might be dlopen (which I assume is meant by `dlope'), but I'm nowhere near sure enough. Might be very slurm/maui-specific.

I'd suggest creating a new thread.

--Jonas

what is "I'd suggest creating a new thread" 's meaning?

In the right forum, look for a button with the text `new thread'. Click it.

hth --Jonas

It has been noticed that sometimes an error message appears when linking object code, where gxx_personality is not found.

The compilers create some object code that at first glance, would appear to be dead code, causing the gxx_personality error message to appear when linking. Actually, the code is not dead code. It serves a very constructive purpose. More details about its purposes are provided later on in this very documentation.

In order for gxx_personality to serve its intended purpose, the changes also needed to be incorporated in a coordinated way with the linkage editor and other software. If an attempt is made to use a linkage editor which does not accomidate gxx_personality, the error message will appear.

When the error message involving gxx_personality appears, then the generated code involving gxx_personality is truly dead code.

There are at least two ways of dealing with this problem. One way is to provide code that resolves the address for gxx_personality. This approach should only be used when the gxx_personality error occurs, and should not be used otherwise. A second method is to strip out the dead code which involves the reference to gxx_personality.

I have not tested the ability to provide code that resolves the address for gxx_personality, because I personally solve the problem by removing the dead code instead. Here are the steps that can be taken where additional code is provided to resolve gxx_personality using cygwin:

First, create source code for VJKgxx_personality.cpp:

// The purpose of this function is to deal with a problem with gxx_personality

extern "C" void __cdecl __gxx_personality_v0 ( void ) {
}

Next, I compile it in a way that created assembly language source, rather than object code:

\cygwin\bin\gcc-4.exe -Wall -ansi -pedantic -W -Wconversion -Wshadow -Wcast-qual -Wwrite-strings -Wunused -Wundef -O3 -funroll-loops -c -save-temps -S VJKgxx_personality.cpp

This created two files, VJKgxx_personality.ii and VJKgxx_personality.s

VJKgxx_personality.s looks like this:

.file "VJKgxx_personality.cpp"
.text
.p2align 4,,15
.globl ___gxx_personality_v0
.def ___gxx_personality_v0; .scl 2; .type 32; .endef
___gxx_personality_v0:
LFB2:
pushl %ebp
LCFI0:
movl %esp, %ebp
LCFI1:
popl %ebp
ret
LFE2:

The above will work as is, but it contains more than what is needed, so I edited it:

.file "VJKgxx_personality.cpp"
.text
.p2align 4,,15
.globl ___gxx_personality_v0
.def ___gxx_personality_v0; .scl 2; .type 32; .endef
___gxx_personality_v0:
ret

Then I assembled it:

\cygwin\bin\as.exe VJKgxx_personality.s -oVJKgxx_personality.o

The resulting object code can, in theory, be linked with your other object code to resolve the problem with gxx_personality

Here is the second way to resolve the problem, and I have used this method with over 150 programs, and it causes no difficulties.

The code can be stripped out manually, but I strip it out on an automated basis.

Here is how to do it manually:

The code is first compiled where it generates assembly language source code instead of object code:

\cygwin\bin\gcc-4.exe -Wall -ansi -pedantic -W -Wconversion -Wshadow -Wcast-qual -Wwrite-strings -Wunused -Wundef -O3 -funroll-loops -c -save-temps -S vjkWhatever.cpp

The above will create two files, vjkWhatever.ii and vjkWhatever.s

vjkWhatever.s can then be edited.

A line is found which looks like this:

.section .eh_frame,"w"

Remove that line until the following is found:

.def ___gxx_personality_v0; .scl 2; .type 32; .endef

Remove the above line also, and keep removing lines until another line is found which starts with:

.def

If no line appears like the one above, then just remove until the end of the assembly language source code.

Finally, assemble the code with the following:

\cygwin\bin\as.exe vjkWhatever.s -ovjkWhatever.o

The resulting object code will link normally.

I remove the code using program VJK00141, which I have written. It makes other modifications to the assembly language source code to make it a better fit for the environment, so here is a stripped-down version, which shows how to deal with gxx_personality:

// Copyright (C) 2007-2009 by Verlan J. Kliewer. All rights reserved.

// This program modifies the cygwin assembly output from compiler/input to assembler

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <search.h>

char vjkBuffer[4096] ;

extern "C" int __cdecl main ( int argc, char *argv[ ] ) {

while ( NULL != gets ( &vjkBuffer[0] ) ) {
if ( 0 == strcmp ( "\t.section\t.eh_frame,\"w\"", &vjkBuffer[0] ) ) {
// We strip out some source here
do {
if ( NULL == gets ( &vjkBuffer[0] ) ) {
return 0 ;
}
} while ( ( 0 != memcmp ( "\t.def\t", &vjkBuffer[0], 6 ) ) || ( 0 == strcmp ( "\t.def\t___gxx_personality_v0;\t.scl\t2;\t.type\t32;\t.endef", &vjkBuffer[0] ) ) ) ;
}
puts ( &vjkBuffer[0] ) ;
}
return 0 ;
}

The purpose of gxx_personality

I found no documentation describing the purpose of gxx_personality, but the reason for it is extremely obvious from a cursory review of the generated assembly language code. It is present in object code to provide some improved debugger capabilities. A table of information is created for each of the longer functions detected in the original C/C++ source code. Shorter functions do not have a table associated with the function. The table includes information about the function, including where the function starts in memory and where it ends.

By itself, the enhancements to the resulting object code is not enough to implement the debugger capabilities. There is no conventional way of accessing the information, and it would behave as dead code. Changes to the linkage editor, however, can enable the linkage editor and debuggers to obtain a list of the functions and the tables associated with the functions.

When executing without the debugger, the software is not slowed down, but runs as rapidly as before. It just takes slightly more memory for the tables associated with each function.

In environments where many people maintain and develop the software, such as with cygwin, when problems take place it may be difficult to identify what is happening and which code is responsible in a production environment. The additional debuging capabilities make it easier to vindicate good code and implicate code that needs to be modified.

Thus, developers of good code benefit, because they are vindicated when problems take place. Code that needs to be modified or which actually has bugs also benefits, because areas in need of improvement are identified.

There are some disadvantages associated with gxx_personality.

When a linkage editor is used which has not implemented gxx_personality, an error message will appear for an unresolved reference to gxx_personality. This might also happen when a linkage editor which has implemented gxx_personality is used, but it is executed in such a way that gxx_personality capability is not utilized. There are answers for this problem.

Another disadvantage is that with the added debugger capability, it becomes easier to reverse-engineer code. Often under cygwin, the source code is available anyway, so reverse engineering is not as serious a concern.

Another disadvantage is that with the implementation of gxx_personality, option -mno-cygwin is no longer available. This option is for mingw, which allows code to be compiled and linked, linking more directly to the Microsoft operating system instead of going through the cygwin dll. Removal of this option means that the cygwin dll is required for all the software that is linked under cygwin. This is a distinct disadvantage when more than one software package is used at the same time which require the cygwin dll. Only one version of the cygwin dll can be in memory at a time, and if the different software packages require different versions of the cygwin dll, conflicts will exist and it could be that only one of the packages can execute at a time.

The reason why -mno-cygwin was decommissioned was that the the additional debugger capability will not be implemented without going through the cygwin dll. It is too much to link that capability in its entirety in a separate executable. Also, the additional debugger capability may require further development or maintenance, which would be more complicated and difficult if -mno-cygwin would still be available.

Another disadvantage is the increased difficulty in linking cygwin code using other linkers, such as Microsoft's visual C/C++ linker, as covered above. Until now, it was possible to link code compiled by cygwin's compiler using Microsoft's visual C++ linker, as long as the stack space used by each function was less than about 4k (otherwise references to _alloca would be found and not resolved), and the ability of main programs and other programs which start the executable must somehow be prevented from calling _alloca.

More is needed before linking can be practical using visual c/c++.