Sponsored Content
Top Forums Programming Compilation error : Please help Post 302197285 by lagigliaivan on Tuesday 20th of May 2008 04:48:31 PM
Old 05-20-2008
Hi

Hi,

I do not understand your problem very well, but If you are defining the variable state_field state_abvr[] as a global variable in the same file where you are using test_state_abvr function, you do not need to declare it as extern.

You should define a variable as extern, if it is global and if you want use it from another function defined in another file.

Hope it helps!
 

10 More Discussions You Might Find Interesting

1. Programming

Regarding compilation error.

Hi All, I facing the following compilation error; when I implementing the following logic. ostrstream ostr; ostr << (( scAxsm.getRecord( i ).getField( 2 ).getShort())%12)!=0?(( scAxsm.getRecord( i ).getField( 2 ).getShort())/12+1) : (( scAxsm.getRecord( i ).getField( 2 ).getShort())/12) <<... (1 Reply)
Discussion started by: sweta
1 Replies

2. Programming

compilation error

Hi, While trying compile a C++ file in UNIX with gcc whose make rule involves the usage of /usr/ccs/bin/as, I get the following error: /usr/ccs/bin/as: No such file or directory /usr/ccs/bin/as: error: write error on output file "<filename>.o" *** Error code 1 clearmake: Error: Build... (2 Replies)
Discussion started by: smanu
2 Replies

3. Programming

Compilation error

