Inb4 use busybox.
I need to have the flag HASSECURITY disabled. In busybox the flag is enabled, and I do not see any way to change the compilation flags of buysbox'es components(however if there is a way to do it - i would like to learn about it)
I have been trying to cross - compile the lsof-4.87 from source using arm-linux-androideabi-gcc-4.8 provided in the adt bundle (20140321). Before running the Configure script i export the environment variables:
export LSOF_ARCH="armv7l"
export LSOF_CC=${HOME}/NDK/adt-bundle-linux-x86_64-20140321/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc
export LSOF_CCV=4.8
However during the Configure script execution I still get the error message:
Cannot determine C library type; assuming it is not glibc
Would you have any idea how to solve this problem?
Related
I was checking out Pion Mediadevices and trying to cross-compile the webrtc example for a rasperry pi zero from my windows computer. When I try to build the example though, I get these errors from Windows command prompt:
# github.com/pion/mediadevices/pkg/codec/mmal
..\..\pkg\codec\mmal\params.go:30:9: undefined: newEncoder
# github.com/pion/mediadevices/pkg/driver/microphone
..\..\pkg\driver\microphone\microphone.go:27:10: undefined: malgo.AllocatedContext
..\..\pkg\driver\microphone\microphone.go:34:2: undefined: malgo.DeviceInfo
..\..\pkg\driver\microphone\microphone.go:40:13: undefined: malgo.InitContext
..\..\pkg\driver\microphone\microphone.go:40:36: undefined: malgo.ContextConfig
..\..\pkg\driver\microphone\microphone.go:78:25: undefined: malgo.DeviceInfo
Also because the program is for the pi zero I edited the import section to have "github.com/pion/mediadevices/pkg/codec/mmal" and commented out the x264 import.
What is the correct way to build this example?
Edit: Upon further investigation, I found that the error message above:
..\..\pkg\codec\mmal\params.go:30:9: undefined: newEncoder
correlates to a call to the function newEncoder which is declared in a seperate go file, mmal.go, in the same folder as params.go. Both of these files have package mmal at the top before their imports and the folder they're contained in is also called mmal. Is there any problems there causing the function to not be viewable to params.go?
mediadevices currently uses cgo to give us access to camera/microphone and codecs. Cross-compiling in cgo is possible but you would very likely need to cross-compile mmal codec as a static library yourself, but this requires access to the source code.
Unfortunately, mmal is not an open-source library. Therefore, the only option left is to compile the library on the raspberry pi since mmal should be installed on your system already.
Note: I'm the mediadevices author 😃.
I need to use an externally built C library doing some calculation with trigonometric services to my Ada program. I do it well using an stm32 bb runtime (SFP) but when trying to do the same in a native environment using the default Ada runtime, I end up with linking problems. Hope I can find some help here.
I tried several configurations of project files (gpr) solutions and I always end up with the same kind of linking error:
Memory region Used Size Region Size %age Used/opt/gnat/gnat_native/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.3.1/ld: /home/pulsar/repos/pulsar-software/something/lib_c/libC.a(something.o): in function `compute':
(.text+0xa5): undefined reference to `sin'
collect2: error: ld returned 1 exit status
Here is what I've got so far.
The C library build sequence is as follows (confirmed by the library provider):
$ gcc -c something.c -o something.o
$ ar -r libsomethingLib.a something.o
The C library gpr file something_lib_c.gpr:
library project Something_Lib_C is
for Languages use ("C");
for Externally_Built use "true";
for Source_Dirs use ("src_c");
for Library_Dir use "lib_c";
for Library_Name use "somethingLib";
for Library_Kind use "static";
end Geocaging_Lib_C;
In the lib_c directory, I have the actual library libsomethingLib.a
In the src_c directory, I have the header API to use the C library (something.h):
#ifndef _GEOCAGING_H
#define _GEOCAGING_H
typedef struct something_s something_t;
extern void compute(something_t* const self);
#endif // _GEOCAGING_H
Then here is the Ada project file that wraps the C library something_lib.gpr:
with "something_lib_c.gpr";
project Something_Lib extends "../settings.gpr" is
for Languages use ("Ada");
for Source_Dirs use ("./src_ada");
for Object_Dir use "obj" & "/" & Target & "/" & Build;
end Geocaging_Lib;
In the directory src_ada, I have the Ada API wrapper (something_api.ads):
with Interfaces; use Interfaces;
with Interfaces.C; use Interfaces.C;
package Something_API is
type T_Something is null record;
procedure Compute (Something : access T_Something);
with Import => True,
Convention => C,
External_Name => "compute";
end Something_API;
And finally, I call the compute service from my Ada program by with-ing the Ada API wrapper.
Once again, when building/linking the whole thing for an arm-eabi target, using an stm32-full or stm32-sfp Ada runtime, everything runs well and the behavior of the library is validated.
The whole point is I'd like to do the thing in a native environment in order to run CI tests on it and I can't find a way to pass the link stage.
Last thing, in the Settings.gpr generic project file contains some common Ada build/bind/build switches that I can provide if necessary. But I can't see how this could work in arm and not in native with the same options. This HAS to be linked to the default Ada runtime thing...
Any idea?
If you were building with a C main program, what would you have to do to bring in the maths libraries at link time? ... possibly something like
gcc foo.c -l somethingLib -lm
What you need to do is to arrange for the -lm to be included whenever you call in something_lib_c.gpr.
I think that what you need to do is to modify library project Something_Lib_C to include the line
for Library_Options use ("-lm");
OK, my HUGE apologies to all of you who tried to help...
The solution was more obvious than I thought, I was just too obsessed with the thing working in arm and not in native.
BUT, the solution was simply to add the -lm switch to the global linker switches. Hence:
Ada_Switches_Linker_Native := (
"-Wl,--gc-sections"
,"-Wl,--verbose"
,"-Wl,-lm"
);
package Linker is
case Target is
when "native" =>
for Switches ("Ada") use Ada_Switches_Linker_Native;
...
end case;
end Linker;
In case it could be of interest for someone else, the fact that it works straightforward in arm environment and not in native is because the default runtime does not embed a specific mathematical library and you are supposed to use the C one provided by gcc, linking through the -lm switch.
In the contrary, when using a target specific runtime like arm (for stm32f4 for example), the correct mathematical libraries are provided, selected and automatically linked depending on your compilation options (-mhard-float, -msoft-float, etc.).
Sorry again and thank you very much for your time.
Here is my code:
package main
import (
kusb "github.com/karalabe/usb"
tusb "github.com/trezor/trezord-go/usb"
)
func main() {
kusb.Enumerate(0, 0)
tusb.InitHIDAPI(nil)
}
When I compile (I'm using go mod to manage the packages), it returns this error:
duplicate symbol _libusb_dev_mem_alloc in:
/var/folders/fm/1rln65d94mn45s0h5l78tdyh0000gp/T/go-link-624554542/000002.o
/var/folders/fm/1rln65d94mn45s0h5l78tdyh0000gp/T/go-link-624554542/000020.o
ld: 136 duplicate symbols for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Why?
Some investigation i had:
The both packages use the same hidapi and libusb C packages in order to interact with usb devices.
Those C packages are identical, hence it defines the same functions so i think it is directly related to the error.
in trezord-go/usb, they include .C file, not the header file.
It is very counterintuitive to me because in the perspective of package users, I shouldn't need to worry about how a C package is used in the internal of the package, only the exposed types, functions and its behaviors.
Can anyone really explain what is going on here and how can I import both of them? They do different functions, eventhough they use the same C package.
From here: https://www.repustate.com/blog/go-duplicate-symbols-for-architecture-x86_64/
"What does this mean? Well, it means we're trying to link the same symbol name (in our case, a method) from two (or more) different source files. The fix was easy: rename one of the methods by updating the header file, the source file (.c or .cpp file) and lastly, updating your references to the symbol in your Go code, if it is directly referenced there."
Will it help ?
I was running into the same issue for hours and finally found the fix on a google groups channel
A package you import could be using cgo, you don't have to be using it directly
...
You can try CGO_ENABLED=0 go build and if it works then it is cgo related.
This was the charm that i was looking for! Hope this works for you too.
I have successfully taken bio-metric prints and posted to the node server using the futronic sdk. I want to be able to use this library likewise for matching in the server because that's where the bio-metric prints for all users are stored. I stubbled upon the node-ffi library that helps define equivalent C functions that I have exported and compiled it down to a .dll file.
Now the challenge here is that I have tried to port the ftrAnsiSDK functions but the ftrScanAPI.dll and the ftrAnsiSDK.dll file could not be compiled together. It gives this error:
...collect2.exe [Error] ld returned 5 exit status
When I compile and export the functions that are not dependent on these two libraries, my code works fine and the functions are easily exported and used in the node server. Please can any one give me a hint?
Here is the link to the repo. It consists of the lib and .dll library that is been used.
For the server code here is a snippet of what I am trying to achieve:
var libm = ffi.Library('lib/visystem', {
'HelloWorld': [ 'void', [] ],
'PrintErrorMessage': [ 'void', ['int'] ],
'CaprureImage': [ 'int', ['int','int','int'] ]});
The HelloWord and PrintErrorMessages are methods that I used as a test case to ensure the functions are being exported before I proceeded to the main functions (you can see the function definition in from the code in the repo.. ) that depends on the futronic lin and sdk.
I am currently using a 64-bit operation system and I installed the same program on a 32-bit machine to be sure, but it still did not compile and export the function. The code editor I am using is Dev++C.
Can anyone help or even give me hint on how to achieve this goal?
As a disclaimer, I'm not familiar with the Dev-C++ IDE or MinGW development.
However, after a cursory look at your github repo, according to your libvisystem.def file, it appears that the only functions that are exported by your DLL are:
HelloWorld
PrintErrorMessage
ReadTemplateFile
SaveBmpFile
SaveTemplateFile
This is also confirmed when looking at the libvisystem.a library header:
So you should probably start by manually add the rest of the exported functions in your dll.h to the def file, in a similar manner to the ones that are already there, and see if that changes anything.
NOTE:
I'm not sure whether the __declspec(dllexport) directive is ignored by the Dev-C++ compiler/linker and it uses the def file instead. Perhaps others on SO have an idea.
here is the code that i wrote: link
and im selecting the following defconfig(exynos8890-herolte_kor_defconfig) for compiling defconfig file
and my core function (kernel/examplepatch/core.c) is depend on the following options as described in kernel/example/Kconfig
config HAVE_EXAMPLEPATCH
bool
help
Arch supports kernel example patch
config EXAMPLEPATCH
bool "Kernel example patch"
depends on DYNAMIC_FTRACE2
depends on MODULES
depends on SYSFS
depends on KALLSYMS_ALL
depends on HAVE_EXAMPLEPATCH
help
Say Y here if you want to support kernel example patch.
and the following options depends on MODULES , depends on SYSFS and depends on KALLSYMS_ALL are selected through defconfig which i selected at compile time(exynos8890-herolte_kor_defconfig) and the rest dependencies depends on HAVE_EXAMPLEPATCH and depends on DYNAMIC_FTRACE2 are selected through arch/arm64/Kconfig link within CONFIG_ARM64(and exynos8890-herolte_kor_defconfig has CONFIG_ARM64 option too)
but unfortunatly the kernel/examplepatch/core.c refuses to compile i cant see the core.o (compiled object) in kernel/examplepatch
so what part or things are wrong?
thanx
regards