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!
Related
The environments are Cent OS 6.7, boost-1.6.2, gcc-6.2.0
I have tried to install a software, but I got some errors.
Are theses errors come from g++ ? or boost?
I can't understand these messages.. because I have never been use g++..
Here is starting line.
[root#cms CASMcode-0.2.0]# scons install
scons: Reading SConscript files ...
rm /usr/local/include/casm
scons: done reading SConscript files.
scons: Building targets ...
Install directory: "include/casm" as "/usr/local/include/casm"
/usr/local/gcc-6.2/bin/g++-6.2 -o src/casm/version/version.os -c -DNDEBUG -O3 --std=c++11 -Wno-deprecated-register -Wno-deprecated-declarations -DEIGEN_DEFAULT_DENSE_INDEX_TYPE=long -Wno-unused-parameter -DNDEBUG -O3 -DGZSTREAM_NAMESPACE=gz -fPIC -Iinclude src/casm/version/version.cc
/usr/local/gcc-6.2/bin/g++-6.2 -o src/casm/clex/ConfigIOStrucScore.os -c -DNDEBUG -O3 --std=c++11 -Wno-deprecated-register -Wno-deprecated-declarations -DEIGEN_DEFAULT_DENSE_INDEX_TYPE=long -Wno-unused-parameter -DNDEBUG -O3 -DGZSTREAM_NAMESPACE=gz -fPIC -Iinclude -I/usr/local/boost_1_62_0/include src/casm/clex/ConfigIOStrucScore.cc
In file included from include/casm/external/Eigen/Core:263:0,
from include/casm/external/Eigen/Dense:1,
from include/casm/CASM_global_definitions.hh:13,
from include/casm/casm_io/EigenDataStream.hh:3,
from src/casm/clex/ConfigIOStrucScore.cc:3:
Error message appear here.
In file included from include/casm/casm_io/DataFormatterTools.hh:1291:0,
from include/casm/casm_io/DataFormatter_impl.hh:3,
from include/casm/casm_io/DataFormatter.hh:757,
from include/casm/clex/ConfigIO.hh:4,
from src/casm/clex/ConfigIOStrucScore.cc:6:
include/casm/casm_io/DataFormatterTools_impl.hh: In member function 'bool CASM::DataFormatterOperator<ValueType, ArgType, DataObject>::parse_args(const string&)':
include/casm/casm_io/DataFormatterTools_impl.hh:33:33: error: invalid initialization of reference of type 'const wstring& {aka const std::__cxx11::basic_string<wchar_t>&}' from expression of type 'std::__cxx11::string {aka std::__cxx11::basic_string<char>}'
val = std::stod(ttag);
^
And here
In file included from include/casm/clex/PrimClex.hh:14:0,
from include/casm/clex/ConfigIOStrucScore.hh:6,
from src/casm/clex/ConfigIOStrucScore.cc:7:
include/casm/clex/ChemicalReference.hh: In member function 'void CASM::ChemicalReferencePrinter::print(const std::vector<CASM::ChemicalReferenceState>&)':
include/casm/clex/ChemicalReference.hh:366:27: error: 'round' is not a member of 'std'
if(almost_equal(std::round(num), num, 1e-14)) {
^~~
Currently, I make a project with scons.
I compiled source codes and it is time to link them.
However, I got an error that ld cannot find object files.
The SConscript is located in src/kernel32, and
import os, sys
# Compile CPP
env_gpp_options = {
'CXX' : 'x86_64-pc-linux-g++',
'CXXFLAGS' : '-std=c++11 -g -m32 -ffreestanding -fno-exceptions -fno-rtti',
'LINK' : 'x86_64-pc-linux-ld',
'LINKFLAGS' : '-melf_i386 -T scripts/elf_i386.x -nostdlib -e main -Ttext 0x10200',
}
env_gpp = Environment(**env_gpp_options)
env_gpp.Append(ENV = {'PATH' : os.environ['PATH']})
object_cpp_list = Glob('*.cpp')
for object_cpp in object_cpp_list:
env_gpp.Object(object_cpp)
# Find all object file
object_target_list = Glob('*.o')
# Linking
env_link_target = 'kernel32.elf'
env_gpp.Program(env_link_target, object_target_list)
and message I got is
x86_64-pc-linux-g++ -o build/kernel32/cpu.o -c -std=c++11 -g -m32 -ffreestanding -fno-exceptions -fno-rtti src/kernel32/cpu.cpp
x86_64-pc-linux-g++ -o build/kernel32/main.o -c -std=c++11 -g -m32 -ffreestanding -fno-exceptions -fno-rtti src/kernel32/main.cpp
x86_64-pc-linux-g++ -o build/kernel32/memory.o -c -std=c++11 -g -m32 -ffreestanding -fno-exceptions -fno-rtti src/kernel32/memory.cpp
x86_64-pc-linux-g++ -o build/kernel32/pageManager.o -c -std=c++11 -g -m32 -ffreestanding -fno-exceptions -fno-rtti src/kernel32/pageManager.cpp
x86_64-pc-linux-g++ -o build/kernel32/utils.o -c -std=c++11 -g -m32 -ffreestanding -fno-exceptions -fno-rtti src/kernel32/utils.cpp
x86_64-pc-linux-ld -o build/kernel32/kernel32.elf -melf_i386 -T scripts/elf_i386.x -nostdlib -e main -Ttext 0x10200 build/kernel32/asmUtils.o build/kernel32/cpu.o build/kernel32/main.o build/kernel32/memory.o build/kernel32/pageManager.o build/kernel32/utils.o
x86_64-pc-linux-ld: cannot find main.o
scons: *** [build/kernel32/kernel32.elf] Error 1
scons: building terminated because of errors.
I checked the directory, build/kernel32/, and I found main.o file.
What is my mistake?
Is there an way to change working directory for scons?
Please let me know what I missed.
You can try this:
import os, sys
# Compile CPP
env_gpp_options = {
'CXX' : 'x86_64-pc-linux-g++',
'CXXFLAGS' : '-std=c++11 -g -m32 -ffreestanding -fno-exceptions -fno-rtti',
'LINK' : 'x86_64-pc-linux-ld',
'LINKFLAGS' : '-melf_i386 -T scripts/elf_i386.x -nostdlib -e main -Ttext 0x10200',
}
env_gpp = Environment(**env_gpp_options)
env_gpp.Append(ENV = {'PATH' : os.environ['PATH']})
object_cpp_list = Glob('*.cpp')
object_target_list = []
for object_cpp in object_cpp_list:
object_target_list.extend(env_gpp.Object(object_cpp))
# Linking
env_link_target = 'kernel32.elf'
env_gpp.Program(env_link_target, object_target_list)
Or
import os, sys
# Compile CPP
env_gpp_options = {
'CXX' : 'x86_64-pc-linux-g++',
'CXXFLAGS' : '-std=c++11 -g -m32 -ffreestanding -fno-exceptions -fno-rtti',
'LINK' : 'x86_64-pc-linux-ld',
'LINKFLAGS' : '-melf_i386 -T scripts/elf_i386.x -nostdlib -e main -Ttext 0x10200',
}
env_gpp = Environment(**env_gpp_options)
env_gpp.Append(ENV = {'PATH' : os.environ['PATH']})
object_cpp_list = Glob('*.cpp')
# Linking
env_link_target = 'kernel32.elf'
env_gpp.Program(env_link_target, object_cpp_list)
This is full scons scripts.
In project root directory,
#SConstruct
build_dir = 'build'
# Build
SConscript(['src/SConscript'], variant_dir = build_dir, duplicate = 0)
# Clean
Clean('.', build_dir)
In src directory
#SConscript for src
SConscript(['bootloader/SConscript',
'kernel32/SConscript'])
In kernel32 directory
#SConscript for kernel32
import os, sys
# Build entry
env_entry = Environment(tools=['default', 'nasm'])
target_entry = 'entry.bin'
object_entry = 'entry.s'
output_entry = env_entry.Object(target_entry, object_entry)
# Compile CPP
env_gpp_options = {
'CXX' : 'x86_64-pc-linux-g++',
'CXXFLAGS' : '-std=c++11 -g -m32 -ffreestanding -fno-exceptions -fno-rtti',
'LINK' : 'x86_64-pc-linux-ld',
'LINKFLAGS' : '-melf_i386 -T scripts/elf_i386.x -nostdlib -e main -Ttext 0x10200',
}
env_gpp = Environment(**env_gpp_options)
env_gpp.Append(ENV = {'PATH' : os.environ['PATH']})
object_cpp_list = Glob('*.cpp')
for object_cpp in object_cpp_list:
env_gpp.Object(object_cpp)
# Compile ASM
env_nasm = Environment(tools=['default', 'nasm'])
env_nasm.Append(ASFLAGS='-f elf32')
object_nasm_list = Glob('*.asm')
for object_nasm in object_nasm_list:
env_nasm.Object(object_nasm)
# Find all object file
object_target_list = Glob('*.o')
object_target_list.append('entry.bin')
# Linking
env_link_target = 'kernel32.elf'
env_gpp.Program(env_link_target, object_target_list)
Thank you for your attention.
I'm trying to setup Mingw-w64 as the mex compiler in MATLAB 2013a. My laptop has x86_64 architecture and runs windows 7. The program I want to compile uses c++11-style threading, so I'm using mingw-w64 version 4.9.0 with posix threads.
According to instruction I found here and here, I modified my mexopts.bat file. The code seems to compile successfully, but the linker reports an error. Does anyone have suggestions what I might be doing wrong?
By the way, I tried using gnumex to setup the compiler, but that didn't work either.
Here's the output and error message that MATLAB gives:
>mex -v Gomoku_mex.cpp
-> Default options filename found in C:\Users\Bas\AppData\Roaming\MathWorks\MATLAB\R2013a
-> Options file = C:\Users\Bas\AppData\Roaming\MathWorks\MATLAB\R2013a\mexopts.bat
MATLAB = C:\Program Files\MATLAB\R2013a
-> COMPILER = x86_64-w64-mingw32-g++
-> Compiler flags:
COMPFLAGS = -std=c++11 -fexceptions -I"C:\Program Files\MATLAB\R2013a\extern\include"
OPTIMFLAGS = -O3 -fexpensive-optimizations -DNDEBUG
DEBUGFLAGS = -g -Wall -Wextra
arguments =
Name switch = -o
-> Pre-linking commands=
-> LINKER = x86_64-w64-mingw32-g++
-> Link directives:
LINKFLAGS = -shared mex.def -L"C:\Program Files\MATLAB\R2013a\bin\win64" -static-libstdc++
LINKDEBUGFLAGS = -g -Wall
LINKFLAGSPOST = -lmex -lmx -lmat -lmwlapack -lmwblas
Name directive = -o "Gomoku_mex.mexw64"
File link directive =
Lib. link directive =
Rsp file indicator =
-> Resource Compiler =
-> Resource Linker =
----------------------------------------------------------------
--> x86_64-w64-mingw32-g++ -std=c++11 -fexceptions -I"C:\Program Files\MATLAB\R2013a\extern\include" -oC:\Users\Bas\AppData\Local\Temp\mex_r7jRw0\Gomoku_mex.obj -I"C:\Program Files\MATLAB\R2013a\extern\include" -I"C:\Program Files\MATLAB\R2013a\simulink\include" -O3 -fexpensive-optimizations -DNDEBUG -DMX_COMPAT_32 Gomoku_mex.cpp
C:\Users\Bas\AppData\Local\Temp\cc4hwD3A.o:Gomoku_mex.cpp:(.text+0x9d1c): undefined reference to `mxGetPr'
C:\Users\Bas\AppData\Local\Temp\cc4hwD3A.o:Gomoku_mex.cpp:(.text+0x9d83): undefined reference to `mxCreateDoubleScalar'
C:/PROGRA~1/mingw-w64/x86_64-4.9.0-posix-seh-rt_v3-rev2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\Bas\AppData\Local\Temp\cc4hwD3A.o: bad reloc address 0x0 in section `.pdata$_ZNKSt5ctypeIcE8do_widenEc'
collect2.exe: error: ld returned 1 exit status
C:\PROGRA~1\MATLAB\R2013A\BIN\MEX.PL: Error: Compile of 'Gomoku_mex.cpp' failed.
Error using mex (line 206)
Unable to complete successfully.
Edit: As extra information, this is my mexopts.bat file. I got this directly from one of the two links above and modified directory & compiler names and added -std=c++11
set MATLAB=%MATLAB%
set PATH=%PATH%;C:\PROGRA~1\mingw-w64\x86_64-4.9.0-posix-seh-rt_v3-rev2\mingw64\bin
set MW_TARGET_ARCH=win64
rem ********************************************************************
rem Compiler parameters
rem ********************************************************************
set COMPILER=x86_64-w64-mingw32-g++
set COMPFLAGS=-std=c++11 -fexceptions -I"%MATLAB%\extern\include"
set OPTIMFLAGS=-O3 -fexpensive-optimizations -DNDEBUG
set DEBUGFLAGS=-g -Wall -Wextra
set NAME_OBJECT=-o
rem ********************************************************************
rem Linker parameters
rem ********************************************************************
set PRELINK_CMDS1=echo EXPORTS > mex.def & echo mexFunction >> mex.def
set LINKER=x86_64-w64-mingw32-g++
set LINKFLAGS= -static-libstdc++ -shared mex.def -L"%MATLAB%\bin\win64" -L"%MATLAB%\extern\lib\win64\microsoft"
set LINKFLAGSPOST= -lmex -lmx -lmat -lmwlapack -lmwblas
set LINKOPTIMFLAGS=-O3
set LINKDEBUGFLAGS= -g -Wall
set LINK_FILE=
set LINK_LIB=
set NAME_OUTPUT=-o "%OUTDIR%%MEX_NAME%%MEX_EXT%"
set RSP_FILE_INDICATOR=
set POSTLINK_CMDS1=del mex.def
Take the following configuration file that I'm using (you'll need to adjust the path pointing to MinGW-w64 location accordingly):
mingw_mexopts.bat
#echo off
set MATLAB=%MATLAB%
set MW_TARGET_ARCH=win64
set PATH=C:\MinGW-w64\mingw64\bin;%PATH%
set COMPILER=x86_64-w64-mingw32-g++
set COMPFLAGS=-c -m64 -mwin32 -mdll -Wall -std=c++11 -DMATLAB_MEX_FILE
set OPTIMFLAGS=-DNDEBUG -O2
set DEBUGFLAGS=-g
set NAME_OBJECT=-o
set LINKER=x86_64-w64-mingw32-g++
set LINKFLAGS=-shared -L"%MATLAB%\extern\lib\win64\microsoft" -L"%MATLAB%\bin\win64"
set LINKFLAGSPOST=-lmx -lmex -lmat
set LINKOPTIMFLAGS=-O2
set LINKDEBUGFLAGS=-g
set LINK_FILE=
set LINK_LIB=
set NAME_OUTPUT=-o "%OUTDIR%%MEX_NAME%%MEX_EXT%"
Next here is a simple MEX-function that uses C++11 threads:
test.cpp
#include "mex.h"
#include <vector>
#include <thread>
void say_hello(int tid) {
mexPrintf("hello from %d\n", tid);
}
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
std::vector<std::thread> threads;
for (int i=0; i<10; i++) {
threads.push_back(std::thread(say_hello, i));
}
for(auto& t : threads) {
t.join();
}
}
Finally we compile and run it in MATLAB:
>> mex -f mingw_mexopts.bat -largeArrayDims test.cpp
>> setenv('PATH', ['C:\MinGW-w64\mingw64\bin;', getenv('PATH')])
>> test
hello from 0
hello from 4
hello from 2
hello from 3
hello from 5
hello from 1
hello from 6
hello from 8
hello from 7
hello from 9
Note that if you're going to deploy this to another machine, you'll have to also copy a few dependent DLL's (you'll find them in MinGW bin folder), and place them next to the MEX-file. Use Dependency Walker to list them. In my case it was:
libstdc++-6.dll
libgcc_s_seh-1.dll
libwinpthread-1.dll
I am using GCC 4.8.2 with MATLAB R2014a running on 64-bit Windows.
Note these error messages:
C:\Users\Bas\AppData\Local\Temp\cc4hwD3A.o:Gomoku_mex.cpp:(.text+0x9d1c): undefined reference to `mxGetPr'
C:\Users\Bas\AppData\Local\Temp\cc4hwD3A.o:Gomoku_mex.cpp:(.text+0x9d83): undefined reference to `mxCreateDoubleScalar'
The library search path for libmex, libmx, libmat, ... is not added in your link command. The directory in your script is the bin directory containing DLLs. That's not correct here.
LINKFLAGS = -shared mex.def -L"C:\Program Files\MATLAB\R2013a\extern\lib\win64\microsoft" -static-libstdc++
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
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.