It's 2021, does Oracle not support modern operating systems that use compiler ABIs released over 6 years ago?
$ make -f demo.mk
rm -rf SunWS_cache
rm -rf cdemo81 cdemo81.o occidml occidml.o occiobj occiobj.o occiobjo* occiobjm* occiobj.h occiobjout.type
/usr/bin/gcc -c -I../include -DLINUX -D_GNU_SOURCE -D_REENTRANT -g cdemo81.c
/usr/bin/g++ -o cdemo81 -g cdemo81.o -L../../ -locci -lclntsh -lpthread
make -f demo.mk buildocci OBJS=occidml.o EXE=occidml
rm -rf SunWS_cache
/usr/bin/g++ -c -I../include -DLINUX -D_GNU_SOURCE -D_REENTRANT -g occidml.cpp
/usr/bin/g++ -o occidml -g occidml.o -L../../ -locci -lclntsh -lpthread
occidml.cpp:291: error: undefined reference to 'oracle::occi::SQLException::getMessage[abi:cxx11]() const'
occidml.cpp:63: error: undefined reference to 'oracle::occi::SQLException::getMessage[abi:cxx11]() const'
occidml.cpp:83: error: undefined reference to 'oracle::occi::SQLException::getMessage[abi:cxx11]() const'
occidml.cpp:106: error: undefined reference to 'oracle::occi::SQLException::getMessage[abi:cxx11]() const'
collect2: error: ld returned 1 exit status
The default libocci.so.19.1 is not compatible with g++ versions 5 and above. Please contact Oracle support to get the specially built libocci to work with g++ 5 and above.
For the supported Linux platforms, please try
make -f demo_rdbms.mk occidemos (for building all OCCI demos)
make -f demo_rdbms.mk occidml (for building just one demo like occidml)
make -f demo_rdbms.mk buildocci EXE=myapp OBJS=myapp.o (for a custom .cpp program)
The above is with a regular installation. You didn't mention which version of OCCI you are trying and the version of g++.
Related
I got this error when I do make
gcc -o tests/simple_test tests/simple_test.o -L. libtraceback.a -Wall -Werror -gdwarf-2 -O0 -m32 -fno-stack-protector -fno-omit-frame-pointer -Itraceback/ -mpreferred-stack-boundary=2 -static
/usr/bin/ld: cannot find crt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc_eh.a when searching for -lgcc_eh
/usr/bin/ld: cannot find -lgcc_eh
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
I read one post and tried
sudo ln -s /usr/lib/x86_64-linux-gnu /usr/lib64
But it doesn't help, is there any reason for this?
Im running on a surface pro 2 using vmware running 64bits ubuntu 13.10.
If you do not have any parcticular reason to build a 32bit application on a 64bit machine just do not use the option -m32.
In case you are following this tutorial then fixed make file code is below working on Ubuntu 20
# $# = target file
# $< = first dependency
# $^ = all dependencies
# First rule is the one executed when no parameters are fed to the Makefile
all: run
kernel.bin: kernel-entry.o kernel.o
ld -m elf_i386 -o $# -Ttext 0x1000 $^ --oformat binary --entry main
kernel-entry.o: kernel-entry.asm
nasm $< -f elf -o $#
kernel.o: kernel.c
gcc -m32 -ffreestanding -c $< -o $# -fno-pie
mbr.bin: mbr.asm
nasm $< -f bin -o $#
os-image.bin: mbr.bin kernel.bin
cat $^ > $#
run: os-image.bin
qemu-system-i386 -fda $<
clean:
$(RM) *.bin *.o *.dis
To run make file
make run
to clean all output files
make clean
I made a custom bash script for assembling, compiling, and linking the kernel but when it gets to the line for linking i run into an error (see below). Im running this on OSX, newest build so im not sure why. Any suggestions?
ld: unknown option: -T
My script:
echo Now assembling, compiling, and linking your kernel:
nasm -f aout -o start.o start.asm
gcc -Wall -O -fstrength-reduce -fomit-frame-pointer -finline-functions -nostdinc -fno- builtin -I./include -c -o main.o main.c
ld -T link.ld -o kernel.bin start.o
echo Done!
Before you try to create your own build scripts, have you managed to get the OSX kernel to build with its own scripts? This site by one of Apple's kernel engineers tells you how it's done.
I have a C project that won't link correctly, and I suspect it's because of the --as-needed flag passed to the ld program by gcc. Because of that flag, gcc sees any linked library listed as an option before the *.c files as unnecessary, and won't link them.
PREFIX?=/usr/local
CFLAGS=-D_LARGEFILE64_SOURCE=1 -g -Wall -I${PREFIX}/apr/include/apr-1 -I${PREFIX}/apr/include/apr-util-1
LDFLAGS=-lapr-1 -pthread -laprutil-1
all: devpkg
devpkg: bstrlib.o db.o shell.o commands.o
install: all
install -d $(DESTDIR)/$(PREFIX)/bin/
install devpkg $(DESTDIR)/$(PREFIX)/bin/
clean:
rm -f *.o
rm -f devpkg
rm -rf *.dSYM
When I run this makefile I get the following.
cc -D_LARGEFILE64_SOURCE=1 -g -Wall -I/usr/local/apr/include/apr-1 -I/usr/local/apr/include/apr-util-1 -c -o bstrlib.o bstrlib.c
cc -D_LARGEFILE64_SOURCE=1 -g -Wall -I/usr/local/apr/include/apr-1 -I/usr/local/apr/include/apr-util-1 -c -o db.o db.c
cc -D_LARGEFILE64_SOURCE=1 -g -Wall -I/usr/local/apr/include/apr-1 -I/usr/local/apr/include/apr-util-1 -c -o shell.o shell.c
cc -D_LARGEFILE64_SOURCE=1 -g -Wall -I/usr/local/apr/include/apr-1 -I/usr/local/apr/include/apr-util-1 -c -o commands.o commands.c
cc -D_LARGEFILE64_SOURCE=1 -g -Wall -I/usr/local/apr/include/apr-1 -I/usr/local/apr/include/apr-util-1 -lapr-1 -pthread -laprutil-1 devpkg.c bstrlib.o db.o shell.o commands.o -o devpkg
/tmp/ccZcAm9b.o: In function `main':
/home/zach/Desktop/devpkgzed/devpkg.c:14: undefined reference to `apr_pool_initialize'
/home/zach/Desktop/devpkgzed/devpkg.c:15: undefined reference to `apr_pool_create_ex'
/home/zach/Desktop/devpkgzed/devpkg.c:29: undefined reference to `apr_getopt_init'
/home/zach/Desktop/devpkgzed/devpkg.c:31: undefined reference to `apr_getopt'
My issue is that I don't really understand how make is coming up with these commands via the CFLAGS that are set. How can I get the linker options to follow the compilation part instead of the other way around, which is triggering this issue?
Make has built-in rules to compile source files and link executables and libraries. The commands you list are produced by these rules.
The reason this fails for you is that, when linking, libraries should be listed after object files, because the linker does a single pass through its arguments and will discard any symbols that are not unresolved at the time they are seen. To correct it, put your libraries in the LDLIBS variable, not the LDFLAGS variable (i.e. just replace LDFLAGS by LDLIBS). The LDFLAGS variable is meant for non-library options for the linker, such as -L or -shared etc
I'm trying to create a shared library with my gcc. It's a gcc for vxworks (thats probably the problem...).
I use the gcc as following:
./gcc -shared -B/path/to/gnutools/bin -o test.so test.c
Result:
/path/to/ld: -r and -shared may not be used together
collect2: ld returned 1 exit status
If I try the same with the linux gcc, there's no problem. So i guess the gcc for VxWorks automatically passes the -r (or -i, which is the same and results in the same) flag to the linker. Is there a way to suppress this?
Greetz
marty
PS: making it static is not really an alternative...
Try compile object file separately with -fPIC and then link:
gcc -Wall -fPIC -c -o test.o test.c
gcc -Wall -shared -o test.so test.o
Another suggestion is to use libtool (at least to figure out the correct flags).
A workaround may be to go directly with ld:
ld -shared -o test.so test.o -lc
I'm trying to install cloog-ppl 0.15-11 in my 64 bit ubuntu 10.10. I get the following error during make. I guess it is wrt linking.
gcc -DHAVE_CONFIG_H -I. -I./include/cloog -I./include -I./include -Wall -fomit-frame-pointer -g -O2 -MT cloog.o -MD -MP -MF .deps/cloog.Tpo -c -o cloog.o `test -f 'source/cloog.c' || echo './'`source/cloog.c
mv -f .deps/cloog.Tpo .deps/cloog.Po
/bin/bash ./libtool --tag=CC --mode=link gcc -Wall -fomit-frame-pointer -g -O2 -o cloog cloog.o libcloog.la -lgmp -lppl_c -lppl -lgmpxx
libtool: link: gcc -Wall -fomit-frame-pointer -g -O2 -o .libs/cloog cloog.o ./.libs/libcloog.so /usr/lib/libgmp.so -lppl_c -lppl /usr/lib/libgmpxx.so
//usr/local/lib/libppl_c.so: undefined reference to `std::__detail::_List_node_base::_M_unhook()#GLIBCXX_3.4.15'
//usr/local/lib/libppl_c.so: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)#GLIBCXX_3.4.15'
//usr/local/lib/libppl_c.so: undefined reference to `std::__detail::_List_node_base::swap(std::__detail::_List_node_base&, std::__detail::_List_node_base&)#GLIBCXX_3.4.15'
//usr/local/lib/libppl_c.so: undefined reference to `std::__detail::_List_node_base::_M_transfer(std::__detail::_List_node_base*, std::__detail::_List_node_base*)#GLIBCXX_3.4.15'
collect2: ld returned 1 exit status
make[1]: *** [cloog] Error 1
make[1]: Leaving directory `/home/praveen/cloog-ppl-0.15.11'
make: *** [all-recursive] Error 1
Can some one help me out on this ?
I have the same problem that I worked for a whole day!! I have a hit, as least this bug disappeared.
When it refers to GLIBCXX_3.4.15 it means that you are using a g++ or gcc with the library not providing the functions or classes you need, very likely 4.4 or 4.5. I changed my g++ and gcc to 4.6 and the problem was solved. For some references, you can check out the following:
How standard lib linked by libstdc++.so.6
Notice: I only get libstdc++.so.5 in /usr/lib when I have g++-4.5 installed. I think libstdc++ is the library that g++ and gcc used.
for changing the compiler version in Linux, see the following link:
Upgrade your compiler
Hope it helps!