How do you use cgo WITHOUT using make? - makefile

I use a custom build tool to compile go projects and I need a way to use cgo in my project.
The problem is that the cgo documentation only tells you how to use it with make.
What I really need to know is which generated files to process with which tools and in what order it needs to be done. I tried to read make.pkg in the go source dir but my best effort fails.
My test dll is very simple, a single function that returns 1 every time it is called and the go code to use this function is similarly simple.
The output from the console produced by a successful run of make on a cgo project would be very helpful.

Output of running make on 32-bit Linux in directory misc/cgo/life:
# gomake _obj/life.a
CGOPKGPATH= cgo -- life.go
touch _obj/_cgo_run
8g -o _go_.8 _obj/life.cgo1.go _obj/_cgo_gotypes.go
8c -FVw -I ${GOROOT}/pkg/linux_386 -I . -o "_cgo_defun.8" _obj/_cgo_defun.c
gcc -m32 -I . -g -fPIC -O2 -o _cgo_main.o -c _obj/_cgo_main.c
gcc -m32 -g -fPIC -O2 -o c-life.o -c c-life.c
gcc -m32 -I . -g -fPIC -O2 -o life.cgo2.o -c _obj/life.cgo2.c
gcc -m32 -I . -g -fPIC -O2 -o _cgo_export.o -c _obj/_cgo_export.c
gcc -m32 -g -fPIC -O2 -o _cgo1_.o _cgo_main.o c-life.o life.cgo2.o _cgo_export.o
cgo -dynimport _cgo1_.o >_obj/_cgo_import.c_ && mv -f _obj/_cgo_import.c_ _obj/_cgo_import.c
8c -FVw -I . -o "_cgo_import.8" _obj/_cgo_import.c
rm -f _obj/life.a
gopack grc _obj/life.a _go_.8 _cgo_defun.8 _cgo_import.8 c-life.o life.cgo2.o _cgo_export.o
The line cgo -- life.go creates the following files:
_obj/_cgo_.o
_obj/life.cgo1.go
_obj/life.cgo2.c
_obj/_cgo_gotypes.go
_obj/_cgo_defun.c
_obj/_cgo_main.c
_obj/_cgo_flags
_obj/_cgo_export.c
_cgo_export.h

"I use a custom build tool to compile go projects and I need a way to use cgo in my project."
... and this approach leads to problems. Using the standard way with a Makefile is simple, easy, proven, documented, etc.
I realize I'm not (directly) answering your question. Instead my "answer" is: I strongly suggest to use the standard way. Don't create problems for your self by choosing other, not directly supported options.
That said, I think there is a way to avoid the Makefiles, I just never been there, sorry. I'm usually lazy/short of time, so I use the simplest/fastest way to get things done. You might want to try the same ;-)

Related

Modifying configure.ac - check for package presence

