My operating system is CoreELEC
$ uname -a
$ Linux CoreELEC 4.9.113 #1 SMP PREEMPT Thu May 21 01:00:42 CEST 2020 aarch64 GNU/Linux
My cpu arch is aarch64
$ arch
$ aarch64
qrencode is ok
$ qrencode -V
$ qrencode version 4.0.2
But, I can't use it to generate PNG images, like this:
$ qrencode -o /storage/pictures/a.png "LDL6867PM1S3KV9G111A"
$ PNG output is disabled at compile time. No output generated.
If anyone knows what the problem is, please let me know, thank you very much!!!
When you are building from source and you run the ./configure step, what it does is checks to see the capabilities of the system before running the make step.
If you looked at what it output when you ran ./configure as you were building qrencode you would have seen something like this:
checking for png... no
!!!!!!!!!!
LIBPNG is required to build the utility tools. Temporarily disabled.
!!!!!!!!!!
so it's telling you that you are missing libpng and therefore it's going to disable png output. So while you have built qrencode, your binary has png output disabled which isn't particularly helpful.
When you attempted to run your new qrencode binary and got this error message:
PNG output is disabled at compile time. No output generated.
It was just informing you that your binary was compiled with png output disabled because as far as ./configure could tell, libpng wasn't available on your system.
To solve this, install libpng then go back and re-build your qrencode binary - checking to make sure the ./configure step correctly finds libpng.
Related
I was trying to compile my own kernel through clang-13 and run systemtap on that. I have enabled the CONFIG_DEBUG_INFO, CONFIG_DEBUG_KERNEL and all other default debugging configs including CONFIG_KPROBES, CONFIG_UPROBES. Additionally I have disabled CONFIG_RANDOMIZE_BASE. To compile and install I ran make -j8 bindeb-pkg && sudo dpkg -i ../*.deb. As you can see from the screenshot below the dbg package was installed and the sha256 confirms that the vmlinux matches, so systemtap should have access to its symbols. However, that doesn't seem to be the case since systemtap fails.
Additionally I compile the latest systemtap with clang-13 as follows make -j8 CC=clang-13 CXX=clang++-13 CFLAGS="-Wno-error" CXXFLAGS="-Wno-error".
The systemtap version is 4.7/0.170 and it says tested kernel versions: 2.6.32 ... 5.15.0-rc7. I might be missing something here.
Tracepoints in stap are identified by chewing through kernel headers (and sometimes sources). You can check whether stap is finding them with greater verbosity, such as:
stap -k -p2 --poison-cache --vp 04 -e 'probe ....'
If it's working, you'll see a lot of compiler invocations related to "tracequery", and you can see the residue of the searches under $TMPDIR (due to the -k option).
I have an open source micromouse robot project. For easier compilation, I use containers (both Podman and Docker should be fine):
make image
make libopencm3
make
This works just fine and generates a main.elf file about 874 kB in size. But that is as long as I fix the arm-none-eabi-gcc-cs to 7.4.0 in the Dockerfile.
If I remove the specific version or set it to 9.2.0, then I get the following error:
$ make
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: main.elf section `.text' will not fit in region `rom'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: region `rom' overflowed by 5288 bytes
collect2: error: ld returned 1 exit status
make: *** [opencm3/libopencm3.rules.mk:204: main.elf] Error 1
What could have changed between those versions?
If I add this line to my Makefile:
LDFLAGS += -specs=nano.specs
Then it compiles just fine with version 9.2.0 and generates a main.elf file about 885 kB in size. But I wonder if the performance would be the same (or equivalent) as before.
Update
I am expecting some performance differences, of course, just like I was expecting some differences in the binary size. But I was wondering if I could expect a higher than 20% difference in performance (specially if it could be now 20% slower).
The new binary is less than 2% bigger, and I would consider this to be "the same" as before. :-D
I do perfectly understand you want to use the latest and greatest toolchain from your prefered, mainstream Linux distribution, but this is not always going well.
In my humble opinion, you should:
stick to Linaro or ARM gcc toolchains,
in the case of your specific cortex-m related project, stick to a gcc toolchain more specifically targeting the cortex-m, i.e. the so called 'GNU Arm Embedded Toolchain'.
Some remarks:
There are probably excellent reasons why ARM itself is providing two specifics toolchains for the two profiles,
Latest GCC toolchain version available from Linaro is 7.4.1, but if they used to point to it by default on this page, they now pointing to version 7.2.1, which may (or not) ring a bell regarding 7.4.1 - there are no official 9.2 versions available yet.
Latest GCC toolchain available from ARM is 8.3.1 for cortex-m, and 8.3 for cortex-a - there are no official 9.2 versions available yet.
Back to your specific issue now: I was able to compile your project using the following steps:
wget "https://developer.arm.com/-/media/Files/downloads/gnu-rm/8-2019q3/RC1.1/gcc-arm-none-eabi-8-2019-q3-update-linux.tar.bz2?revision=c34d758a-be0c-476e-a2de-af8c6e16a8a2?product=GNU%20Arm%20Embedded%20Toolchain,64-bit,,Linux,8-2019-q3-update" -O gcc-arm-none-eabi-8-2019-q3-update-linux.tar.bz2
mkdir -p /opt/arm
tar jxf gcc-arm-none-eabi-8-2019-q3-update-linux.tar.bz2 -C /opt/arm
export PATH=/opt/arm/gcc-arm-none-eabi-8-2019-q3-update/bin:$PATH
Command which arm-none-eabi-gcc should display /opt/arm/gcc-arm-none-eabi-8-2019-q3-update/bin/arm-none-eabi-gcc.
git clone --recurse-submodules https://github.com/Bulebots/bulebule.git
cd bulebule
scripts/setup_libopencm3.sh
make -s -C src/
Command arm-none-eabi-size ./src/main.elf should display:
text data bss dec hex filename
55152 3336 7100 65588 10034 ./src/main.elf
Please note that there is a Docker file for the latest GCC toolchain from ARM targeting the cortex-m profile here. You may want to use it in your own Docker file and remove those two lines:
arm-none-eabi-gcc-cs-7.4.0 \
arm-none-eabi-newlib-3.1.0-2.fc30 \
I hope this helps.
I am having difficulty trying to get graphicsmagick to work. New to the coding world =]
I think I might have botched up my installation by not using brew to install.
I have an image on my /Desktop; 'sign.jpeg'
Here's what I get when I try to identify (or resize) the image:
Admins-iMac:Desktop admin$ gm identify sign.jpeg
gm identify: No decode delegate for this image format (sign.jpeg).
gm identify: Request did not return an image.
So I guess I will try unlinking and relinking:
Admins-iMac:Desktop admin$ brew unlink jpeg
Unlinking /usr/local/Cellar/jpeg/9b... 17 symlinks removed
Admins-iMac:Desktop admin$ brew link jpeg
Linking /usr/local/Cellar/jpeg/9b... 17 symlinks created
Hmm:
Admins-iMac:Desktop admin$ brew info jpeg
jpeg: stable 9b (bottled)
Image manipulation library
http://www.ijg.org
/usr/local/Cellar/jpeg/9b (20 files, 724KB) *
Poured from bottle on 2018-01-11 at 10:48:47
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/jpeg.rb
Alright so I guess I will try un/reinstalling graphicsmagick:
Admins-iMac:Desktop admin$ brew uninstall imagemagick graphicsmagick libpng jpeg
Error: No such keg: /usr/local/Cellar/imagemagick
Let me check the version info:
Admins-iMac:Desktop admin$ gm -version
GraphicsMagick 1.3.27 Q8 http://www.GraphicsMagick.org/
Copyright (C) 2002-2017 GraphicsMagick Group.
Additional copyrights and licenses apply to this software.
See http://www.GraphicsMagick.org/www/Copyright.html for details.
Feature Support:
Native Thread Safe yes
Large Files (> 32 bit) yes
Large Memory (> 32 bit) yes
BZIP yes
DPS no
FlashPix no
FreeType no
Ghostscript (Library) no
JBIG no
JPEG-2000 no
JPEG no
Little CMS no
Loadable Modules no
OpenMP no
PNG no
TIFF no
TRIO no
UMEM no
WebP no
WMF no
X11 no
XML yes
ZLIB yes
Host type: x86_64-apple-darwin16.7.0
Configured using the command:
./configure 'CC=clang' 'LDFLAGS=-L/usr/local/libjpeg/lib -L/usr/local/libpng/lib -L/usr/local/libtiff/lib' 'CPPFLAGS=-I/usr/local/libjpeg/include -I/usr/local/libpng/include -I/usr/local/libtiff/include' '--prefix=/usr/local/mac-dev-env/graphicsmagick-1.3.27'
Final Build Parameters:
CC = clang
CFLAGS = -g -O2 -Wall -D_THREAD_SAFE
CPPFLAGS = -I/usr/local/libjpeg/include -I/usr/local/libpng/include -I/usr/local/libtiff/include -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/libxml2
CXX = g++
CXXFLAGS = -D_THREAD_SAFE
LDFLAGS = -L/usr/local/libjpeg/lib -L/usr/local/libpng/lib -L/usr/local/libtiff/lib -L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib
LIBS = -lbz2 -lxml2 -lz -lm -lpthread
I am just not good with this terminal stuff quite yet, so I am mostly unsure how to interpret all these lines. I should have just used brew to install it in the first place D:
Any help would be appreciated!
Personally, I would recommend ImageMagick over GraphicsMagick, with reasons as in the comments above.
To sort out your current situation, I would do the following:
ensure my PATH is correct for homebrew
uninstall all the mentioned packages
install the necessary packages
check my setup
So, I'll cover each aspect of that with a separate section, and put a horizontal rule in between.
Edit your login profile, probably $HOME/.profile and make sure that /usr/local/bin is at the start because that is where homebrew installs stuff. So basically, you want a line near the end like:
export PATH=/usr/local/bin:$PATH
Exit Terminal, and then start a new Terminal and check your PATH starts correctly with /usr/local/bin by running:
echo $PATH
Now remove all the packages you have been playing with:
brew rm imagemagick jpeg libpng graphicsmagick
Now reinstall just the ones you want:
brew install jpeg libpng imagemagick
Now test that homebrew is happy, by running:
brew doctor
and following the good doctor's advice.
Then you should be able to run:
identify -version
convert -size 1024x768 gradient:red-blue first.jpg
You can see the created image by opening the Finder at the current directory:
open .
Then select the file with the mouse by tapping on it once, and press the SPACE bar to quick-look it.
I've been having issues with Homebrew's 1.3.27 version of GraphicsMagick - it doesn't seem to configure the delegates properly.
Downgrading to 1.3.26_2 has solved our issues.
I installed the golang.
~/go/bin$ ls
go godoc gofmt
Trying to test, but to no avail.
~/go/bin$ go version
-bash: /home/orc/go/bin/go: no such file or directory
My $PATH:
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/orc/go/bin:
Info:
~/go/bin$ uname -m
x86_64
~/go/bin$ file go
go: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
~/go/bin$ pwd
/home/orc/go/bin
Please tell me what's wrong?
UPDATE
~/go/bin$ ls -l
итого 28688
-rwxr-xr-x 1 orc orc 9571864 Фев 18 14:40 go
-rwxr-xr-x 1 orc orc 16164032 Фев 18 14:41 godoc
-rwxr-xr-x 1 orc orc 3594712 Фев 18 14:40 gofmt
~/go/bin$ ./go
-bash: ./go: Нет такого файла или каталога
!!!
~/go/bin$ file $(which ls)
/bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
~/go/bin$ uname -a
Linux olimp-web 2.6.32-5-amd64 #1 SMP Mon Jun 13 05:49:32 UTC 2011 x86_64 GNU/Linux
Please explain how to fix it?
Have you checked that you have the correct version for your architecture installed. I have just had this exact problem when I put a 32-bit binary on a 64-bit virtual machine. I removed the 32-bit version and installed the architecture appropriate version (based on the instructions on the website) and it worked. Hope that works for you too.
A couple of things to check, which may come to nothing, but they'll at least rule out things:
There's no indication in your question that your current directory is within /home/orc, a simple pwd should clarify that.
Can you run the file directly, such as with ./go or ~/go/bin/go?
Is it executable? The output of ls -l should clarify that.
Get the full machine details with uname -a.
Check the system executables in case it's somehow not 64-bit, despite the indication: file $(which ls).
Make sure there's no funny characters in the path that would prevent it being picked up there: echo $PATH | od -xcb.
Make sure your GOPATH is set up correctly (not sure this would affect go version but it's something extra to try).
In my case go compiler and language were not installed...
sudo apt install golang-go
For me this was the answer, this is on ubuntu18.04 windows subsystem linux 2 install:
export GOPATH=$HOME/go
export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin
I was facing the same issue in Docker, I'm writing an answer for anybody that may be using docker, In my case I had to install glibc, for context I'm using alpine3.17
And here's the portion of my dockerfile -
COPY --from=golang:1.19.5-alpine3.17 /usr/local/go/ /usr/local/go/
ENV GOPATH=/go
ENV PATH="${PATH}:/usr/local/go/bin:$GOPATH/bin"
RUN apk update && apk add --no-cache wget gcompat && apk -U upgrade
RUN wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub
RUN wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.35-r0/glibc-2.35-r0.apk
RUN apk add --force-overwrite glibc-2.35-r0.apk
I have a problem concerning libstdc++.so.
I installed a new version of gcc and tried to compile C++ code. The compiling worked, but when I try to execute the binary (m5.opt is its name) I've got the following error:
build/ALPHA_SE/m5.opt: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by build/ALPHA_SE/m5.opt).
Do I need to replace libstdc++.so? And if so, where can I download the version I want? On the GCC-website they say libstdc++ is a part of gcc now.
Details
GCC:
I had gcc 4.1.2 before, but I downloaded gcc 4.2.4. From the untarred gcc-directory I executed ./configure; make; sudo make install`.
When I tried to use gcc or g++ to compile, it's default version was still 4.1.2. To overcome this I replaced some links:
mv /usr/bin/gcc /usr/bin/gcc_bak
ln -s /usr/local/bin/gcc gcc
mv /usr/bin/g++ /usr/bin/g++_bak
ln -s /usr/local/bin/g++ g++
GLIBC(++) -- libstdc++:
/usr/lib64/libstdc++.so.6 -> libstdc++.so.6.0.8
/usr/local/lib/libstdc++.so -> libstdc++.so.6.0.9
/lib/libc.so.6 -> libc-2.5.so -> libc-2.5.so
Linux-version:
uname -a gives:
Linux madmax 2.6.18-128.4.1.el5 #1 SMP Tue Aug 4 12:51:10 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
The problem is that you built your new GCC incorrectly: on Linux you should use
./configure --prefix=/usr
The default installation prefix is /usr/local, which is why make install put gcc and g++ binaries into /usr/local/bin, etc.
What's happening to you now is that you compile and link using the new (symlinked) GCC 4.2.4, but at runtime your program binds to the old /usr/lib64/libstdc++.so.6 (version 6.0.8, instead of required 6.0.9). You can confirm that by running ldd build/ALPHA_SE/m5.opt: you should see that it uses /usr/lib64/libstdc++.so.6.
There are several fixes you could do.
env LD_LIBRARY_PATH=/usr/local/lib64 ldd build/ALPHA_SE/m5.opt
should show you that setting LD_LIBRARY_PATH is sufficient to redirect the binary to correct library, and
LD_LIBRARY_PATH=/usr/local/lib64 build/ALPHA_SE/m5.opt
should just run. You could "bake" this path into m5.opt binary by relinking it with -Wl,-rpath=/usr/local/lib64.
A more permanent solution is to fix the libraries the same way you fixed the binaries:
cd /usr/lib64 && mv libstdc++.so.6 libstdc++.so.6_bak &&
ln -s /usr/local/lib64/libstdc++.so.6 .
An even better solution is to reconfigure the new GCC with --prefix=/usr, and then make all install.
I know this is a very old question, but ...
It's not usually a good idea to replace the system compiler (i.e. the one in /usr) because the entire system will have been built with it and depend on it.
It's usually better to install the new compiler to a separate location and then see the libstdc++ FAQ How do I insure that the dynamically linked library will be found? and Finding Dynamic or Shared Libraries in the manual for how to ensure the correct libstdc++.so is found at runtime.
The other answers here should be fine, but the 'quick and easy' solution if you do happen to have gcc installed to /usr/local/ is to just add the new libs to the LD_LIBRARY_PATH
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib64
You can also check the to see if you have the right versions of GLIBC installed using
strings /usr/lib/libstdc++.so.6 | grep GLIBC
strings /usr/local/lib64/libstdc++.so.18 | grep GLIBC
I got this last tip from another forum so credits due where credits due!