I'm using with gfortran 4.8.2 on FreeBSD 9.2 to create some executable files. There are three files, one C file and two Fortran 77 files where I'm using two routines with one common block.
The problem is that I receive an error of multiple definitions from gfortran compiler.
requests which I had sent to server:
autoreconf
./configure
make
di8810.c
#include <ctype.h>
#include <stdio.h>
#include <stdlib.h>
void main(argc,argv)
int argc;
char *argv[];
{
if (argc != 4)
{
exit(99);
}
gds100(argv[1],argv[2],argv[3]);
}
gds100.f
SUBROUTINE GDS100(AUSGABE,FORMAT,FILENAME)
CHARACTER*4097 EBUF
CHARACTER*264 BUFFER
CHARACTER*1 CBUFFER(264)
CHARACTER*1 CEBUF(4097)
CHARACTER*1 FORMAT
INTEGER*2 INULL
CHARACTER*1 LTEXT(112)
COMMON /GDSCB2/ EBUF
EQUIVALENCE (EBUF,CEBUF(1))
EQUIVALENCE (CEBUF(4097),INULL)
DATA INULL /0/
...
END
gds102.f
SUBROUTINE GDS102
CHARACTER*264 BUFFER
CHARACTER*1 CBUFFER(264)
CHARACTER*4097 EBUF
CHARACTER*1 CEBUF(4097)
INTEGER*2 INULL
INTEGER POIADR
COMMON /GDSCB2/ EBUF
EQUIVALENCE (BUFFER,CBUFFER(1))
EQUIVALENCE (EBUF,CEBUF(1))
EQUIVALENCE (CEBUF(4097),INULL)
DATA IWOGRZ /4096/
DATA INULL /0/
ENTRY GDSUMS(N)
...
END
The error is:
make all-am
gcc -DHAVE_CONFIG_H -I. -DDI88xx -g -O2 -MT src/di8810-di8810.o -MD -MP -MF src/.deps/di8810-di8810.Tpo -c -o src/di8810-di8810.o `test -f 'src/di8810.c' || echo './'`src/di8810.c
mv -f src/.deps/di8810-di8810.Tpo src/.deps/di8810-di8810.Po
gfortran -cpp -fcheck=all -fno-underscoring -DDI88xx -g -O2 -c -o src/di8810-gds100.o `test -f 'src/gds100.f' || echo './'`src/gds100.f
gfortran -cpp -fcheck=all -fno-underscoring -DDI88xx -g -O2 -c -o src/di8810-gds102.o `test -f 'src/gds102.f' || echo './'`src/gds102.f
gfortran -cpp -fcheck=all -fno-underscoring -DDI88xx -g -O2 -o di8810 src/di8810-di8810.o src/di8810-gds100.o src/di8810-gds102.o
src/di8810-gds102.o: In function `gds102':
/.amd_mnt/blnn728x/home/sayik_bo/di8810_t/src/gds102.f:2: multiple definition of `gdscb2'
src/di8810-gds100.o:/.amd_mnt/blnn728x/home/sayik_bo/di8810_t/src/gds100.f:1: first defined here
collect2: Fehler: ld gab 1 als Ende-Status zurück
*** [di8810] Error code 1
Stop in /.amd_mnt/blnn728x/home/sayik_bo/di8810_t.
*** [all] Error code 1
Stop in /.amd_mnt/blnn728x/home/sayik_bo/di8810_t.
Stop in /.amd_mnt/blnn728x/home/sayik_bo/di8810_t.
*** [all] Error code 1
Stop in /.amd_mnt/blnn728x/home/sayik_bo/di8810_t.
It's driving me nuts. Any ideas?
elaborating on my comment
the common statement causes the compiler to allocate global storage for GDSCB2.
The symbols CEBUF,INULL are by Equivalence essentially pointers to the global storage.
Now the two data inull/0/ statements are redundantly initializing the same
location in global memory. I don't know if that a problem or not..just something to look at.
The other thing i see there is inull is 2 bytes (probably..or maybe more but certainly not 1)
yet it is equivalenced to the very last byte of the global character array. ie the initilization writes to data beyond the allocated space.
If at all feasible i would get rid of the common all together. Allocate the storage in the calling program and pass it as an argument to the subroutines.
in any case just do CEBUF(4097)=char(0) instead of using inull like that.
Related
When compiling ltrace with icecc we run into a compilation problem. This is the minimal example:
main.c
#include <assert.h>
int main(int argc, char **argv) {
assert(argc != argc);
return 0;
}
test.sh:
#!/bin/bash
set -x
# one step compilation (no warning)
gcc -Wall main.c
# splitted compilation (warning)
gcc -Wall -E main.c -o main.i
gcc -Wall --preprocessed main.i
output:
++ gcc -Wall main.c
++ gcc -Wall -E main.c -o main.i
++ gcc -Wall --preprocessed main.i
main.c: In function ‘main’:
main.c:4:10: warning: self-comparison always evaluates to false [-Wtautological-compare]
assert(argc != argc);
^~
As you can see the result is different when compiling in one step and when preprocessing and compiling in two steps. Is this intended behavior?
I use gcc 6.3, the issue also appears in gcc 6.2 for ARM. I also cannot ignore this, as the full example uses -Werror.
according to cppreference
The generation of the implicitly-defined copy constructor is
deprecated if T has a user-defined destructor or user-defined copy
assignment operator.
but the following code, no warning message is given using clang++ and c++
struct CAT
{
CAT(){cout<<"CAT()"<<endl;}
~CAT(){}
};
int main()
{
CAT c1, c2;
CAT c3(c1); //should print out a warning?
}
clang++-3.6 -W -Wall -Wextra -pedantic -O2 -o m main.cpp -pedantic-errors -std=c++14
Is it the expected behaviour of g++ and clang++?
clang++ has this warning:
main.cpp:6:5: warning: definition of implicit copy constructor for 'CAT' is deprecated because it has a user-declared destructor [-Wdeprecated]
~CAT(){}
^
main.cpp:12:9: note: implicit copy constructor for 'CAT' first required here
CAT c3(c1); //should print out a warning?
^
1 warning generated.
demo: http://coliru.stacked-crooked.com/a/d6b31ce2d56fac5a
I'm playing around with XPC, GCD and go but I hit a quick wall when my code was failing to compile with the following error messages (which I don't understand):
main(__DATA/__const): unexpected reloc for dynamic symbol _NSConcreteGlobalBlock
main(__DATA/__const): unhandled relocation for _NSConcreteGlobalBlock (type 28 rtype 120)
I am compiling using go build the code that follows:
main.go
package main
/*
#include <xpc/xpc.h>
#include "wrapper.h"
*/
import "C"
import (
"fmt"
)
//export HandleXPCEvent
func HandleXPCEvent(event C.xpc_object_t) {
fmt.Println("Event was handled")
}
func main() {
name := C.CString("com.example.xpc")
queue := C.dispatch_queue_create(name, nil)
conn := C.xpc_connection_create(name, queue)
C.set_event_handler(conn)
//C.xpc_connection_resume(conn)
}
wrapper.h
#ifndef _WRAPPER_H_
#define _WRAPPER_H_
#include <stdlib.h>
#include <stdio.h>
#include <xpc/xpc.h>
xpc_connection_t connect( char* name);
void set_event_handler(xpc_connection_t connection);
#endif
wrapper.c
#include "wrapper.h"
#include <dispatch/dispatch.h>
extern void HandleXPCEvent(xpc_object_t);
xpc_connection_t connect( char* name) {
dispatch_queue_t queue = dispatch_queue_create(name,0);
return xpc_connection_create(name,queue);
}
void set_event_handler(xpc_connection_t connection) {
xpc_connection_set_event_handler(connection, ^(xpc_object_t event) {
xpc_retain(event);
// Call Go function
HandleXPCEvent(event);
});
}
I'm I doing something wrong? Is this some kind of go bug or how can this be fixed?
Update:
I ran go build -x -work on my project and I got the following output:
➣ go build -x -work
WORK=/var/folders/fb/bgfqk8wx5x16w7yh2cg50vrw0000gn/T/go-build524335717
mkdir -p $WORK/github.com/gabrielayuso/go-xpc/_obj/
mkdir -p $WORK/github.com/gabrielayuso/go-xpc/_obj/exe/
cd /Users/gabrielayuso/Documents/Workspace/Projects/go/src/github.com/gabrielayuso/go-xpc
/usr/local/go/pkg/tool/darwin_amd64/cgo -objdir $WORK/github.com/gabrielayuso/go-xpc/_obj/ -- -I $WORK/github.com/gabrielayuso/go-xpc/_obj/ main.go
/usr/local/go/pkg/tool/darwin_amd64/6c -F -V -w -I $WORK/github.com/gabrielayuso/go-xpc/_obj/ -I /usr/local/go/pkg/darwin_amd64 -o $WORK/github.com/gabrielayuso/go-xpc/_obj/_cgo_defun.6 -D GOOS_darwin -D GOARCH_amd64 $WORK/github.com/gabrielayuso/go-xpc/_obj/_cgo_defun.c
gcc -I . -g -O2 -fPIC -m64 -pthread -fno-common -print-libgcc-file-name
gcc -I . -g -O2 -fPIC -m64 -pthread -fno-common -I $WORK/github.com/gabrielayuso/go-xpc/_obj/ -o $WORK/github.com/gabrielayuso/go-xpc/_obj/_cgo_main.o -c $WORK/github.com/gabrielayuso/go-xpc/_obj/_cgo_main.c
gcc -I . -g -O2 -fPIC -m64 -pthread -fno-common -I $WORK/github.com/gabrielayuso/go-xpc/_obj/ -o $WORK/github.com/gabrielayuso/go-xpc/_obj/_cgo_export.o -c $WORK/github.com/gabrielayuso/go-xpc/_obj/_cgo_export.c
gcc -I . -g -O2 -fPIC -m64 -pthread -fno-common -I $WORK/github.com/gabrielayuso/go-xpc/_obj/ -o $WORK/github.com/gabrielayuso/go-xpc/_obj/main.cgo2.o -c $WORK/github.com/gabrielayuso/go-xpc/_obj/main.cgo2.c
gcc -I . -g -O2 -fPIC -m64 -pthread -fno-common -I $WORK/github.com/gabrielayuso/go-xpc/_obj/ -o $WORK/github.com/gabrielayuso/go-xpc/_obj/wrapper.o -c ./wrapper.c
gcc -I . -g -O2 -fPIC -m64 -pthread -fno-common -o $WORK/github.com/gabrielayuso/go-xpc/_obj/_cgo_.o $WORK/github.com/gabrielayuso/go-xpc/_obj/_cgo_main.o $WORK/github.com/gabrielayuso/go-xpc/_obj/_cgo_export.o $WORK/github.com/gabrielayuso/go-xpc/_obj/main.cgo2.o $WORK/github.com/gabrielayuso/go-xpc/_obj/wrapper.o
/usr/local/go/pkg/tool/darwin_amd64/cgo -objdir $WORK/github.com/gabrielayuso/go-xpc/_obj/ -dynimport $WORK/github.com/gabrielayuso/go-xpc/_obj/_cgo_.o -dynout $WORK/github.com/gabrielayuso/go-xpc/_obj/_cgo_import.c
/usr/local/go/pkg/tool/darwin_amd64/6c -F -V -w -I $WORK/github.com/gabrielayuso/go-xpc/_obj/ -I /usr/local/go/pkg/darwin_amd64 -o $WORK/github.com/gabrielayuso/go-xpc/_obj/_cgo_import.6 -D GOOS_darwin -D GOARCH_amd64 $WORK/github.com/gabrielayuso/go-xpc/_obj/_cgo_import.c
gcc -I . -g -O2 -fPIC -m64 -pthread -fno-common -o $WORK/github.com/gabrielayuso/go-xpc/_obj/_all.o $WORK/github.com/gabrielayuso/go-xpc/_obj/_cgo_export.o $WORK/github.com/gabrielayuso/go-xpc/_obj/main.cgo2.o $WORK/github.com/gabrielayuso/go-xpc/_obj/wrapper.o -Wl,-r -nostdlib /usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/x86_64/libgcc.a
/usr/local/go/pkg/tool/darwin_amd64/6g -o $WORK/github.com/gabrielayuso/go-xpc/_obj/_go_.6 -p github.com/gabrielayuso/go-xpc -D _/Users/gabrielayuso/Documents/Workspace/Projects/go/src/github.com/gabrielayuso/go-xpc -I $WORK $WORK/github.com/gabrielayuso/go-xpc/_obj/_cgo_gotypes.go $WORK/github.com/gabrielayuso/go-xpc/_obj/main.cgo1.go
/usr/local/go/pkg/tool/darwin_amd64/pack grcP $WORK $WORK/github.com/gabrielayuso/go-xpc.a $WORK/github.com/gabrielayuso/go-xpc/_obj/_go_.6 $WORK/github.com/gabrielayuso/go-xpc/_obj/_cgo_import.6 $WORK/github.com/gabrielayuso/go-xpc/_obj/_cgo_defun.6 $WORK/github.com/gabrielayuso/go-xpc/_obj/_all.o
cd .
/usr/local/go/pkg/tool/darwin_amd64/6l -o $WORK/github.com/gabrielayuso/go-xpc/_obj/exe/a.out -L $WORK $WORK/github.com/gabrielayuso/go-xpc.a
# github.com/gabrielayuso/go-xpc
main(__DATA/__const): unexpected reloc for dynamic symbol _NSConcreteGlobalBlock
main(__DATA/__const): unhandled relocation for _NSConcreteGlobalBlock (type 28 rtype 120)
Content of $WORK dir as generated by go build -x -work: go-xpc_work.zip
I'm not very familiar with compiling and linking therefore I can't make much sense of this output. I just noticed that _cgo_import.c a file generated by cgo (with options -dynimport and -dynout) has #pragma cgo_import_dynamic _NSConcreteGlobalBlock _NSConcreteGlobalBlock "" in the first line which is related to the error message the linker gave.
Hope this information can help to find out what the problem is and how to solve it.
I don't know much about those libraries but nothing jumps out at me with the code you have here.
Some useful debug output can be obtained from go build -x -work which will print the commands and the working directory for you.
The working directory will be left untouched so you can go look at the code cgo generates for you. That plus the commands it will print for you should get you started on tracking down the problem.
I have a wrapper written up for using Go and XPC in Cocoa Applications.
It's located here:
https://github.com/aventurella/go-xpc
Like two of my previous questions (inline-asm-with-gcc & arm7tdmi-does-not-support-requested-special-purpose-register, I have some build problem when converting code compiled with ARMASM to gcc(code sourcery GCC-4.6.2 eabi).
This time is at linking process: I get a lot of "first defined here" and "multiple definition" to inline functions. Example :
inline U16 ByteSwap16(U16 uData) {
return ( (uData >> 8) | (uData << 8) );
}
I get " multiple definition of `ByteSwap16' " and "first defined here" on the first line.
Here's the linking parameter that I use for the file with the error :
arm-none-eabi-ld -T".\linker.ld" -Map=BootLoad.map -o BootLoad.elf InitMain.o tsk_main.o ecp.o memalloc.o tsk_ecp.o firmdesc.o crc.o flash.o eth.o firmflash.o firmdest.o bcfg.o bootdownload.o cinit.o serial.o cpu.o mmu.o ngucos.o cdbini.o cs712sio.o cs712eth.o nginit.o MmuSdram0.o ../../OS/ngos/lib/rtstub/arm/gcc/libngosd4m32l.a ../../OS/ngip/lib/rtstub/arm/gcc/libngipd4m32l.a
In case the error comes in compilation process :
arm-none-eabi-gcc -c -H -Wall -Wa,-adhlns="tsk_main.o.lst" -fmessage-length=0 -MMD -MP -MF"tsk_main.d" -MT"tsk_main.d" -fpic -o"tsk_main.o" -march=armv4t -mcpu=arm7tdmi -mlittle-endian -g3 -gdwarf-2 -O0 -I"../../OS/ngos/hw/cdb89712" -I"../../OS/ngos" -I"../../OS/ngos/include" -I"../../OS/ngos/rtos/ucosii" -I"./" -I"src/" -I"../../Common/inc" -I"../../OS/uCOS-II/SOURCE" -I"../../OS/ngos/drivers/arm" -I"../../OS/ngos/include/ngos" -I"../../OS/ngip/include" -I"../../OS/ngip/include/ngip" -I"../../Dvcscomponent/Inc" -I"../../Inc" "src/tsk_main.c"
Any idea why the inline function generate theses errors?
Thanks in advance!
I am compiling a kernel module, containing a structure of size 34, using the standard command.
make -C /lib/modules/$(KVERSION)/build M=$(PWD) modules
The sizeof(some_structure) is coming as 36 instead of 34 i.e. the compiler is padding the structure.
How do I remove this padding?
Running make V=1 shows the gcc compiler options passed as
make -I../inc -C /lib/modules/2.6.29.4-167.fc11.i686.PAE/build M=/home/vishal/20100426_eth_vishal/organised_eth/src modules
make[1]: Entering directory `/usr/src/kernels/2.6.29.4-167.fc11.i686.PAE'
test -e include/linux/autoconf.h -a -e include/config/auto.conf || ( \
echo; \
echo " ERROR: Kernel configuration is invalid."; \
echo " include/linux/autoconf.h or include/config/auto.conf are missing."; \
echo " Run 'make oldconfig && make prepare' on kernel src to fix it."; \
echo; \
/bin/false)
mkdir -p /home/vishal/20100426_eth_vishal/organised_eth/src/.tmp_versions ; rm -f /home/vishal/20100426_eth_vishal/organised_eth/src/.tmp_versions/*
make -f scripts/Makefile.build obj=/home/vishal/20100426_eth_vishal/organised_eth/src
gcc -Wp,-MD,/home/vishal/20100426_eth_vishal/organised_eth/src/.eth_main.o.d -nostdinc -isystem /usr/lib/gcc/i586-redhat-linux/4.4.0/include -Iinclude -I/usr/src/kernels/2.6.29.4-167.fc11.i686.PAE/arch/x86/include -include include/linux/autoconf.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Os -m32 -msoft-float -mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2 -march=i686 -mtune=generic -Wa,-mtune=generic32 -ffreestanding -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Iarch/x86/include/asm/mach-generic -Iarch/x86/include/asm/mach-default -Wframe-larger-than=1024 -fno-stack-protector -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -pg -Wdeclaration-after-statement -Wno-pointer-sign -fwrapv -fno-dwarf2-cfi-asm -DTX_DESCRIPTOR_IN_SYSTEM_MEMORY -DRX_DESCRIPTOR_IN_SYSTEM_MEMORY -DTX_BUFFER_IN_SYSTEM_MEMORY -DRX_BUFFER_IN_SYSTEM_MEMORY -DALTERNATE_DESCRIPTORS -DEXT_8_BYTE_DESCRIPTOR -O0 -Wall -DT_ETH_1588_051 -DALTERNATE_DESCRIPTORS -DEXT_8_BYTE_DESCRIPTOR -DNETHERNET_INTERRUPTS -DETH_IEEE1588_TESTS -DSNAPTYPSEL_TMSTRENA_TEVENTENA_TESTS -DT_ETH_1588_140_147 -DLOW_DEBUG_PRINTS -DMEDIUM_DEBUG_PRINTS -DHIGH_DEBUG_PRINTS -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(eth_main)" -D"KBUILD_MODNAME=KBUILD_STR(conxt_eth)" -c -o /home/vishal/20100426_eth_vishal/organised_eth/src/eth_main.o /home/vishal/20100426_eth_vishal/organised_eth/src/eth_main.c
If using GCC, you can use the packed attribute on your structure to prevent padding:
struct foo
{
void * bar;
}
__attribute__( ( packed ) );
#pragma pack might work
I suspect that GCC is forcing the total structure to be aligned onto a 32 bit boundary, so its size is a multiple of 4.
Imagine the following.
struct foo
{
void * bar ;
some other stuff .....
};
struct foo my_foo_array[10];
Then if the sizeof(struct foo) is not a multiple of 4 then.
my_foo_array[0].bar has a different memory alignment to my_foo_array[1].bar. The processor would need to perform 2 32 bit memory accesses in order to access all four bytes of my_foo_array[1].bar. x86 processors will do this reassembly of misaligned 32 bit values but most other processors will throw some form of bus error exception which is not good.
The packed attribute signals how the elements of the structure are packed with respect to each other, but in normal operation the start of structure needs to placed on a 32 bit aligned address.
I hope this explains things a little better.