My main development platform is Gentoo on Linux. However, recently I tried to build my program on the fresh VM install on Debian.
My program contains of main binary and couple of dll/so/dylib libraries. One of the libraries depends on the presence of unixODBC/iODBC.
I was told by unixODBC maintainers to use odbc_config script to identify the build parameters.
When I build on Gentoo - everything works fine. There is no problems.
However, when I build on Debian - the build fails because apparently Debian does not produce odbc_config script and instead in this case rely on pkg-config.
So, I need to add a test in configure.ac to check for odbc_config script presence and pass it along to one of the so files generation (lets call it libodbc_lib project).
Could someone please help me with this?
EDIT:
Is this correct to be put in configure.ac:
AC_CHECK_PROG(ODBC,odbc_config,yes)
if test x"${ODBC}" == x"yes" ; then
ODBC_CFLAGS = `odbc_config --cflags`
ODBC_LIBS = `odbc_config --libs` -lodbcinst
else
ODBC_CFLAGS = `pkg-config odbc --cflags`
ODBC_LIBS = `pkg-config odbc --libs` -lodbcinst
fi
AC_SUBST(ODBC_CFLAGS)
AC_SUBST(ODBC_LIBS)
If it is - how do I use ODBC_FLAGS/ODBC_LIBS in my subproject?
EDIT2:
Based on this answer I used the following code:
In the main configure.ac:
AC_CHECK_PROG(ODBC,odbc_config,yes)
if test x"${ODBC}" == x"yes" ; then
ODBC_CFLAGS = `odbc_config --cflags`
ODBC_LIBS = `odbc_config --libs` -lodbcinst
else
ODBC_CFLAGS = `pkg-config odbc --cflags`
ODBC_LIBS = `pkg-config odbc --libs` -lodbcinst
fi
AC_SUBST(ODBC_CFLAGS)
AC_SUBST(ODBC_LIBS)
In the libodbc_lib/Makefile.am:
libodbc_lib_la_CXXFLAGS = -I../../dbinterface \
-DUNICODE \
-DUNIXODBC \
-I#ODBC_CFLAGS#
libodbc_lib_la_LDFLAGS = -L../dbinterface \
-ldbinterface \
#ODBC_LIB#
I regenerated configure, run it successfully and then tried running make.
I got following error:
CXXLD libodbc_lib.la
/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find #ODBC_LIB#: No such file or directory
What I did wrong?
EDIT3:
After fixing the missing S, I got following compile commands:
make[2]: Entering directory '/home/igor/dbhandler/Debug/libodbc'
/bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I/home/igor/dbhandler/libodbc -I.. -I../../dbinterface -DUNICODE -DUNIXODBC -I#IODBC_CFLAGS# -g -O0 -MT libodbc_lib_la-database_odbc.lo -MD -MP -MF .deps/libodbc_lib_la-database_odbc.Tpo -c -o libodbc_lib_la-database_odbc.lo `test -f 'database_odbc.cpp' || echo '/home/igor/dbhandler/libodbc/'`database_odbc.cpp
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I/home/igor/dbhandler/libodbc -I.. -I../../dbinterface -DUNICODE -DUNIXODBC -I#IODBC_CFLAGS# -g -O0 -MT libodbc_lib_la-database_odbc.lo -MD -MP -MF .deps/libodbc_lib_la-database_odbc.Tpo -c /home/igor/dbhandler/libodbc/database_odbc.cpp -fPIC -DPIC -o .libs/libodbc_lib_la-database_odbc.o
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I/home/igor/dbhandler/libodbc -I.. -I../../dbinterface -DUNICODE -DUNIXODBC -I#IODBC_CFLAGS# -g -O0 -MT libodbc_lib_la-database_odbc.lo -MD -MP -MF .deps/libodbc_lib_la-database_odbc.Tpo -c /home/igor/dbhandler/libodbc/database_odbc.cpp -o libodbc_lib_la-database_odbc.o >/dev/null 2>&1
mv -f .deps/libodbc_lib_la-database_odbc.Tpo .deps/libodbc_lib_la-database_odbc.Plo
/bin/sh ../libtool --tag=CXX --mode=link g++ -I../../dbinterface -DUNICODE -DUNIXODBC -I#IODBC_CFLAGS# -g -O0 -L../dbinterface -ldbinterface -o libodbc_lib.la -rpath /usr/local/lib libodbc_lib_la-database_odbc.lo
libtool: link: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/crtbeginS.o .libs/libodbc_lib_la-database_odbc.o -L../dbinterface -ldbinterface -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0 -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../lib64/crtn.o -g -O0 -Wl,-soname -Wl,libodbc_lib.so.0 -o .libs/libodbc_lib.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libodbc_lib.so.0" && ln -s "libodbc_lib.so.0.0.0" "libodbc_lib.so.0")
libtool: link: (cd ".libs" && rm -f "libodbc_lib.so" && ln -s "libodbc_lib.so.0.0.0" "libodbc_lib.so")
libtool: link: ar cru .libs/libodbc_lib.a libodbc_lib_la-database_odbc.o
libtool: link: ranlib .libs/libodbc_lib.a
libtool: link: ( cd ".libs" && rm -f "libodbc_lib.la" && ln -s "../libodbc_lib.la" "libodbc_lib.la" )
make[2]: Leaving directory '/home/igor/dbhandler/Debug/libodbc'
I still the variable name there and not their values.
Is it normal?
As UnixODBC upstream does ship and install *.pc files, I would expect that file to be both present and correct and therefore I would ignore any *-config scripts. The pkg-config system is quite well thought out and works even for quite weird cross compilation environments. The *.pc mechanism works well on Linux, on FreeBSD, on OSX, cross-compiling for Windows on Linux, to name a few.
A well-written _config program written in portable shell could do the same by basically reproducing much of the pkg-config logic in portable shell for each and every _config script, hopefully correctly.
However, odbc_config is not a portable shell script. It is a binary executable, i.e. it will regularly break for cross-compiling, as the system you build on will usually not be able to run programs like odbc_config which are built to run on the system you are building for.
And even if the flags from the *.pc files were unsuitable for a very unusual build environment: Using PKG_CHECK_MODULES defines appropriate _CFLAGS and _LIBS variables for the configure script, so even in a very unusual build environments one can always override whatever the *.pc file might contain by calling configure like
../configure ODBC_CFLAGS='-I/weird/stuff -DWEIRD_STRING="moo"' ODBC_LIBS='-L/very/weird/libxyz -lodbc'
So... using odbc_config has no advantages, upstream already provides a odbc.pc file so it is always present, so why not just always use odbc.pc?
So, in configure.ac (if builds without odbc.pc present should fail, otherwise you will have to do some AC_DEFINE and/or AM_CONDITIONAL to conditionally build with or without ODBC support) do
m4_pattern_forbid([PKG_CHECK_MODULES])dnl
PKG_CHECK_MODULES([ODBC], [odbc])
and in any subdirectory (what you call "subproject") Makefile.am or Makefile-files where you need to link somehting against libodbc, put, depending on whether you are building an executable
bin_PROGRAMS += foobar
[…]
foobar_CPPFLAGS += $(ODBC_CFLAGS)
foobar_LDADD += $(ODBC_LIBS)
or a (libtool) library
lib_LTLIBRARIES += libfoo.la
[…]
libfoo_la_CPPFLAGS += $(ODBC_CFLAGS)
libfoo_la_LIBADD += $(ODBC_LIBS)
That should work for all native and cross-compile builds in properly set up build environments, and people can still override odbc_CFLAGS and odbc_LIBS in case of problems.
Of course, you can always AC_CHECK_PROG or AC_PATH_PROG or AC_CHECK_TOOL or AC_PATH_TOOL together with an AC_ARG_VAR for the odbc_config program and then define and AC_SUBST an _CFLAGS and _LIBS variable set to the output of $ODBC_CONFIG --cflags and $ODBC_CONFIG --libs, respectively, and then then use the _CFLAGS and _LIBS vars in Makefile.am/Makefile-files as above.
However, that is a lot of code to write, and with a lot of special cases to consider, and if you have to ask about how to do this you will probably get a lot more wrong than if you just just use PKG_CHECK_MODULES.
You can always add something later if the PKG_CHECK_MODULES route actually does not work for a use case and which cannot be fixed within the pkg-config framework. Until that time (if it ever happens), I would recommend to just use the simple PKG_CHECK_MODULES method and probably be done.
So, I need to add a test in configure.ac to check for odbc_config script presence and pass it along to one of the so files generation
Autoconf has AC_PATH_PROG() for checking for a program in the executable search path. You would of course use AC_SUBST() to define one or more output variables by which to convey the results to the generated makefiles.
But no, coming back around to my comment on the answer to one of your previous questions, what you ought to do is not have configure forward information about the executable, but rather for it to determine the needed flags itself and forward them, via one or more output variables. If you continue to use odbc_config, at least conditionally, then that means having configure run it and capture the output. You should not inject shell command substitutions into your compilation commands.
And if you substitute a different mechanism, whether conditionally or exclusively, then similarly for that. (That's what your other answer describes with respect to pkg-config.)

How do I tell CMake to specify multiple linker script files to GCC?

I"m using CMake 3.17 and the GNU ARM toolchain and I'm trying to migrate a build from Eclipse to CMake. Part of the Eclipse build specifies multiple linker script files to use at link time so I set up my CMakeLists.txt file like this:
target_link_options(${application_name} PRIVATE
-mcpu=cortex-m4
-mthumb
-mfloat-abi=hard
-mfpu=fpv4-sp-d16
-fmessage-length=0
-fsigned-char
-ffunction-sections
-fdata-sections
-flto
-Wall
-Xlinker --gc-sections
-Wl,-Map,${map_file}
-T ${CMAKE_SOURCE_DIR}/ldscripts/libs.ld
-T ${CMAKE_SOURCE_DIR}/ldscripts/mem.ld
-T ${CMAKE_SOURCE_DIR}/ldscripts/sections.ld
)
But when I run make the -T option gets swallowed for the second and third files. Here's what I get when running make VERBOSE=1 after successful compilation of all sources. The linker command line followed by a warning about missing -T options:
Linking CXX executable StartupSequence.elf
/D/gcc-arm-none-eabi-9-2019-q4/bin/arm-none-eabi-g++.exe --specs=nano.specs --specs=nosys.specs -g -Og -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -flto -Wall -Xlinker --gc-sections -Wl,-Map,StartupSequence.map -T C:/svn/startup_sequence/ldscripts/libs.ld C:/svn/startup_sequence/ldscripts/mem.ld C:/svn/startup_sequence/ldscripts/sections.ld #CMakeFiles/StartupSequence.dir/objects1.rsp -o StartupSequence.elf ../Drivers/CMSIS/DSP/Lib/libarm_cortexM4lf_math.a ../Middlewares/Third_Party/mbedTLS/library/libmbedcrypto.a
d:/gcc-arm-none-eabi-9-2019-q4/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:/svn/startup_sequence/ldscripts/sections.ld contains output sections; did you forget -T?
Why does the -T not get sent to the command line properly for the last two files?
I've tried separating the link script specification into three separate calls to target_link_options and enclosing each script specification in double quotes but it seems to have no effect.
By default, CMake de-duplicates compile and link options. That is, multiple -T options are combined into the single one.
CMake doesn't know which options are actually bonded with the further arguments, but provides a SHELL: mechanism for define such options:
target_link_options(${application_name} PRIVATE
"SHELL:-T ${CMAKE_SOURCE_DIR}/ldscripts/libs.ld"
"SHELL:-T ${CMAKE_SOURCE_DIR}/ldscripts/mem.ld"
"SHELL:-T ${CMAKE_SOURCE_DIR}/ldscripts/sections.ld"
)
This mechanism is described in the documentation for target_link_options command.
The same mechanism works for compiler options passed to target_compile_options, see that question and my answer for it.
Because -T is interpreted as an single option. Glue -T with the path instead. Try:
-T${CMAKE_SOURCE_DIR}/ldscripts/libs.ld
-T${CMAKE_SOURCE_DIR}/ldscripts/mem.ld
-T${CMAKE_SOURCE_DIR}/ldscripts/sections.ld

How to set gcc flags in Emscripten

I compile with the following command:
gcc -Wall -march=native -O3 -ffast-math -I/usr/local/include -I/usr/local/include -o waon main.o notes.o midi.o analyse.o fft.o hc.o snd.o -L/usr/local/lib -L/usr/local/lib -lfftw3 -L/usr/local/lib -lsndfile -lm
I now would like to compile with Emscripten. How do I convert the above gcc command into an emcc command?
The command you have described in the question is linking rather than compiling. However in general you should just be able to replace gcc with emcc and it will do the right thing. In this case you will need to replace not only this linking command but also the commands used to compile the sources to the .o files.
It would probably be a good idea to take out the -march option.
It looks like your project is using libsndfile and FFTW. You will probably need to compile these libraries yourself using emscripten. Both of them are using autotools so with a bit of luck you can compile them with emscripten simply by adding the following parameters when you run the configure script:
./configure --prefix=$HOME/emscripten-libs CC=emcc
make && make install
Then when you link your program you can specify -L$HOME/emscripten-libs/lib instead of -L/usr/local/lib.
Make research about emsdk download&setup on your computer.
Download emsdk instruction
Next interest link is :
emcc or em++ instruction
https://emscripten.org/docs/tools_reference/emcc.html
When you setup emcc in command line you can see this project (i make emcc final look based on python script runner.py etc.):
c-cpp-to-javascript
Basic and useful example's :
Pretty analog with gcc :
Args:
-lGL for openGL
-s TOTAL_MEMORY=512MB --memory-init-file 1 Memory staff
--preload-file folderWithImages/--use-preload-plugins If you use assets
-I forInclude/someheader.h
-L libraryFolder/someLib.lib
-std=c11
Simple run:
./emcc -O2 a.cpp -o a.js
or
./emcc -O2 a.cpp -o a.html
Links:
./emcc -O2 a.cpp -o a.bc
./emcc -O2 b.cpp -o b.bc
./emcc -O2 a.bc b.bc -o project.js
Or :
to get JS
emcc -s WASM=1 myAdds.a myLib.a source1.c source2.cpp -o build.js
to get html
emcc -s WASM=1 myAdds.a myLib.a source1.c source2.cpp -o build.html
Link together the bitcode files:
emcc project.bc libstuff.bc -o allproject.bc
Compile the combined bitcode to HTML
emcc allproject.bc -o final.html
Important note :
You can't take an existing .a library and convert it. You must build lib with emcc also.

How can i print the compilation options on making several C files using GCC and make

I want to print my whole file compilation options on make in my console on build.
For example on compiling test1.c test2.c test3.c using make
should print like
cc -g -O1 -Wall test1.c
cc -g -O1 -Wall test2.c
cc -g -O1 -Wall test3.c
make -n will show the commands make would execute without running them. Is that what you mean?
Use make -B -n to see all the build commands without actually building anything.

gcc link error occurred

I compiled with gcc
gcc -l. 'net-snmp-config --cflags'
-fPlC -shared -c -o matsu_object.o tsu_object.c
but this error occurred
gcc: -lcrypto: Because a link was
not completed, the input file of the
linker was not used
What's wrong?
Did you mistype the question? There's no way for that to output the message you write, and I would expect that the proper command is something more like
gcc -L. `net-snmp-config --cflags` -fPIC -shared -c -o matsu_object.o tsu_object.c
Notice the -L uppercase, backticks instead of single quotes, and upper-case I in PIC.
Also, you don't say what you're trying to do, but net-snmp-config should also take at least one of --libs or --agent-libs as well.
Ah, I didn't read closely enough...
-c means "compile", that is: generate from tsu_object.c, a compiled matsu_object.o.
Without -c, the compiler actually links, that is: generate from *.o, a.out or other specified file.
-shared (and linker flags like -l and -L) are only meaningful when linking. They're meaningless when compiling, as you are doing here because of -c.
Please correct the command-line in the question to accurately reflect what you're running, and give some more explanation as to what you're trying to do.
I think you are using ticks ' instead of back ticks `. Does --cflags really give linker options? I think you are at the link step here. Also what is the effect of -c at a link. I thought -c was compile only and not attempt to link.
You used single quotes instead of backquotes.
Instead of this:
gcc -l. 'net-snmp-config --cflags' -fPlC -shared -c -o matsu_object.o tsu_object.c
You should type:
gcc -l. `net-snmp-config --cflags`-fPlC -shared -c -o matsu_object.o tsu_object.c
net-snmp-config is a program. When you run it with --cflags, it evaluates to the correct cflags that you should be using to compile your program.
But you know what? You should be using autoconf. Even for something this small, it usually makes sense to do the work. Most people I know need to compile on more than one platform...

Resources