I am compiling a software xchm on solaris 10. First i run './configure' There is no error. But when i start compiling using 'gmake' following error shown /usr/local/include/wx-2.6/wx/x11/brush.h: In copy constructor `wxBrush::wxBrush(const wxBrush&)':... (3 Replies)
Discussion started by: mansoorulhaq
3 Replies

4. Solaris

Solaris : compilation error

Hi All, while building, i am receiving the following error...... Undefined first referenced symbol in file void os_directory::create(const std::string &) obj.release/BOConfig.o (symbol belongs to implicit dependency... (2 Replies)
Discussion started by: vinod_kumar_k
2 Replies

5. Linux

c++ compilation error

Hello every one, here i am attempting to compile a c++ module using gcc.it is throwing a error . error: ==== > make -S dummyCHARGP /usr/local/bin/gcc -g -DDEBUG -DMAT -I. -I/swtemp/usbs/cc/unix-ce/root/subsys/lib/Linux/ -I/opt/dce/include -I/opt/dce/include/dce ... (12 Replies)
Discussion started by: mannam srinivas
12 Replies

6. HP-UX

compilation error

hello everyone, here i am attempting to compile a c++ submodule.OS is HP-UX. here i am getting the following error. ====================================== "Make: Don't know how to make compile. Stop." =================================== could you pls somebody suggest why this error is... (2 Replies)
Discussion started by: mannam srinivas
2 Replies

7. UNIX for Dummies Questions & Answers

Need help in resolving Compilation error

state_field state_abvr = { "AL","ALABAMA", "AK","ALASKA", "AZ","ARIZONA", "AR","ARKANSAS", "CA","CALIFORNIA", "CO","COLORADO", "CT","CONNECTICUT", "DE","DELAWARE", "DC","DISTRICT-OF-COLUMBIA", "FL","FLORIDA", "GA","GEORGIA", "HI","HAWAII", "ID","IDAHO", "IL","ILLINOIS",... (1 Reply)
Discussion started by: jagan_kalluri
1 Replies

8. Programming

pro*c compilation error

Hi, Recently our codes have been migrated to new server, whenever we compile any pro*c programs we receive the following errorl. please help >> make -f lib_util.mk all CC= ucbcc 4Compiling lib_util ### command line files and options (expanded): ### -xO3 -DNULL=0 -v -o lib_util.o... (0 Replies)
Discussion started by: satvd
0 Replies

9. Shell Programming and Scripting

Pro*c compilation error

Hi, Recently our codes have been migrated to new server, whenever we compile any pro*c programs we receive the following errorl. please help >> make -f lib_util.mk all CC= ucbcc 4Compiling lib_util ### command line files and options (expanded): ### -xO3 -DNULL=0 -v -o lib_util.o... (1 Reply)
Discussion started by: satvd
1 Replies

10. Programming

Compilation Error

I am getting the below given errors for the following program though all the variables have been declared and used appropriately. Please Help. The environment is AIX. Error: ------ "gbsizeprofile.c", line 67.4: 1506-275 (S) Unexpected text 'void' encountered. "gbsizeprofile.c", line 67.10:... (2 Replies)
Discussion started by: yschd
2 Replies
DWARF_NEXT_CU_HEADER(3) 				   BSD Library Functions Manual 				   DWARF_NEXT_CU_HEADER(3)

NAME
dwarf_next_cu_header, dwarf_next_cu_header_b, dwarf_next_cu_header_c -- step through compilation units in a DWARF debug context LIBRARY
DWARF Access Library (libdwarf, -ldwarf) SYNOPSIS
#include <libdwarf.h> int dwarf_next_cu_header(Dwarf_Debug dbg, Dwarf_Unsigned *cu_length, Dwarf_Half *cu_version, Dwarf_Off *cu_abbrev_offset, Dwarf_Half *cu_pointer_size, Dwarf_Unsigned *cu_next_offset, Dwarf_Error *err); int dwarf_next_cu_header_b(Dwarf_Debug dbg, Dwarf_Unsigned *cu_length, Dwarf_Half *cu_version, Dwarf_Off *cu_abbrev_offset, Dwarf_Half *cu_pointer_size, Dwarf_Half *cu_offset_size, Dwarf_Half *cu_extension_size, Dwarf_Unsigned *cu_next_offset, Dwarf_Error *err); int dwarf_next_cu_header_c(Dwarf_Debug dbg, Dwarf_Bool is_info, Dwarf_Unsigned *cu_length, Dwarf_Half *cu_version, Dwarf_Off *cu_abbrev_offset, Dwarf_Half *cu_pointer_size, Dwarf_Half *cu_offset_size, Dwarf_Half *cu_extension_size, Dwarf_Sig8 *type_signature, Dwarf_Unsigned *type_offset, Dwarf_Unsigned *cu_next_offset, Dwarf_Error *err); DESCRIPTION
These functions are used to step through compilation or type units associated with a DWARF debug context, optionally returning information about the unit. Function dwarf_next_cu_header_c() is the API recommended for new application code. Function dwarf_next_cu_header() and dwarf_next_cu_header_b() can only operate on compilation units associated with the ``.debug_info'' section. They are less general than func- tion dwarf_next_cu_header_c(), and are deprecated for use by new application code. Argument dbg should reference a DWARF debug context allocated using dwarf_init(3). If argument is_info is set to 1, the function returns information for compilation units found in the ``.debug_info'' section. If argument is_info is set to 0, the function returns information for type units found in the ``.debug_types'' sections. Argument cu_length should point to a location that will be set to the length of the compilation or type unit. Argument cu_version should point to a location that will be set to the version number for the compilation or type unit. Argument cu_abbrev_offset should point to a location that will be set to the starting offset (in the ``.debug_abbrev'' section) of the set of debugging information entry abbreviations associated with this compilation or type unit. Argument cu_pointer_size should point to a location that will be set to the size in bytes of an address for the machine architecture of the underlying object being debugged. Argument cu_offset_size should point to a location that will be set to the size in bytes for a DWARF offset in the compilation or type unit. Argument cu_extension_size is only needed for processing MIPS/IRIX objects that use a non-standard DWARF format. It should point to a location that will be set to 4 for normal objects and to 0 for non-standard ones. Argument type_signature and type_offset is only needed for processing type units. Argument type_signature should point to a location that will be set to the 64-bit unique signature of the type described in the type unit. Argument type_offset should point to a location that will be set to the offset of the debugging information entry that describes the type. Argument cu_next_offset should point to a location that will be set to the offset of the next compilation unit header in the ``.debug_info'' section, or the offset of the next type unit header in the ``.debug_types'' section. Argument err should point to a location that will hold an error descriptor in case of an error. Function dwarf_next_cu_header_b() is identical to function dwarf_next_cu_header_c() except that it does not provide arguments is_info, type_signature and type_offset. Function dwarf_next_cu_header() is identical to function dwarf_next_cu_header_b() except that it does not provide arguments cu_offset_size and cu_extension_size. A value of NULL may be used for any of the arguments cu_length, cu_version, cu_abbrev_offset, cu_pointer_size, cu_offset_size, cu_extension_size, type_signature, type_offset, cu_next_offset and err if the caller is not interested in the respective value. Iterating Through Compilation Units in a Debug Context The first call to function dwarf_next_cu_header_c() for a given debug context with argument is_info set to 1 will return information about the first compilation unit in the ``.debug_info'' section. Subsequent calls to the function will iterate through the remaining compilation units in the section. On stepping past the last compilation unit in the section, function dwarf_next_cu_header_c() returns DW_DLV_NO_ENTRY and resets its internal state. The next call to the function will restart from the first compilation unit in the section. Iterating Through Type Units in a Debug Context When a DWARF debug context is allocated using dwarf_init(3), an internal pointer assoicated with the context will point to the fisrt ``.debug_types'' section found in the debug object. The first call to function dwarf_next_cu_header_c() for the debug context with argument is_info set to 0 will return information about the first type unit in that ``.debug_types'' section. Subsequent calls to the function will iterate through the remaining type units in the section. On stepping past the last type unit in the debug context, function dwarf_next_cu_header_c() returns DW_DLV_NO_ENTRY and resets its internal state. The next call to the function will restart from the first type unit in the ``.debug_types'' section. If the debug object contains multiple ``.debug_types'' sections, the function dwarf_next_types_section() can be called to move the internal pointer to the next ``.debug_types'' section. As a result, subsequent calls of the function dwarf_next_cu_header_c() will operate on the new ``.debug_types'' section. Function dwarf_next_types_section() returns DW_DLV_NO_ENTRY when there are no more ``.debug_types'' sections left in the debug object. RETURN VALUES
On success, these functions return DW_DLV_OK. In case of an error, they return DW_DLV_ERROR and set argument err. When there are no more compilation units left to traverse, they return DW_DLV_NO_ENTRY. ERRORS
These functions can fail with the following error: [DW_DLE_ARGUMENT] Argument dbg was NULL. SEE ALSO
dwarf(3), dwarf_get_cu_die_offset_given_cu_header_offset(3), dwarf_init(3), dwarf_next_types_section(3), dwarf_siblingof(3) BSD
December 21, 2014 BSD
All times are GMT -4. The time now is 04:38 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy