I was trying to cross-compile from a Debian PC for a BeagleBone Black, and i was able to build an "hello-world" sample, and build the wxWidgets, but when i compiled a wxWidgets app (the "minimal" sample) i failed, 'cause i've not been able to find how to get and link the needed libraries for armhf (GTK+, X11, etc... see my question here)
I've found a page explaining how to use BuildRoot to compile for a Raspberry, so i took that route and i was able to configure and make a "host" which compiled the wxWidgets first, and the "minimal" sample app next.
Problem is that on my BBB it does'nt run 'cause different gclib version
debian#beaglebone:~$ ./minimal
./minimal: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.28' not found (required by ./minimal)
debian#beaglebone:~$ ldd --version
ldd (Debian GLIBC 2.24-11+deb9u3) 2.24
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
So, i'm again bashing my head against a wall.
What options should i use in BuildRoot to be able to use the same gcc (and all the required libraries, which i don't know to what should i look) that are present in my BBB?
Linux version 4.9.88-ti-r111 (root#b9-am57xx-beagle-x15-2gb) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP PREEMPT Sun Apr 22 08:04:34 UTC 2018
gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
It sounds like you are building with one environment and running in a different environment.
That's akin to compiling on one distro and trying to run on another distro.
Or even compiling on one distro release and using another to run - e.g. Debian Jessie vs. Stretch.
Further evidence is that you mention:
BuildRoot as your build environment
debian#beaglebone and ldd (Debian GLIBC 2.24-11+deb9u3) 2.24
The fundamental version conflict is that BuildRoot and Debian 9 use different versions of libc (and other libraries)
The proper way to address this is by building inside a matching environment. In this case that would be Debian 9 - either as distro proper or at least as a chroot. The package that you should install is: crossbuild-essential-armhf
That will get you the necessary tool-chains and dependencies.
Related
I would like to know if any of you can help me with the following problem.
I need to install the libusb-1.0.so.0 library on suse linux enterprise server 32 bits. I need the library because it is require by SANE software.
The operating system has some restriction, so i cannot run zypper or yast, But i can run rpm --nodeps -i to install rpm packages.
I also tried to download the libusb project and compile it, but the operating system does not have gcc installed on it.
I was wondering if any one has libusb-1.0.so.0 that works on SLES 32 bits or if any one has an ISO of SLES 32 bits.
Thanks.
Unfortunately you did not tell the used service pack, yet.
Assuming that you're using the latest SP4, I'd recommend to heck out https://scc.suse.com/patches and search for the keyword „slessp4-libusb-1_0-12986“.
The pages provides you 5 patches. Select architecture "i586, i686" in the result list. You'll then get the compiled and source RPM of libusb-1_0.
You need to login first to download these packages. Please note that you also need to have a valid subscription. Since SLES 11 SP4 is out of general support, you probably need to have an LTSS subscription.
I try to install mobicents-Restcomm-JBoss-AS7
but - found many src distributions, i don't want to go down the road - compiling the whole src tree.
Many docs point some urls - that i should look mobicents-Restcomm-JBoss-AS7-*-zip.
On github jss7-8.0.0-179 is a source distrib.
any working link with binary?
going with source build - is a little pain to do a proof of concept...
if it matters:
CentOS Linux release 7.6.1810 (Core)
java version "1.7.0_221"
OpenJDK Runtime Environment (rhel-2.6.18.0.el7_6-x86_64 u221-b02)
OpenJDK 64-Bit Server VM (build 24.221-b02, mixed mode)
Seems all the binary have been removed from repo. You might to get binaries if you have it installed before now.
cant install WXWidgets from source (wxwidgets3.0-3.0.2.orig)
After configure which apparently runs without errors:
config.status: executing wx-config commands
Configured wxWidgets 3.0.2 for `x86_64-unknown-linux-gnu'
Which GUI toolkit should wxWidgets use? GTK+ 2 with support for GTK+ printing libnotify
Should wxWidgets be compiled into single library? no
Should wxWidgets be linked as a shared library? yes
Should wxWidgets support Unicode? yes (using wchar_t)
What level of wxWidgets compatibility should be enabled?
wxWidgets 2.6 no
wxWidgets 2.8 yes
Which libraries should wxWidgets use?
STL no
jpeg builtin
png sys
regex builtin
tiff builtin
zlib sys
expat sys
libmspack no
sdl no
at Make I get this after a few lines:
ranlib /home/sem/Downloads/wxwidgets3.0-3.0.2.orig/lib/libwxregexu-3.0.a
make: *** No rule to make target 'src/jpeg/jcomapi.c', needed by 'wxjpeg_jcomapi.o'. Stop.
I don't know what is wxwidgets3.0-3.0.2.orig, but this is not how the distribution archives are called, so it looks like you've got the file from which Ubuntu packages are built which doesn't seem to include the sources for 3rd party libraries such as libjpeg, presumably because these libraries are supposed to be already installed.
So you need to either install all the dependencies (you would find them in the debian/control file of the Ubuntu package) or get the really original sources from https://github.com/wxWidgets/wxWidgets/releases/v3.0.3 (there is no reason to use 3.0.2 when 3.0.3 is out).
I have Windows 10 with the Ubuntu userspace based on Windows Linux Subsystem, with the gcc package installed. Using gcc -static, I built a statically linked binary, hello, that the usual utilities describe as follows:
$ ldd hello
not a dynamic executable
$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.24, BuildID[sha1]=xxx, not stripped
If I take this executable to a random Windows system that doesn't have the Linux-supporting subsystem installed, will it still run?
No. It requires WSL to map Linux Kernel calls to Windows. Second it needs bash to load it since it's an ELF executable not a Windows one.
I have compiled an Ada program on Ubuntu using GNAT.
Afterwards, I tried a few test runs with that program and it worked properly.
But when I uploaded this to my Apache (UNIX) webserver and tried to run the program, there was no output. Why is this so?
Could it be that programs which have been compiled on Ubuntu don't work on a UNIX server?
(Sorry for the stupid question!)
Linux version of the system I use for compiling (uname -a):
Linux ubuntu 3.0.0-12-generic #20-Ubuntu x86-64 GNU/Linux
Linux version of the system I want to run the program on later (uname -a):
Linux 2.6.37-he-xeon-64gb+1 i686 GNU/Linux
For compiling on the Ubuntu machine, I use:
gnatmake -O3 myprogram -bargs -static
When you build a GNAT program (gnatmake my_program), by default it links against dynamic libraries (libgnat.so, libgnarl.so). These libraries are part of the GNAT system and are very unlikely to be available on your web server.
If you say ldd my_program it will show you the shared libraries used.
You can force the build to use the static GNAT libraries by saying
gnatmake my_program -bargs -static
(the -bargs -static must come after regular flags like -O2).
Edit: more info on -bargs and friends.
You must make sure that the server has the libraries your app links against or link them statically like already suggested by others. Some other comments point out that you need to "cross compile" or that the server won't run 64 bit binaries. This is easily solved unless the app you're building is very complex.
gnatmake --GCC='gcc -m32'
Will make a binary that will run on a 32bit system. However the chief problem is that the servers (g)libc is very likely to be older than what's on your ubunu box. Programs compiled against newer glibc will not necessarily run on systems with an older glibc installed.
for more info and plenty more links, look here:
Linking against an old version of libc to provide greater application coverage
How can I link to a specific glibc version?
edit:
Besides, apache may not be configured to accept invocation of external binaries. Have you "tried to run the program" with something you know exists on the server? Try to run something trivial like /bin/ls to make sure your method of running the program works. Look at the logs if it doesn't work. Programs need to be executable, by the way: chmod 755 /path/to/webeserver/uploads/ada-app
Why don't you just compile it on your Webserver instead of your local machine ?
Aswell cat /etc/issue or cat /etc/release could give us some information about the distribution you're using.