I'm trying to cross compile perl 5.24 using following method since the target machine does not have ssh installed.
https://github.com/arsv/perl-cross
Just for Fyi, my local machine is ubuntu x86_64 GNU/Linux.
I configure the toolchain with the following option:
./configure -Dsysroot=$QNX_TARGET -Dcc=ntoarmv7-gcc -Dtargetarch=armle -Dprefix=$HOME/localperl -Duseshrplib
The reason I think the above scripts worked just fine because it generates the makefile with the following message:
Generating config.h
Extracting config.h (with variable substitutions)
Generating Makefile.config
Configuration completed for native build
platform: x86_64-
c compiler: ntoarmv7-gcc
ld: ntoarmv7-gcc
ar: ar
ranlib: ranlib
when i run the make -j4 option i end up getting either of the following 2 results:
./generate_uudmap uudmap.h bitcount.h mg_data.h
./generate_uudmap: 1: ./generate_uudmap: Syntax error: word unexpected (expecting ")")
make: *** [uudmap.h] Error 2
OR
cp -f op.c opmini.c
cp -f perl.c perlmini.c
cp -f ext/re/re.pm lib/re.pm
sh cflags.SH
cp -f dist/ExtUtils-ParseXS/lib/ExtUtils/xsubpp lib/ExtUtils/xsubpp
ntoarmv7-gcc -DPERL_CORE --sysroot=/opt/qnx650/target/qnx6 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC -Wno-unused-function -c -o op.o op.c
./miniperl_top lib/unicore/mktables -w -C lib/unicore -P pod -maketest -makelist -p
./miniperl_top: no ./miniperl found; build it before using miniperl_top
make: *** [lib/unicore/CombiningClass.pl] Error 1
I couldn't find much info on how to resolve the above issues. Could it be because i have not provided correct setting options for ./configure ?? If so, can you provide more insight on this.
EDIT:
It looks like i was passing the wrong information to ./configure script (it was considering it as the native rather than cross), I updated it with the following and was able to make bit of progress.
./configure -Dsysroot=/opt/qnx6 -Dcc=arm-unknown-nto-qnx6.6.0eabi-gcc --target-tools-prefix=arm-unknown-nto-qnx6.6.0eabi- --target=arm-unknown-nto-qnx6.6.0eabi --host=arm-unknown-nto-qnx6.6.0eabi -Dprefix=$HOME/localperl
with this, the configuration was successfull for the cross platform. Now when I perform the make, it runs fine for a bit and I run it following error
arm-unknown-nto-qnx6.6.0eabi-ar cru libperl.a op.o perl.o gv.o toke.o perly.o pad.o regcomp.o dump.o dquote.o util.o mg.o reentr.o mro_core.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o keywords.o caretx.o time64.o DynaLoader.o
arm-unknown-nto-qnx6.6.0eabi-ranlib libperl.a
./miniperl_top statars > static.list
./miniperl_top extlibs > ext.libs
arm-unknown-nto-qnx6.6.0eabi-gcc -DPERL_CORE --sysroot=/opt/qnx6 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -c -o perlmain.o perlmain.c
arm-unknown-nto-qnx6.6.0eabi-gcc --sysroot=/opt/qnx6 -Wl,-E -o perl perlmain.o libperl.a
libperl.a(pp.o): In function `Perl_pp_crypt':
pp.c:(.text+0xffd8): warning: The 'crypt' function has been deprecated in libc. Link against liblogin for extended algorithm support.
libperl.a(toke.o): In function `Perl_scan_num':
toke.c:(.text+0x27b82): undefined reference to `pow'
libperl.a(util.o): In function `Perl_drand48_r':
util.c:(.text+0xa36e): undefined reference to `ldexp'
libperl.a(sv.o): In function `S_hextract':
sv.c:(.text+0x13ca0): undefined reference to `frexp'
libperl.a(sv.o): In function `Perl_sv_vcatpvfn_flags':
sv.c:(.text+0x16cc0): undefined reference to `frexp'
libperl.a(time64.o): In function `Perl_gmtime64_r':
time64.c:(.text+0x338c): undefined reference to `fmod'
.
.
time64.c:(.text+0x359c): undefined reference to `floor'
time64.c:(.text+0x37e6): undefined reference to `ceil'
collect2: error: ld returned 1 exit status
make: *** [perl] Error 1
final problem was related to linking the libraries. adding -lm fixed the problem
arm-unknown-nto-qnx6.6.0eabi-gcc --sysroot=/opt/qnx660/target/qnx6 -Wl,-rpath,/home/swgroup/localperl/lib/perl5/5.24.0/arm-/CORE -Wl,-E -o perl perlmain.o libperl.so -lm
Related
I'm trying to compile Qt 5.15.2 for arm64 Pi4.
The configure phase fails with
ERROR: Feature 'opengles2' was enabled, but the pre-condition '(config.win32 && !features.opengl-dynamic) || (!config.watchos && !features.opengl-desktop && libs.opengl_es2)' failed.
ERROR: Feature 'eglfs' was enabled, but the pre-condition '!config.android && !config.darwin && !config.win32 && !config.wasm && features.egl' failed.
ERROR: The OpenGL functionality tests failed!
After reading the build output I see how the OpenGL test fails:
+ cd /build/pi4/parts/qtbase/build/config.tests/opengl_es2 && PKG_CONFIG_SYSROOT_DIR=/ PKG_CONFIG_LIBDIR=/build/pi4/stage/usr/lib/pkgconfig:/build/pi4/stage/usr/lib/aarch64-linux-gnu/pkgconfig:/usr/lib/aarch64-linux-gnu/pkgconfig:/usr/share/pkgconfig:/usr/lib/pkgconfig /build/pi4/parts/qtbase/build/bin/qmake "CONFIG -= qt debug_and_release app_bundle lib_bundle" "CONFIG += shared warn_off console single_arch" 'QMAKE_LIBDIR += /build/pi4/stage/usr/lib/aarch64-linux-gnu' -early "CONFIG += cross_compile" 'QMAKE_USE += opengl_es2' 'QMAKE_LIBS_OPENGL_ES2 = -L//build/pi4/stage/usr/lib -lGLESv2' 'QMAKE_INCDIR_OPENGL_ES2 = //build/pi4/stage/usr/include' /build/pi4/parts/qtbase/build/config.tests/opengl_es2
+ cd /build/pi4/parts/qtbase/build/config.tests/opengl_es2 && MAKEFLAGS= /usr/bin/make
> /usr/bin/aarch64-linux-gnu-g++ -c -march=armv8-a -mtune=cortex-a72 -O2 -w -fPIC -I. -I/build/pi4/stage/usr/include -I/build/pi4/parts/qtbase/build/mkspecs/devices/linux-rasp-pi4-v3d-g++ -o main.o main.cpp
> /usr/bin/aarch64-linux-gnu-g++ -Wl,-O1 -o opengl_es2 main.o -L/build/pi4/stage/usr/lib/aarch64-linux-gnu -L//build/pi4/stage/usr/lib -lGLESv2
> /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: warning: libglapi.so.0, needed by //build/pi4/stage/usr/lib/libGLESv2.so, not found (try using -rpath or -rpath-link)
> /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: //build/pi4/stage/usr/lib/libGLESv2.so: undefined reference to `_glapi_tls_Dispatch'
> collect2: error: ld returned 1 exit status
> make: *** [Makefile:69: opengl_es2] Error 1
But the libglapi.so.0 is exactly in -L//build/pi4/stage/usr/lib.
I executed the test step manually and it failed with the same error:
root#10cb734e2e05:~/pi4/parts/qtbase/build/config.tests/opengl_es2# /usr/bin/aarch64-linux-gnu-g++ -Wl,-O1 -o opengl_es2 main.o -L/build/pi4/stage/usr/lib/aarch64-linux-gnu -L//build/pi4/stage/usr/lib -lGLESv2
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: warning: libglapi.so.0, needed by //build/pi4/stage/usr/lib/libGLESv2.so, not found (try using -rpath or -rpath-link)
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: //build/pi4/stage/usr/lib/libGLESv2.so: undefined reference to `_glapi_tls_Dispatch'
collect2: error: ld returned 1 exit status
But if I specify the same path /build/pi4/stage/usr/lib with -rpath, the compilation succeeds:
root#10cb734e2e05:~/pi4/parts/qtbase/build/config.tests/opengl_es2# /usr/bin/aarch64-linux-gnu-g++ -Wl,-O1,-rpath=/build/pi4/stage/usr/lib -o opengl_es2 main.o -L/build/pi4/stage/usr/lib/aarch64-linux-gnu -L//build/pi4/stage/usr/lib -lGLESv2
So my question is - why the linker cannot find the same library with the -L argument but can do it if I use -rpath?
The root cause was that the linker cannot find a dependency of a dependency. LD_LIBRARY_PATH and L doesn't work in such cases. You should use -rpath-link.
You can read more details in the posts I mentioned in the end.
When compiling Qt, you can pass extra arguments for libraries you need.
In my case, I had to add the following code to make it work:
QMAKE_LIBS_OPENGL_ES2+="-Wl,-rpath,${SNAPCRAFT_STAGE}/usr/lib/" \
QMAKE_LIBS_EGL+="-Wl,-rpath,${SNAPCRAFT_STAGE}/usr/lib/" \
My solution is based on this post: Why does ld need -rpath-link when linking an executable against a so that needs another so?
and this article: Why does ld need -rpath-link when linking an executable against a so that needs another so?
I'm trying to upgrade my micronuclues to upload my code to digispark,but when I try to upgrade that happens:
Building command line tool: micronucleus...
gcc -Ilibrary -O -g -D LINUX -o micronucleus micronucleus.c micronucleus_lib.o littleWire_util.o -static -L/usr/lib/x86_64-linux-gnu -lusb
/usr/bin/ld: cannot find -lusb
collect2: error: ld returned 1 exit status
make: *** [Makefile:61: micronucleus] Error 1
I'm a little confused as to how you've gotten it compiling but not linking because, at least on Debian based distributions, the header file that would be needed during compiling is provided by the same package that provides the libusb.a that it is failing to link against.
If you are on a Debian based distro, try (re)installing libusb-dev:
sudo apt install libusb-dev
This is what I've built it against locally.
If you have a libusb.a and it's not in /usr/lib/x86_64-linux-gnu, then you'd need a different directory supplied to -L.
I'm trying to use MinGW-W64 instead of MinGW in Codelite. When I compile simple "hello, world" project it's all right. But when I try to link some libraries, I get a strange linker error. Project with exactly same settings compiles by MinGW with any problems. There are build output for both variants:
MinGW GCC 4.8.1
`C:\Windows\system32\cmd.exe /C D:/apps/mingw/bin/mingw32-make.exe -j8 SHELL=cmd.exe -e -f Makefile
"----------Building project:[ code - Debug ]----------"
mingw32-make.exe[1]: Entering directory 'D:/Projects/codelite/code'
codelite-cc D:/apps/mingw/bin/g++.exe -c "D:/Projects/codelite/code/src/main.cpp" -Wfatal-errors -g -O0 -pedantic -W -std=c++11 -Wall -o ./Debug/src_main.cpp.o -I./inc/
D:/apps/mingw/bin/g++.exe -o bin/code #"code.txt" -L./lib/ -lopengl32
mingw32-make.exe[1]: Leaving directory 'D:/Projects/codelite/code'
====0 errors, 0 warnings====`
MinGW-W64 GCC 5.2.0
`C:\Windows\system32\cmd.exe /C D:/apps/mingw-w64/mingw32/bin/mingw32-make.exe -j8 SHELL=cmd.exe -e -f Makefile
"----------Building project:[ code - Debug ]----------"
mingw32-make.exe[1]: Entering directory 'D:/Projects/codelite/code'
codelite-cc D:/apps/mingw-w64/mingw32/bin/g++.exe -c "D:/Projects/codelite/code/src/main.cpp" -Wfatal-errors -g -O0 -pedantic -W -std=c++11 -Wall -o ./Debug/src_main.cpp.o -I./inc/
D:/apps/mingw-w64/mingw32/bin/g++.exe -o bin/code #"code.txt" -L./lib/ -lopengl32
g++.exe: error: #code.txt -L./lib/: No such file or directory
mingw32-make.exe[1]: *** [bin/code] Error 1
code.mk:78: recipe for target 'bin/code' failed
mingw32-make.exe[1]: Leaving directory 'D:/Projects/codelite/code'
mingw32-make.exe: *** [All] Error 2
Makefile:4: recipe for target 'All' failed
====1 errors, 0 warnings====`
This looks like a bug in your toolchain and not in CodeLite.
There is a space between the "#code.text" and -L./lib and for some reason g++ does not see it...
I put my money on the mingw32-make tool. You can tell CodeLite to use the mingw32-make.exe from the 4.8.1 version (which worked): settings->build settings->compilers->[YOUR COMPILER NAME]->Make
Another option is to disable the option that tells CodeLite to generate Makefile that passes the object list via file to the compiler:
Settings->Build Settings->compilers->[YOUR COMPILER NAME]->Advanced tab and uncheck the option: pass object list to the linker via file
Lately i too have found the similar problem. Later i was able to figure out the issue. We just to need to go to the project settings under change makefile generator default to codelite makefile generator i think that will work.
I am trying to compile my c code on linux i386.
I have the sqlite3 library at:
/usr/lib/i386-linux-gnu/libsqlite3.so.0
/usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6
but the linker does not find them. I even specified the path manually with the -L option which I suspect is not necessary:
cc -pthread -L/lib/i386-linux-gnu -L/usr/lib/i386-linux-gnu -L../i386/debug/lib/ ./bin/i386/debug/*.o -lsculib -lpthread -lsqlite3 -o ../i386/debug/bin/myProgram
/usr/bin/ld: cannot find -lsqlite3
collect2: error: ld returned 1 exit status
make: *** [../i386/debug/bin/core] Error 1
any ideas why it does not find them?
Presumably, you also need the header files.
$ sudo apt-get install libsqlite3-dev
I trying to get a cmake build system working on linux. The project contains a bunch of executables and two libraries. One of the executables is first built as a library, then that library is linked with the object file containing the man subroutine. This was done because the rest of the executables depend on that library. The tricky part is that the main subroutine is defined inside a module that the rest of sources depend on so this needs to be compiled before the rest of the sources. The effect is that the main subroutine gets added to the resulting library. This seems to work fine on Mac OS X but, the linking state fails on Linux.
The cmake file for the failing part looks like
cmake_minimum_required (VERSION 2.8)
# Create an empty variable to hold all the source files.
set (vmec_sources "")
# Add subdirectory for all the sources.
add_subdirectory (Sources)
add_library (vmec STATIC ${vmec_sources})
add_dependencies (vmec stell)
# Define an executable and link all libraries.
add_executable (xvmec ${CMAKE_CURRENT_SOURCE_DIR}/Sources/General/vmec_main.f)
add_dependencies (xvmec vmec)
target_link_libraries (xvmec vmec stell)
if ((NOT ${NETCDF_C} STREQUAL "") AND (NOT ${NETCDF_F} STREQUAL ""))
target_link_libraries (xvmec ${NETCDF_C} ${NETCDF_F})
endif ()
When running cmake, everything configures fine and generates a make file when I run make Mac OS X everything works fine. When I run make on Linux it fails.
The output from the make VERBOSE=1 On Linux produces
Linking Fortran executable ../build/bin/xvmec
cd /home/user/reconstruction/VMEC2000 && /usr/bin/cmake -E cmake_link_script CMakeFiles/xvmec.dir/link.txt --verbose=1
/usr/bin/gfortran -cpp -D NETCDF -I /usr/include CMakeFiles/xvmec.dir/Sources/General/vmec_main.f.o -o ../build/bin/xvmec -rdynamic ../build/lib/libvmec.a ../build/lib/libstell.a /usr/lib/libnetcdf.so /usr/lib/libnetcdff.so
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/libgfortranbegin.a(fmain.o): In function `main':
(.text+0x26): undefined reference to `MAIN__'
collect2: ld returned 1 exit status
make[2]: *** [build/bin/xvmec] Error 1
make[2]: Leaving directory `/home/user/reconstruction'
make[1]: *** [VMEC2000/CMakeFiles/xvmec.dir/all] Error 2
make[1]: Leaving directory `/home/user/reconstruction'
make: *** [all] Error 2
On Mac OS X, I get
Linking Fortran executable ../build/bin/xvmec
cd /Users/user/repo/trunk/VMEC2000 && "/Applications/CMake 2.8-8.app/Contents/bin/cmake" -E cmake_link_script CMakeFiles/xvmec.dir/link.txt --verbose=1
/usr/local/bin/gfortran -framework Accelerate -cpp -D DARWIN -D NETCDF -I /Users/user/NetCDF/include -O3 -ftree-vectorize -m64 -march=native -fomit-frame-pointer -falign-functions -mfpmath=sse CMakeFiles/xvmec.dir/Sources/General/vmec_main.f.o -o ../build/bin/xvmec ../build/lib/libvmec.a ../build/lib/libstell.a /Users/user/NetCDF/lib/libnetcdf.dylib /Users/user/NetCDF/lib/libnetcdff.dylib
"/Applications/CMake 2.8-8.app/Contents/bin/cmake" -E cmake_progress_report /Users/user/repo/trunk/CMakeFiles 100
[100%] Built target xvmec
The link line looks like it is linking all the same stuff in the correct order so I don't understand why this is failing on Linux.
Turns out I had the wrong file listed as containing the main method. It seems that later versions of gfortran can link 'MAIN__' from a inside a library while gfortran-4.4 cannot.