I am trying to build gcc for my linux. I'm cross compiling since I don't have a preexisting gcc.
I'm using musl as libc.
I configured gcc like this:
export CFLAGS="-pipe -march=native -fstack-protector-strong -fno-plt -pie -fpie"
../gcc-10.1.0/configure --target=x86_64-unknown-linux-musl \
--host=x86_64-unknown-linux-musl --build=x86_64-pc-linux-gnu \
--enable-lto --prefix=/usr --disable-nls --disable-multilib \
--enable-languages=c --without-isl --with-newlib --disable-libsanitizer \
--with-sysroot=/root/mnt
When I run make gcc compiles for a few minutes. After a while the build tries to execute the following
x86_64-unknown-linux-musl-gcc -O2 -g -O2 -pipe -march=native -fstack-protector-strong -fno-plt -pie -fpie -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -DUSE_ELF_SYMVER -DGTHREAD_USE_WEAK=0 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o ./libgcc_s.so.1.tmp -g -O2 -pipe -march=native -fstack-protector-strong -fno-plt -pie -fpie -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _mulhc3_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _divhc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _divdi3_s.o _moddi3_s.o _divmoddi4_s.o _udivdi3_s.o _umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o sfp-exceptions_s.o addtf3_s.o divtf3_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o fixtfti_s.o fixunstfti_s.o floattitf_s.o floatuntitf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o getf2_s.o letf2_s.o eqtf2_s.o _divtc3_s.o _multc3_s.o _powitf2_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc
in my build directory under x86_64-unknown-linux-musl/libgcc which fails with:
/root/mnt/tools/lib/gcc/x86_64-unknown-linux-musl/10.1.0/../../../../x86_64-unknown-linux-musl/bin/ld: /root/mnt/tools/lib/gcc/x86_64-unknown-linux-musl/10.1.0/../../../../x86_64-unknown-linux-musl/lib/Scrt1.o: in function `_start_c':
Scrt1.c:(.text._start_c+0x1b): undefined reference to `main'
collect2: error: ld returned 1 exit status
I verified with objdump -t crt1.o and objdump -t Scrt1.o that these object files define main, which they do.
Im pretty confused by now because the name libgcc suggests that it's a library, which of course does not have a main method. Why is ld expecting one? What is the build trying to do here?
I'm building a package (vice 3.4) that uses GNU autoconf. Running ./configure fails with the following message:
checking size of time_t... 0
configure: error: can not figure type of time_t
error: Bad exit status from /var/tmp/rpm-tmp.wIgnPw (%build)
Examining config.log, this appears to be failing due to the following error:
/usr/bin/ld: /tmp/ccMTSdtB.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status
I tried resolving this by adding -fPIC to the CFLAGS environment variable:
CFLAGS=-fPIC ./configure
But while this is clearly being used during other stages of ./configure...
configure:3657: checking whether the C compiler works
configure:3679: gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE=1 -fPIC -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld conftest.c >&5
It doesn't seem to be used in the feature tests related to time_t:
configure:9684: checking for time_t in time.h
configure:9700: gcc -c -g -O3 -Wall -Wformat -Wformat-signedness -Wshadow -Wpointer-arith -Wstrict-prototypes -Wuninitialized -Wunreachable-code -Wno-unused-parameter -Werror=implicit-function-declaration -Wfatal-errors conftest.c >&5
[...]
configure:9753: checking size of time_t
configure:9758: gcc -o conftest -g -O3 -Wall -Wformat -Wformat-signedness -Wshadow -Wpointer-arith -Wstrict-prototypes -Wuninitialized -Wunreachable-code -Wno-unused-parameter -Werror=implicit-function-declaration -Wfatal-errors -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld conftest.c >&5
Looking at configure.ac, the above code is generated from:
if test $bu_cv_decl_time_t_time_h = yes; then
AC_CHECK_SIZEOF([time_t],[],[#include <time.h>])
else
AC_CHECK_SIZEOF([time_t],[],[#include <sys/types.h>])
fi
I've been able to work around the problem by redefining CC instead:
CC="gcc -fPIC" ./configure
This works, but it's ugly (what if something wants to call gcc without -fPIC?). Is there a reason that AC_CHECK_SIZEOF is ignoring CFLAGS?
It looks like the suspicion I expressed in comments is confirmed. The VICE configure program intentionally substitutes its own choice of CFLAGS for the user's specified ones when it performs some of its checks, including the ones related to time_t. Thus, this is not a question of Autoconf ignoring your flags, but rather of VICE doing so.
I reiterate that I think it's a more significant issue that configuration doesn't work out of the box for you in the first place. I suggest raising that as an issue against the project. Although I don't like that VICE is so cavalier about ignoring the user's CFLAGS, that's a separate matter, and one that I suspect wouldn't get much traction with the devs.
John correctly identified the issue, and based on that information I did a little digging and I've figure out what's going on.
I'm building this under the control of rpm, which calls configure like this:
%configure --enable-native-gtk3ui $COMMON_FLAGS
That %configure expands into a chunk of shell code that looks like this:
CFLAGS="${CFLAGS:--O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection}" ; export CFLAGS ;
CXXFLAGS="${CXXFLAGS:--O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection}" ; export CXXFLAGS ;
FFLAGS="${FFLAGS:--O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules}" ; export FFLAGS ;
FCFLAGS="${FCFLAGS:--O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules}" ; export FCFLAGS ;
LDFLAGS="${LDFLAGS:--Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld}" ; export LDFLAGS;
[ "1" = 1 ] && for i in $(find $(dirname ./configure) -name config.guess -o -name config.sub) ; do
[ -f /usr/lib/rpm/redhat/$(basename $i) ] && /usr/bin/rm -f $i && /usr/bin/cp -fv /usr/lib/rpm/redhat/$(basename $i) $i ;
done ;
[ "1" = 1 ] && [ x != "x-Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld" ] &&
for i in $(find . -name ltmain.sh) ; do
/usr/bin/sed -i.backup -e 's~compiler_flags=$~compiler_flags="-Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld"~' $i
done ;
./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu \
--program-prefix= \
--disable-dependency-tracking \
\
--prefix=/usr \
--exec-prefix=/usr \
--bindir=/usr/bin \
--sbindir=/usr/sbin \
--sysconfdir=/etc \
--datadir=/usr/share \
--includedir=/usr/include \
--libdir=/usr/lib64 \
--libexecdir=/usr/libexec \
--localstatedir=/var \
--sharedstatedir=/var/lib \
--mandir=/usr/share/man \
--infodir=/usr/share/info
Of particular interest is the fact that this is setting LDFLAGS. The failing config test is:
gcc -o conftest -g -O3 -Wall -Wformat -Wformat-signedness -Wshadow \
-Wpointer-arith -Wstrict-prototypes -Wuninitialized -Wunreachable-code \
-Wno-unused-parameter -Werror=implicit-function-declaration \
-Wfatal-errors -Wl,-z,relro -Wl,--as-needed -Wl,-z,now \
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld conftest.c
That -specs line points to a gcc spec file that looks like this:
*self_spec:
+ %{!static:%{!shared:%{!r:-pie}}}
That effectively adds the -pie option to the command line. We can reproduce the failure with a simple hello.c program:
#include <stdio.h>
#include <unistd.h>
int main(int argc, char **argv) {
printf("hello world\n");
return(0);
}
Like this:
$ gcc -o hello -pie hello.c
/usr/bin/ld: /tmp/ccXRAu6r.o: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status
But here's the thing:
A successful gcc invocation looks like this:
gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 \
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong \
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 \
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic \
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection \
-D_GNU_SOURCE=1 -fPIC -Wl,-z,relro -Wl,--as-needed -Wl,-z,now \
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld conftest.c
Note that there is a second -specs option there, that points to /usr/lib/rpm/redhat/redhat-hardened-cc1, which looks like:
*cc1_options:
+ %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}}}}}
This takes care of adding -fPIE to the command line, which results in a successful compile:
$ gcc -o hello -pie -fPIE hello.c
$
We're hitting this failure because the configure script is replacing CFLAGS during the tests, but preserving LDFLAGS. This results in a faulty command line.
For my own purposes, I'm just patching the configure script to not replace CFLAGS during the time_t related tests. This seems both expedient (it's a one-character diff if I just comment out the appropriate line) and effective (it results in a successful build).
I will probably report this upstream as a bug.
I'm hoping for help installing Andreas Mueller's MATLAB bindings for Global Probability of Boundary.
I hope that my issue is not deeply ingrained in my installation, so I'll describe the immediate problem first, with the following paragraph noting some attempts at implementation.
According to Mueller's instructions in the readme, I did my best to install CUDA, ACML, and GCC (currently working on RHEL 7). After a successful build/install of the library libdamascene.so, I included a txt file in /etc/ld.so.conf.d/ which includes the path of libdamascene.so. It shows up when I use ldconfig -p | grep libdamascene.so.
When I open up MATLAB and try to build the MEX-file (using GCC 6.3) I get
Error using mex:
In file included from ../damascene-python-and-matlab-bindings-master/bindings/gpb_mex.c: 3: 0:
../damascene-python-and-matlab-bindings-master/bindings/gpb.h: 10: 143: error: expected ';', ',' or ')' before '=' token
void gpb(const unsigned int* in)image, unsigned int width, unsigned int height, float* border, int*textons, float* orientations, int device_num=0);
And a couple of subsequent errors that I gather are from the fact that the compiler wasn't able to properly read the header.
One thing I tried to do was to simply remove the declaration of device_num = 0 and place explicitly initialize it in the gpb_mex.c function call. This result is more nebulous.
Error using mex
/tmp/mex_1295917814264136_135235/gpb_mex.o: In function 'mexFunction':
gpb_mex.c: (.text+0x161): undefined reference to gpb
collect2: error: ld returned 1 exit status.
This error makes me thing that theres a problem with my library, which is a little more challenging to debug. I won't put all the things I tried (available on demand) to get a successful build of the library but let me summarize:
I'm running CUDA 9.0, not CUDA 8.0.
I'm running the gpuacml from the AMD Open64 SDK (only one I could find).
I had to change the gpu_architecture in the CMakelists.txt master file from sm_20 to sm_70.
I have a separate installation of GCC 6.3.0 (and GCC 5.3.0) so I can build the library.
My biggest question is: do you think this indeed a matter of an incorrectly built library or is there something else missing. Is there any way I can check if the library libdamascene.so is working correctly?
Please let me know how I can clarify my situation. Thank you so much!
Edit: I am including additional data.
Here's MATLAB output when I try to compile the MEX-file.
mex -v GCC='/usr/bin/gcc63' G++='/usr/bin/g++63' gpb_mex.c
Verbose mode is on.
... Looking for compiler 'gcc' ...
... Executing command 'which gcc' ...Yes ('/usr/bin/gcc').
... Executing command 'gcc -print-file-name=libstdc++.so' ...Yes ('/usr/lib/gcc/x86_64-redhat-linux/4.8.5/libstdc++.so').
Found installed compiler 'gcc'.
Options file details
-------------------------------------------------------------------
Compiler location: /usr/bin/gcc63
Options file: /home/clusterbomb/.matlab/R2018b/mex_C_glnxa64.xml
CMDLINE2 : /usr/bin/gcc63 -pthread -Wl,--no-undefined -Wl,-rpath-link,/usr/local/MATLAB/R2018b/bin/glnxa64 -shared -O -Wl,--version-script,"/usr/local/MATLAB/R2018b/extern/lib/glnxa64/c_exportsmexfileversion.map" /tmp/mex_1326595352957888_135235/gpb_mex.o /tmp/mex_1326595352957888_135235/c_mexapi_version.o -L"/usr/local/MATLAB/R2018b/bin/glnxa64" -lmx -lmex -lmat -lm -lstdc++ -o gpb_mex.mexa64
CC : /usr/bin/gcc63
DEFINES : -DMATLAB_DEFAULT_RELEASE=R2017b -DUSE_MEX_CMD -D_GNU_SOURCE -DMATLAB_MEX_FILE
MATLABMEX : -DMATLAB_MEX_FILE
CFLAGS : -fexceptions -fPIC -fno-omit-frame-pointer -pthread
INCLUDE : -I"/usr/local/MATLAB/R2018b/extern/include" -I"/usr/local/MATLAB/R2018b/simulink/include"
COPTIMFLAGS : -O2 -fwrapv -DNDEBUG
CDEBUGFLAGS : -g
LD : /usr/bin/gcc63
LDFLAGS : -pthread -Wl,--no-undefined -Wl,-rpath-link,/usr/local/MATLAB/R2018b/bin/glnxa64
LDTYPE : -shared
FUNCTIONMAP : "/usr/local/MATLAB/R2018b/extern/lib/glnxa64/mexFunction.map"
VERSIONMAP : "/usr/local/MATLAB/R2018b/extern/lib/glnxa64/c_exportsmexfileversion.map"
LINKEXPORT : -Wl,--version-script,"/usr/local/MATLAB/R2018b/extern/lib/glnxa64/mexFunction.map"
LINKEXPORTVER : -Wl,--version-script,"/usr/local/MATLAB/R2018b/extern/lib/glnxa64/c_exportsmexfileversion.map"
LINKLIBS : -L"/usr/local/MATLAB/R2018b/bin/glnxa64" -lmx -lmex -lmat -lm -lstdc++
LDOPTIMFLAGS : -O
LDDEBUGFLAGS : -g
MWCPPLIB : "/usr/local/MATLAB/R2018b/sys/os/glnxa64/libstdc++.so.6"
OBJEXT : .o
LDEXT : .mexa64
SETENV : CC="/usr/bin/gcc63"
CXX="g++"
CFLAGS="-fexceptions -fPIC -fno-omit-frame-pointer -pthread -DMATLAB_DEFAULT_RELEASE=R2017b -DUSE_MEX_CMD -D_GNU_SOURCE -DMATLAB_MEX_FILE "
CXXFLAGS="-fexceptions -fPIC -fno-omit-frame-pointer -pthread -std=c++11 -DMATLAB_DEFAULT_RELEASE=R2017b -DUSE_MEX_CMD -D_GNU_SOURCE -DMATLAB_MEX_FILE "
COPTIMFLAGS="-O2 -fwrapv -DNDEBUG"
CXXOPTIMFLAGS="-O2 -fwrapv -DNDEBUG"
CDEBUGFLAGS="-g"
CXXDEBUGFLAGS="-g"
LD="/usr/bin/gcc63"
LDXX="g++"
LDFLAGS="-pthread -Wl,--no-undefined -Wl,-rpath-link,/usr/local/MATLAB/R2018b/bin/glnxa64 -shared -L"/usr/local/MATLAB/R2018b/bin/glnxa64" -lmx -lmex -lmat -lm -lstdc++ -Wl,--version-script,"/usr/local/MATLAB/R2018b/extern/lib/glnxa64/mexFunction.map""
LDDEBUGFLAGS="-g"
GCC : /usr/bin/gcc63
CPPLIBS : /usr/lib/gcc/x86_64-redhat-linux/4.8.5/libstdc++.so
MATLABROOT : /usr/local/MATLAB/R2018b
ARCH : glnxa64
SRC : "/home/clusterbomb/Downloads/GPUGPB/damascene-python-and-matlab-bindings-master/bindings/gpb_mex.c";"/usr/local/MATLAB/R2018b/extern/version/c_mexapi_version.c"
OBJ : /tmp/mex_1326595352957888_135235/gpb_mex.o;/tmp/mex_1326595352957888_135235/c_mexapi_version.o
OBJS : /tmp/mex_1326595352957888_135235/gpb_mex.o /tmp/mex_1326595352957888_135235/c_mexapi_version.o
SRCROOT : /home/clusterbomb/Downloads/GPUGPB/damascene-python-and-matlab-bindings-master/bindings/gpb_mex
DEF : /tmp/mex_1326595352957888_135235/gpb_mex.def
EXP : "gpb_mex.exp"
LIB : "gpb_mex.lib"
EXE : gpb_mex.mexa64
ILK : "gpb_mex.ilk"
MANIFEST : "gpb_mex.mexa64.manifest"
TEMPNAME : gpb_mex
EXEDIR :
EXENAME : gpb_mex
G++ : /usr/bin/g++63
OPTIM : -O2 -fwrapv -DNDEBUG
LINKOPTIM : -O
CMDLINE1_0 : /usr/bin/gcc63 -c -DMATLAB_DEFAULT_RELEASE=R2017b -DUSE_MEX_CMD -D_GNU_SOURCE -DMATLAB_MEX_FILE -I"/usr/local/MATLAB/R2018b/extern/include" -I"/usr/local/MATLAB/R2018b/simulink/include" -fexceptions -fPIC -fno-omit-frame-pointer -pthread -O2 -fwrapv -DNDEBUG "/home/clusterbomb/Downloads/GPUGPB/damascene-python-and-matlab-bindings-master/bindings/gpb_mex.c" -o /tmp/mex_1326595352957888_135235/gpb_mex.o
CMDLINE1_1 : /usr/bin/gcc63 -c -DMATLAB_DEFAULT_RELEASE=R2017b -DUSE_MEX_CMD -D_GNU_SOURCE -DMATLAB_MEX_FILE -I"/usr/local/MATLAB/R2018b/extern/include" -I"/usr/local/MATLAB/R2018b/simulink/include" -fexceptions -fPIC -fno-omit-frame-pointer -pthread -O2 -fwrapv -DNDEBUG "/usr/local/MATLAB/R2018b/extern/version/c_mexapi_version.c" -o /tmp/mex_1326595352957888_135235/c_mexapi_version.o
-------------------------------------------------------------------
Building with 'gcc'.
/usr/bin/gcc63 -c -DMATLAB_DEFAULT_RELEASE=R2017b -DUSE_MEX_CMD -D_GNU_SOURCE -DMATLAB_MEX_FILE -I"/usr/local/MATLAB/R2018b/extern/include" -I"/usr/local/MATLAB/R2018b/simulink/include" -fexceptions -fPIC -fno-omit-frame-pointer -pthread -O2 -fwrapv -DNDEBUG "/home/clusterbomb/Downloads/GPUGPB/damascene-python-and-matlab-bindings-master/bindings/gpb_mex.c" -o /tmp/mex_1326595352957888_135235/gpb_mex.o
/usr/bin/gcc63 -c -DMATLAB_DEFAULT_RELEASE=R2017b -DUSE_MEX_CMD -D_GNU_SOURCE -DMATLAB_MEX_FILE -I"/usr/local/MATLAB/R2018b/extern/include" -I"/usr/local/MATLAB/R2018b/simulink/include" -fexceptions -fPIC -fno-omit-frame-pointer -pthread -O2 -fwrapv -DNDEBUG "/usr/local/MATLAB/R2018b/extern/version/c_mexapi_version.c" -o /tmp/mex_1326595352957888_135235/c_mexapi_version.o
/usr/bin/gcc63 -pthread -Wl,--no-undefined -Wl,-rpath-link,/usr/local/MATLAB/R2018b/bin/glnxa64 -shared -O -Wl,--version-script,"/usr/local/MATLAB/R2018b/extern/lib/glnxa64/c_exportsmexfileversion.map" /tmp/mex_1326595352957888_135235/gpb_mex.o /tmp/mex_1326595352957888_135235/c_mexapi_version.o -L"/usr/local/MATLAB/R2018b/bin/glnxa64" -lmx -lmex -lmat -lm -lstdc++ -o gpb_mex.mexa64
Error using mex
/tmp/mex_1326595352957888_135235/gpb_mex.o: In function `mexFunction':
gpb_mex.c:(.text+0x161): undefined reference to `gpb'
collect2: error: ld returned 1 exit status
Here's the header file gpb.h (with edit of removing device_num=0):
void gpb(const unsigned int* in_image,unsigned int width,unsigned int height, float* border, int* textons, float* orientations, int device_num);
Here's the gpb_mex.c file with the alteration of addition the declared device_num in the final line:
#include <mex.h>
#include "gpb.h"
void mexFunction(int nOut, mxArray *pOut[],
int nIn, const mxArray *pIn[])
{
mwSize width, height;
float* borders;
float* orientations;
int* textons;
unsigned int *in_image;
mwSize dims[3];
mwSize orientation_dims[3];
if((nIn != 1) || (nOut != 3))
mexErrMsgTxt("Usage: border,textons,orientations = gpb(image)");
if (!mxIsClass(pIn[0],"uint8") || mxGetNumberOfDimensions(pIn[0]) != 3) {
mexErrMsgTxt("Usage: th argument must be a unsigned int matrix");
}
const mwSize *indims= mxGetDimensions(pIn[0]);
if (indims[0]!=4)
mexErrMsgTxt("Image needs to be of shape 4 x widht x height");
width = indims[2];
height = indims[1];
mexPrintf("width %d, height %d\n",width,height);
mexPrintf("Element-size: %d, sizeof(int): %d, sizeof(char) %d\n",mxGetElementSize(pIn[0]),sizeof(int),sizeof(unsigned char));
dims[0]=width; dims[1]=height; //for rgb0
mexPrintf("width: %d height: %d\n",width, height);
pOut[0]=mxCreateNumericMatrix(height,width,mxSINGLE_CLASS,mxREAL);
pOut[1]=mxCreateNumericMatrix(height,width,mxINT32_CLASS,mxREAL);
orientation_dims[0]=width; orientation_dims[1]=height; orientation_dims[2]=8;
pOut[2]=mxCreateNumericArray(3,orientation_dims,mxSINGLE_CLASS,mxREAL);
borders=(float*) mxGetPr(pOut[0]);
textons=(int*) mxGetPr(pOut[1]);
orientations=(float*) mxGetPr(pOut[2]);
in_image = (unsigned int*) mxGetData(pIn[0]);
gpb(in_image,height,width,borders,textons,orientations, 0);
}
Happy to provide any more source code as need, but the rest would be ripped straight from amueller's repository (link above).
Edit 2:
using -L resulted in a permission error, which I resolved by sudo chmod 755 libdamascene.so in linux terminal.
So the good news is that matlab was able to find libdamascene, evidenced by it moving forward after permission denied. Unfortunately, the compiler is still struggling.
mex -v GCC='/usr/bin/gcc63' gpb_mex.c -L</home/clusterbomb/Downloads/GPUGPB/damascene-python-and-matlab-bindings-master/build/libdamascene.so>
Verbose mode is on.
... Looking for compiler 'gcc' ...
... Executing command 'which gcc' ...Yes ('/usr/bin/gcc').
... Executing command 'gcc -print-file-name=libstdc++.so' ...Yes ('/usr/lib/gcc/x86_64-redhat-linux/4.8.5/libstdc++.so').
Found installed compiler 'gcc'.
Options file details
-------------------------------------------------------------------
Compiler location: /usr/bin/gcc63
Options file: /home/clusterbomb/.matlab/R2018b/mex_C_glnxa64.xml
CMDLINE2 : /usr/bin/gcc63 -pthread -Wl,--no-undefined -Wl,-rpath-link,/usr/local/MATLAB/R2018b/bin/glnxa64 -shared -O -Wl,--version-script,"/usr/local/MATLAB/R2018b/extern/lib/glnxa64/c_exportsmexfileversion.map" /tmp/mex_1363958469865432_171081/gpb_mex.o /tmp/mex_1363958469865432_171081/c_mexapi_version.o -L</home/clusterbomb/Downloads/GPUGPB/damascene-python-and-matlab-bindings-master/build/libdamascene.so> -L"/usr/local/MATLAB/R2018b/bin/glnxa64" -lmx -lmex -lmat -lm -lstdc++ -o gpb_mex.mexa64
CC : /usr/bin/gcc63
DEFINES : -DMATLAB_DEFAULT_RELEASE=R2017b -DUSE_MEX_CMD -D_GNU_SOURCE -DMATLAB_MEX_FILE
MATLABMEX : -DMATLAB_MEX_FILE
CFLAGS : -fexceptions -fPIC -fno-omit-frame-pointer -pthread
INCLUDE : -I"/usr/local/MATLAB/R2018b/extern/include" -I"/usr/local/MATLAB/R2018b/simulink/include"
COPTIMFLAGS : -O2 -fwrapv -DNDEBUG
CDEBUGFLAGS : -g
LD : /usr/bin/gcc63
LDFLAGS : -pthread -Wl,--no-undefined -Wl,-rpath-link,/usr/local/MATLAB/R2018b/bin/glnxa64
LDTYPE : -shared
FUNCTIONMAP : "/usr/local/MATLAB/R2018b/extern/lib/glnxa64/mexFunction.map"
VERSIONMAP : "/usr/local/MATLAB/R2018b/extern/lib/glnxa64/c_exportsmexfileversion.map"
LINKEXPORT : -Wl,--version-script,"/usr/local/MATLAB/R2018b/extern/lib/glnxa64/mexFunction.map"
LINKEXPORTVER : -Wl,--version-script,"/usr/local/MATLAB/R2018b/extern/lib/glnxa64/c_exportsmexfileversion.map"
LINKLIBS : -L</home/clusterbomb/Downloads/GPUGPB/damascene-python-and-matlab-bindings-master/build/libdamascene.so> -L"/usr/local/MATLAB/R2018b/bin/glnxa64" -lmx -lmex -lmat -lm -lstdc++
LDOPTIMFLAGS : -O
LDDEBUGFLAGS : -g
MWCPPLIB : "/usr/local/MATLAB/R2018b/sys/os/glnxa64/libstdc++.so.6"
OBJEXT : .o
LDEXT : .mexa64
SETENV : CC="/usr/bin/gcc63"
CXX="g++"
CFLAGS="-fexceptions -fPIC -fno-omit-frame-pointer -pthread -DMATLAB_DEFAULT_RELEASE=R2017b -DUSE_MEX_CMD -D_GNU_SOURCE -DMATLAB_MEX_FILE "
CXXFLAGS="-fexceptions -fPIC -fno-omit-frame-pointer -pthread -std=c++11 -DMATLAB_DEFAULT_RELEASE=R2017b -DUSE_MEX_CMD -D_GNU_SOURCE -DMATLAB_MEX_FILE "
COPTIMFLAGS="-O2 -fwrapv -DNDEBUG"
CXXOPTIMFLAGS="-O2 -fwrapv -DNDEBUG"
CDEBUGFLAGS="-g"
CXXDEBUGFLAGS="-g"
LD="/usr/bin/gcc63"
LDXX="g++"
LDFLAGS="-pthread -Wl,--no-undefined -Wl,-rpath-link,/usr/local/MATLAB/R2018b/bin/glnxa64 -shared -L</home/clusterbomb/Downloads/GPUGPB/damascene-python-and-matlab-bindings-master/build/libdamascene.so> -L"/usr/local/MATLAB/R2018b/bin/glnxa64" -lmx -lmex -lmat -lm -lstdc++ -Wl,--version-script,"/usr/local/MATLAB/R2018b/extern/lib/glnxa64/mexFunction.map""
LDDEBUGFLAGS="-g"
GCC : /usr/bin/gcc63
CPPLIBS : /usr/lib/gcc/x86_64-redhat-linux/4.8.5/libstdc++.so
MATLABROOT : /usr/local/MATLAB/R2018b
ARCH : glnxa64
SRC : "/home/clusterbomb/Downloads/GPUGPB/damascene-python-and-matlab-bindings-master/bindings/gpb_mex.c";"/usr/local/MATLAB/R2018b/extern/version/c_mexapi_version.c"
OBJ : /tmp/mex_1363958469865432_171081/gpb_mex.o;/tmp/mex_1363958469865432_171081/c_mexapi_version.o
OBJS : /tmp/mex_1363958469865432_171081/gpb_mex.o /tmp/mex_1363958469865432_171081/c_mexapi_version.o
SRCROOT : /home/clusterbomb/Downloads/GPUGPB/damascene-python-and-matlab-bindings-master/bindings/gpb_mex
DEF : /tmp/mex_1363958469865432_171081/gpb_mex.def
EXP : "gpb_mex.exp"
LIB : "gpb_mex.lib"
EXE : gpb_mex.mexa64
ILK : "gpb_mex.ilk"
MANIFEST : "gpb_mex.mexa64.manifest"
TEMPNAME : gpb_mex
EXEDIR :
EXENAME : gpb_mex
OPTIM : -O2 -fwrapv -DNDEBUG
LINKOPTIM : -O
CMDLINE1_0 : /usr/bin/gcc63 -c -DMATLAB_DEFAULT_RELEASE=R2017b -DUSE_MEX_CMD -D_GNU_SOURCE -DMATLAB_MEX_FILE -I"/usr/local/MATLAB/R2018b/extern/include" -I"/usr/local/MATLAB/R2018b/simulink/include" -fexceptions -fPIC -fno-omit-frame-pointer -pthread -O2 -fwrapv -DNDEBUG "/home/clusterbomb/Downloads/GPUGPB/damascene-python-and-matlab-bindings-master/bindings/gpb_mex.c" -o /tmp/mex_1363958469865432_171081/gpb_mex.o
CMDLINE1_1 : /usr/bin/gcc63 -c -DMATLAB_DEFAULT_RELEASE=R2017b -DUSE_MEX_CMD -D_GNU_SOURCE -DMATLAB_MEX_FILE -I"/usr/local/MATLAB/R2018b/extern/include" -I"/usr/local/MATLAB/R2018b/simulink/include" -fexceptions -fPIC -fno-omit-frame-pointer -pthread -O2 -fwrapv -DNDEBUG "/usr/local/MATLAB/R2018b/extern/version/c_mexapi_version.c" -o /tmp/mex_1363958469865432_171081/c_mexapi_version.o
-------------------------------------------------------------------
Building with 'gcc'.
/usr/bin/gcc63 -c -DMATLAB_DEFAULT_RELEASE=R2017b -DUSE_MEX_CMD -D_GNU_SOURCE -DMATLAB_MEX_FILE -I"/usr/local/MATLAB/R2018b/extern/include" -I"/usr/local/MATLAB/R2018b/simulink/include" -fexceptions -fPIC -fno-omit-frame-pointer -pthread -O2 -fwrapv -DNDEBUG "/home/clusterbomb/Downloads/GPUGPB/damascene-python-and-matlab-bindings-master/bindings/gpb_mex.c" -o /tmp/mex_1363958469865432_171081/gpb_mex.o
/usr/bin/gcc63 -c -DMATLAB_DEFAULT_RELEASE=R2017b -DUSE_MEX_CMD -D_GNU_SOURCE -DMATLAB_MEX_FILE -I"/usr/local/MATLAB/R2018b/extern/include" -I"/usr/local/MATLAB/R2018b/simulink/include" -fexceptions -fPIC -fno-omit-frame-pointer -pthread -O2 -fwrapv -DNDEBUG "/usr/local/MATLAB/R2018b/extern/version/c_mexapi_version.c" -o /tmp/mex_1363958469865432_171081/c_mexapi_version.o
/usr/bin/gcc63 -pthread -Wl,--no-undefined -Wl,-rpath-link,/usr/local/MATLAB/R2018b/bin/glnxa64 -shared -O -Wl,--version-script,"/usr/local/MATLAB/R2018b/extern/lib/glnxa64/c_exportsmexfileversion.map" /tmp/mex_1363958469865432_171081/gpb_mex.o /tmp/mex_1363958469865432_171081/c_mexapi_version.o -L</home/clusterbomb/Downloads/GPUGPB/damascene-python-and-matlab-bindings-master/build/libdamascene.so> -L"/usr/local/MATLAB/R2018b/bin/glnxa64" -lmx -lmex -lmat -lm -lstdc++ -o gpb_mex.mexa64
/tmp/mex_1363958922594243_171081: line 2: -L/usr/local/MATLAB/R2018b/bin/glnxa64: No such file or directory
Error using mex
The command '/usr/bin/gcc63' exited with a return value '1'
I have double and triple checked that the directory /usr/local/MATLAB/R2018b/bin/glnxa64 exists (it does). I have also tried restoredefaultpath and rehash toolboxcache to no avail. No change when I utilize gcc 5.3.0 or the native RHEL 7 gcc. Thank you for your help so far!
In the file damascene-python-and-matlab-bindings/bindings/gpb.h, the following line causes the error:
void gpb(const unsigned int* in_image,unsigned int width,unsigned int height, float* border, int* textons, float* orientations, int device_num=0);
The last argument has a default parameter, which is a C++ feature, an not valid C syntax. Remove the =0 so it becomes:
void gpb(const unsigned int* in_image,unsigned int width,unsigned int height, float* border, int* textons, float* orientations, int device_num);
Next, when you call gpb, you cannot rely on the default value for device_num, so you need to pass this explicitly. In damascene-python-and-matlab-bindings/bindings/gpb_mex.c, the line:
gpb(in_image,height,width,borders,textons,orientations);
needs an additional argument 0:
gpb(in_image,height,width,borders,textons,orientations,0);
With these changes, I hope, the code should compile normally with a C compiler.
(I realize that you already did these things...)
Finally, the linker needs to find the gpb function. I presume this one is in the libdamascene.so library that you built. You need to tell the mex command to link in this library:
mex -v GCC='/usr/bin/gcc63' gpb_mex.c -ldamascene
(the argument to -l gets lib prepended and .a or .so appended, to form the name of the library file. Depending on where this library file resides, you might need to also add a -L<path> argument to the mex call, with <path> the directory that contains the library file:
mex -v GCC='/usr/bin/gcc63' gpb_mex.c -L/home/clusterbomb/Downloads/GPUGPB/damascene-python-and-matlab-bindings-master/build/libdamascene.so
This is my Makefile for the compiler.
CC = arm-none-eabi-gcc
AS = arm-none-eabi-as
LD = arm-none-eabi-ld
OD = arm-none-eabi-objdump
CFLAGS = -g -c -O1 -mcpu=cortex-m0 -mthumb
AFLAGS = -g -c -mcpu=cortex-m0 -mthumb
LDFLAGS = -g -mcpu=cortex-m0 -mthumb --specs=rdimon.specs -lc -lrdimon
ODFLAGS = -d
all: HW1.elf
test: HW1.elf
# echo "...copying"
qemu-system-arm -machine versatilepb -cpu cortex-m3 -nographic -monitor null -serial null -semihosting -k\
ernel HW1.elf
HW1.elf: test.o t1.o
$(CC) $(LDFLAGS) test.o t1.o -o HW1.elf
test.o: test.c t1.o
# echo ".compiling"
$(CC) $(CFLAGS) test.c t1.o -o test.o
t1.o: t1.s
# echo ".assembling"
$(AS) $(AFLAGS) t1.s -o t1.o
clean:
rm -rf t1.o test.o HW1.elf
When I do make all, I get
.assembling
arm-none-eabi-as -g -c -mcpu=cortex-m0 -mthumb t1.s -o t1.o
.compiling
arm-none-eabi-gcc -g -c -O1 -mcpu=cortex-m0 -mthumb test.c t1.o -o test.o
arm-none-eabi-gcc: warning: t1.o: linker input file unused because linking not done
arm-none-eabi-ld -g -mcpu=cortex-m0 -mthumb --specs=rdimon.specs -lc -lrdimon test.o -o HW1.elf
arm-none-eabi-ld: unrecognised emulation mode: thumb
Supported emulations: armelf
make: *** [HW1.elf] Error 1
I have looked at numberous collect2 errors on StackOverflow and find that there is a function either not defined or is mislabeled.
I have entered the directory in the ~/.bashrc file to call arm-none-eabi library functions. I know that the error has nothing to do with the t1.s and/or test.c files and solely to do with an improper notation dealing with my makefile, but I'm lost as to what I'm doing wrong. I know it's something with test.o.
I will provide test.c and t1.s just in case there is something wrong with them.
test.c
include <stdio.h>
extern int inc(int);
#define RED_COUNT 5
#define YELLOW_COUNT 2
#define GREEN_COUNT 5
enum light_states {RED, YELLOW, GREEN};
static int state = RED;
void stop_light () {
static int state_counter = 0;
switch (state) {
case RED:
printf("RED\n");
if (++state_counter >= RED_COUNT) {
state_counter = 0;
state = GREEN;
}
break;
case GREEN:
printf("GREEN\n");
if (++state_counter >= GREEN_COUNT) {
state_counter = 0;
state = YELLOW;
}
break;
case YELLOW:
printf("YELLOW\n");
if (++state_counter >= YELLOW_COUNT) {
state_counter = 0;
state = RED;
}
break;
default:
state = RED;
state_counter = 0;
break;
}
}
main(){
int i;
while (i < 36) {
stop_light();
i = inc(i);
}
}
t1.s
.text
.syntax unified
.thumb
.global inc
.type inc, %function
inc:
adds r0,r0,#1
bx lr
EDIT 1:
Updated the missing '-c' and am now getting a new error regarding LD.
EDIT 2:
Updated the LD error. Everything fixed now and answers were very helpful!
Based on the Limifrog STM32L board examples, I am trying to setup my own toolchain for ARM development (STM32F40x based).
I get an error:
C:\Users\pmu\embedded\empty_stm32>make
arm-none-eabi-gcc -mthumb -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -I
./inc -I./../Libraries/CMSIS/Device/ST/STM32F4xx/Include -I./../Libraries/CMSIS/
Include -Os -Wall -ffunction-sections -fdata-sections -fno-exceptions -Wno-write
-strings -o main src/main.c
c:/program files (x86)/gnu tools arm embedded/4.9 2015q3/bin/../lib/gcc/arm-none
-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc.a(lib_a-exit.o): In
function `exit':
exit.c:(.text.exit+0x16): undefined reference to `_exit'
collect2.exe: error: ld returned 1 exit status
make: *** [main] Error 1
when compiling:
#include "My_Globals.h"
int main(void) {
while(1) {
}
return 0;
}
What does this error mean? Why does it not occur in the Board examples above?
The Makefile
# Compilation Tools
CC = arm-none-eabi-gcc
LD = arm-none-eabi-ld
CP = arm-none-eabi-objcopy
OD = arm-none-eabi-objdump
SIZE = arm-none-eabi-size
# Optimization (ß,1,2,s)
OPT = s
ROOT = ./..
CMSIS_DIR = $(ROOT)/Libraries/CMSIS
HAL_DIR = $(ROOT)/Libraries/CMSIS/Include
SRC = ./src
INC_LOCAL = ./inc
INCLUDES = \
$(INC_LOCAL) \
$(CMSIS_DIR)/Device/ST/STM32F4xx/Include \
$(CMSIS_DIR)/Include
ARCH_FLAGS = -mthumb -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16
LD_FLAGS =
# Compiler flags
CFLAGS = \
$(ARCH_FLAGS) \
$(addprefix -I,$(INCLUDES)) \
-O$(OPT) \
-Wall \
-ffunction-sections \
-fdata-sections \
-fno-exceptions \
-Wno-write-strings
main:
#echo "start"
#echo $#
$(CC) $(LDFLAGS) $(CFLAGS) -o $# src/main.c
Now, what libraries can be used to re-use the implementation of _exit() from elsewhere?