I am writing integrations tests with the Elrond Rust testing framework.
So, I am running cargo test. But it throws this error:
note: /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o: in function `_start':
(.text+0x24): undefined reference to `main'
collect2: error: ld returned 1 exit status
How can I fix it, please?
Using this similar issue as a starting point, I would say that the problem is that your tests are configured as a rust binary, and so the compiler expects a main function.
Try to re-create your integration test cargo package as a library, by providing the --lib argument to the cargo new command. Not providing that argument creates a binary by default, according to the documentation on cargo new.
Related
Note: I have also created this as an issue for xgo here, but I thought it might be better suited as an SO question.
I am trying to cross compile my go application and one of the dependencies is the alsa.lib. I cannot get this to sucessfully compile using xgo.
Initially I tried with this command:
xgo --targets=linux/*,windows/*,darwin/* -deps=ftp://ftp.alsa-project.org/pub/lib/alsa-lib-1.1.8.tar.bz2 github.com/Lynges/susimup
And that produced this error:
/deps-build/alsa-lib-1.1.8/src/pcm/pcm_softvol.c:856: undefined reference to 'pow'
collect2: error: ld returned 1 exit status
2019/04/11 22:51:27 Failed to cross compile package: exit status 2
So then I added the depsargs to get --with-softfloat and that moved it along to a new error:
/deps-build/alsa-lib-1.1.8/src/pcm/pcm_meter.c:674: undefined reference to `dlsym'
collect2: error: ld returned 1 exit status
And that is where I am stuck now.
I have tried adding some more arguments like mentioned in the comment to this answer, but that just gave me a warning:
configure: WARNING: unrecognized options: --disable-alsamixer, --disable-xmto, --disable-nls, --disable-bat
So now I really have no idea what to do. I just want to cross compile my very simple app for arm so that it may be used on a Raspberry pi.
I have problem with building my C++ project using CLion, MINGw64.
So this is the problem I cannot handle with ._.
Everything works on Linux but on Win10 I have this log:
libBiblioteka.a(Rent.cpp.obj): In function `boost::uuids::detail::random_provider_base::random_provider_base()':
C:/msys64/mingw64/include/boost/uuid/detail/random_provider_bcrypt.ipp:40: undefined reference to `BCryptOpenAlgorithmProvider'
libBiblioteka.a(Rent.cpp.obj): In function `boost::uuids::detail::random_provider_base::get_random_bytes(void*, unsigned long long)':
C:/msys64/mingw64/include/boost/uuid/detail/random_provider_bcrypt.ipp:76: undefined reference to `BCryptGenRandom'
libBiblioteka.a(Rent.cpp.obj): In function `boost::uuids::detail::random_provider_base::destroy()':
C:/msys64/mingw64/include/boost/uuid/detail/random_provider_bcrypt.ipp:93: undefined reference to `BCryptCloseAlgorithmProvider'
collect2.exe: error: ld returned 1 exit status
I have read these references are unavaiable on win10. But there is an question:
Is there any way to workaround this?
Those are not defined in libcrypt but in libbcrypt.
Did you have the same typo in your linker flags (you should have -lbcrypt)?
I am trying to compile a C program which utilizes dl library to access shared object functions from a dynamic library I created.
The code is very simple and from a tutorial.
I initially compiled it on x86 platform using gcc with no issues.
I am now trying to compile it for arm platform and I am getting an error.
I tried using the following to compile it
arm-none-eabi-gcc -I/usr/arm-linux-gnueabi/include -L/usr/arm-linux-gnueabi/lib ex29.c -ldl -o ex29
I get the following error:
/usr/local/share/gcc-arm-none-eabi-toolchain/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/crt0.o: In function _start':
(.text+0xe0): undefined reference to__libc_init_array'
collect2: error: ld returned 1 exit status
I am not sure what is causing this error.
Thanks for any help.
I am trying to build CEF in Release mode but I get the following linker error:
AR(target)
/home/adminuser/temp/build/linux/Release/obj.target/libcef_dll_wrapper.a
LINK(target) /home/adminuser/temp/build/linux/Release/cefclient
/home/adminuser/temp/build/linux/Release/ldb.a(ldbJS.o): In function
LdbURLLoader::LoadURL(std::string)': ldbJS.cpp:(.text+0x34e):
undefined reference toCefURLRequest::Create(CefRefPtr,
CefRefPtr)' collect2: error: ld returned 1 exit
status make: *** [/home/adminuser/temp/build/linux/Release/cefclient]
Error 1
I don't get this problem when building the Debug version so I am not quite sure how to resolve it. I tried various #pragma directives to stop the compiler from optimizing out this method but to no avail.
* UPDATE *
When I remove the -DNDEBUG flag from CFLAGS_Release in the libcef_dll_wrapper.target.mk file it will build. I don't want to do this in the Release build without knowing what I'm doing though.
I am using gcc 4.8.2.
It turns out forcing the LD linker to reanalyze my libraries was the solution. The CEF application already had an elaborate scheme of makefiles that used the --start-group and --end-group indicators to do this, but the library I previously added was not included with them. I added it and linked my application without any more problems!
I have been writing some python extension modules with cython. The extensions I've written build and work well. Then, I wanted to use typed memoryviews, when accessing my numpy arrays, as they seem to have several advantages http://docs.cython.org/src/userguide/memoryviews.html
However, as soon as I use a memoryview in my cython code I will get an error when building the extension. For example, if I add this test line:
cdef double[:, ::1] X = np.zeros((100, 100))
to an existing, working cython extension. I will get the following errors:
C:\MinGW\bin\gcc.exe -shared -s build\temp.win32-2.7\Release\image_box.o build\temp.win32-2.7\Release\image_box.def -Lc:\python27\libs -Lc:\python27\PCbuild -lp
ython27 -lmsvcr90 -o x:\ARframework\python\image_ops\image_box.pyd
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0xe23): undefined reference to `___sync_fetch_and_add_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x3318): undefined reference to `___sync_fetch_and_add_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x4c81): undefined reference to `___sync_fetch_and_sub_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x4d37): undefined reference to `___sync_fetch_and_sub_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x10767): undefined reference to `___sync_fetch_and_sub_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x10793): undefined reference to `___sync_fetch_and_sub_4'
collect2.exe: error: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
I've tried to add -march=i486 to the gcc line, as suggested in this post:
undefined reference to sync_fetch_and_add_4
but that didn't solve the problem. For that matter, I also tried -march=i586 and -march=pentium without success.
Any idea what's going on here?
My platform is Windows 7, mingw version is 4.70, Cython version is 0.17.1
Thanks
I found a solution.
Actually, the gcc flag -march=i486 does solve the problem! However, when I tested it in the console I just applied it to the gcc line for the link step (that's where I got the errors) and as it didn't solve the problem I thought it just didn't work.
In fact, I need to use -march=i486 both in the compile and link steps, then there is no errors anymore.
As to how to include these flags when I build the extension, I have tried to add
import os
os.environ['LDFLAGS'] = '-march=i486'
os.environ['CFLAGS'] = '-march=i486'
to the setup.py but it didn't seem to work.
So I have modified the c:\python27\Lib\distutils\cygwinccompiler.py to include these flags in the compile and link steps. Not sure if this is very elegant way of setting these flags. Any alternatives are welcome!