I'm trying to compile the libxkbcommon library for kodi for my Raspberry Pi 2.
The host machine is a dedicated Server running Ubuntu 16.04 x64.
Now there are two errors when I'm trying to compile libxkbcommon, depending on what yacc I'm using:
byacc:
YACC src/xkbcomp/parser.c
yacc: e - line 219 of
"/opt/kodi/xbmc/tools/depends/target/libxkbcommon/raspberry-pi2-release/src/xkbcomp/parser.y", syntax error
%destructor { FreeStmt((ParseCommon *) $$); }
^
Makefile:1637: recipe for target 'src/xkbcomp/parser.c' failed
btyacc:
parser.y:85: syntax error
Here is the source code of libxkbcommon:
https://github.com/xkbcommon/libxkbcommon
The xbcomp/parser.y file requires a number of (very useful) bison extensions, so it can't be processed by all yacc variants.
btyacc does not support bison-compatible pure-parser declarations. (It has a different, not entirely compatible mechanism which implements the same feature.) So it fails on the first instance of one of those declarations.
It should be possible to use byacc, but not the version which is available in the Ubuntu package repository. Although the Ubuntu package repository change history seems to suggest that the intention was to include the build option which allows %destructor, the actual binary currently available in the byacc repository was built without that option. (It is also several years old, and I think it would be useful to use a more recent version.) I reported this as launchpad bug 1776270, along with a suggestion for a possible fix.
I'm sure you'll be able to build the software using Gnu bison, which is available as the Ubuntu package bison. Since that's the most popular yacc version installed on developer machines, a failure to build with bison would probably have been noticed long ago.
If you would prefer to use byacc, for whatever reason, you'll have to download and build it yourself. You can get the most recent version from Thomas Dickey's byacc page, and then build it with the usual procedure: untar, configure, make, make install. When I tested this, I used the following configure line:
./configure --enable-btyacc --program-prefix=b --prefix=/usr
Only the first option is mandatory
* --program-prefix=b Install it as `byacc` rather than `yacc`
* --enable-btyacc Necessary for %destructor support
* --prefix=/usr Install it in /usr/bin and /usr/man. The default
is /usr/local/bin and /usr/local/man, which failed on
my Ubuntu install because of a missing -D option in the
install command in the Makefile.
Related
I am trying to use the latest version of the appImage-builder because appimages of my application built with the old version of appImage-builder do not run on ubuntu 22.04 anymore. So I got the order to try and see if it works with the new appImage-builder.
Currently (June 2022), only versions below 1.0 which are based on ubuntu 18.04 are available on docker (which we previously used to build our appimage).
The newer versions are available via github (https://github.com/AppImageCrafters/appimage-builder/releases).
However, I seem to be unable to execute:
appimage-builder --generate
or
appimage-builder --recipe AppImageBuilder.yml
Is there any documentation available on how to correctly use the .appimage version of appImage-builder? All I could find in https://appimage-builder.readthedocs.io/en/latest/ seems to refer to the docker version or a manually built version of appImage-builder.
Depending on the error message you get, there could be a couple of issues at play here.
If you got an error related to FUSE, then you need to install the libfuse2 package with apt install libfuse2. AppImages rely on libfuse2, but Ubuntu has stopped including it since 22.04, in favor of libfuse3.
If you get an error related to "file not found", then it could be that you do not have AppImageLauncher installed. Sadly, with type 2 AppImages the design decision was taken to modify the ELF header of the executable with 3 magic bytes at offset 8 of the executable. This means that Linux linkers will not run the file. AppImageLauncher actually copies the file to a temporary directory and zeroes out the magic number in order to be able to execute it.
A good starting point for debugging issues like this is to run the strace command, which will let you see which system call likely cause the error. Keep in mind that if you try to execute a file and you get File not found, it might mean that the linker specified by the file can not be found on the system or the ELF header is not valid. You can also run the executable by using the linker directly, which might give you more clues. For example with: /lib64/ld-linux-x86-64.so.2 <NAME-OF-YOUR-EXECUTABLE>.
I've been trying to install LuaJIT on Windows 10 for some time following the official guide, and I actually get to install it. For example, if I execute luajit I get into the prompt. Also, luajit -v returns the version of luajit (2.0.4). And I can also execute code with luajit -e <lua code>. However, whenever I try to save bytecode with luajit -b, I get the following message:
luajit: unknown luaJIT command or jit.* modules not installed
I tried to make all sort of installations: using Cygwin, luajit-rocks, MinGW, ... However, no matter what I try, I always get the same result, and I have no clue of what to do.
Could you point me to some potential problems I might be overlooking?
I have on my system Lua 5.1 and Luarocks.
Some extra LuaJIT features are implemented as separate Lua modules (e.g. jit.bcsave for bytecode saving), and LuaJIT depends on package.path to find those modules. The suggested install location for those modules is in the default package.path, but if you override it via the LUA_PATH environment variable, you have to make sure to include that location there. One easy way to do that is to put two consecutive semicolons into LUA_PATH: Double semicolons are replaced by the compile-time default value of package.path.
You need place modules to "jit" folder near with juajit.exe. That folder include some system modules (bcsave too). package.path can dont work, becouse it hardlinked, how i understand. That folders distributed with source code.
Download lua from official sice: https://luajit.org/download.html
You can see "jit" folder inside archive:
LuaJIT-2.0.5.zip\LuaJIT-2.0.5\src\jit\
If there a relatively simple way to make go + libxml2 + gokogiri work on windows?
I mean that I may be can install it (but at the moment I can not, stuck with Package libxml-2.0 was not found in the pkg-config search path), but then I need to provide my utilite to other people, who will never be able (or would wish ) to install lall libxml2 dependencies, modify PATH etc on windows...
It work flawless on Ubuntu...
I found this https://github.com/moovweb/gokogiri/issues/49 thats funny with installation of Gimp 2 (what?!), but I still cannot make it run with such error, I guess might be issue with PATH, but all PATH are set
$ go get github.com/moovweb/gokogiri
# github.com/moovweb/gokogiri/help
Documents\go\src\github.com\moovweb\gokogiri\help\help.go:6:25: fatal error: lib
xml/tree.h: No such file or directory
#include <libxml/tree.h>
^
compilation terminated.
# github.com/moovweb/gokogiri/xpath
Documents\go\src\github.com\moovweb\gokogiri\xpath\expression.go:4:26: fatal err
or: libxml/xpath.h: No such file or directory
#include <libxml/xpath.h>
^
compilation terminated.
You are struggling because it is hard to combine packages that were built by different people for different purposes and get your environment set up correctly. I think it is best to use MSYS2, an environment for Windows that provides a consistent set of packages for things like gcc, go, libxml2, and iconv. MSYS2 has a package manager (pacman) that helps you easily install them and keep them updated.
I don't do much programming with Go, but I am familiar with MSYS2 and it seems like I was able to get gokogiri installed using MSYS2. You should open MSYS2's "MinGW-w64 Win64 Shell" from the Start menu (mingw64_shell.bat), and try running these commands:
pacman -S mingw-w64-x86_64-{gcc,go,libxml2,iconv}
export GOROOT=/mingw64/
export GOPATH=/c/Users/David/Documents/goproj/
mkdir -p $GOPATH
go get github.com/moovweb/gokogiri
I think GOPATH should be set to the directory of your project. If you run into an error, it might be because some pacman package is required that I didn't list here.
The string mingw-w64-x86_64-{gcc,go,libxml2,iconv} gets expanded by Bash into the following list of packages:
mingw-w64-x86_64-gcc
mingw-w64-x86_64-go
mingw-w64-x86_64-libxml2
mingw-w64-x86_64-iconv
If you are actually using 32-bit Windows, replace x86_64 with i686 in the instructions above.
If you are curious, the scripts for building those packages are here: https://github.com/Alexpux/MINGW-packages
As a disclaimer, I haven't actually compiled any go programs in MSYS2, so there could be big problems I am unaware of.
Also, one of the main developers of MSYS2 (alexpux) said this in the #msys2 IRC chat on 2015-06-21:
We not build go for a long time.
This package in very WIP state
Also see
https://github.com/Alexpux/MINGW-packages/issues/421
So you might need to fix some issues with the MSYS2 Go package and recompile it yourself to really make this work. But you have the PKGBUILD script that was used to build it, so maybe that will be less hard than what you are trying to do right now, which involves compiling/collecting every dependency of gokogiri.
MSYS2 would make your other installation of go, libxml2, and iconv obsolete. You can delete those things once you get your MSYS2 environment working.
If you are using visual studio and want to add dependency to your project then just install it using NuGet Package Manager it's easiest method.
Install command: Install-Package libxml2
The problem:
I can't seem to install perl modules correctly, JSON-2.53 in particular.
I have done the following:
Searched for a similar problem and tried its solution - did not work.
perl ".../config.h, needed by `Makefile'" not working after OSX Lion upgrade
Installed XCode command line developer utilities (c compiler, make, etc)
Read version compatibility documentation on this particular perl module: http://metacpan.org/pod/JSON
Ran the following commands to make and install the desired perl module:
$perl Makefile.PL
Welcome to JSON (v.2.53)
If you install JSON::XS v.2.27, it makes JSON faster.
************************** CAUTION **************************
This is 'JSON version 2' and there are many differences *
to version 1.xx *
Please check your applications useing old version. *
See to 'INCOMPATIBLE CHANGES TO OLD VERSION' and 'TIPS' *
Writing Makefile for JSON
(verified that the Makefile has been written)
$make
make: *** No rule to make target `/System/Library/Perl/5.12/darwin-thread-multi-2level/CORE/config.h', needed by `Makefile'. Stop.
What does that error even mean? What can I do to successfully make install this module?
Here are some additional items that may help you assist me in debugging this issue:
$which make
/Applications/Xcode.app/Contents/Developer/usr/bin/make
$which perl
/usr/bin/perl
$perl -v
This is perl 5, version 12, subversion 3 (v5.12.3) built for darwin-thread-multi-2level
I think you need to download and reinstall XCode. If I recall correctly for 10.7, after downloading Xcode from the app store it drops an installer into your Applications folder. You need to run it and try installing the command line tools again (from Xcode's prefernces pane). I know you mentioned you did this already, but a bit more background might explain why it's worth another try.
Here are the relevant lines in the Makefile from my Mac:
PERL_INC = /System/Library/Perl/5.12/darwin-thread-multi-2level/CORE
# Where is the Config information that we are using/depend on
CONFIGDEP = $(PERL_ARCHLIB)$(DFSEP)Config.pm $(PERL_INC)$(DFSEP)config.h
Later on in the Makefile CONFIGDEP is used as a dependency in a target. I believe in your case make is looking for /System/Library/Perl/5.12/darwin-thread-multi-2level/CORE/config.h and can't find it. The error you're seeing is make's obtuse way of saying file not found.
config.h contains specific information about the OS but is not needed for running scripts. It's only referenced when you want to compile a module. With stock OSX you get enough perl to execute scripts. Install XCode and you get the bits (like config.h) to do perl "development". I use quotes because you can write and run perl scripts without Xcode. But as you discovered, compiling a module requires the additional files Xcode provides. (Incidentally, RedHat does the same thing. You have to install the perl-devel package to get config.h. The perl runtime is in a separate package.)
Here are some things you can try:
Verify /System/Library/Perl/5.12/darwin-thread-multi-2level/CORE/config.h exists. If not, Xcode command line utilities were not installed properly. Try it again.
If config.h exists, check its content and make sure it looks sane. It's a C header file and consists of comments and #define statements.
If you don't have access to view config.h, you have a permission issue. Try using sudo make as a bypass. Disk Utility (found in Applications -> Utilities) might be able to permanently fix this.
You could risk changing the Makefile by removing "$(PERL_INC)$(DFSEP)config.h" from CONFIGDEP. I did this on my 10.8 Mac and it worked without issue (it passed all tests as well). However, if you don't find the root cause of your config.h issue, the next time you want to install a perl module you may find yourself right back where you started.
I had this exact same error, whilst this may not be a solution for you.... after reinstalling an updated xcode compatible with the OSX version (+rebooting after the install) I still had the error - to cut a long story short I noticed there was no config.h in /CORE/ after the error.....the solution that worked was to touch config.h and create the file first and then re-run the make. Hope this helps someone.
It's late and I should go to bed and maybe that's why I can't figure this out. I'm on a fedora-13 machine and I just ran
yum install gambit-c
I installed it because I want to follow along in a schemed text book.
but now that it's installed, how do I start the scheme interpreter??
It looks from the RPM listing that the binaries are named gsi, gsix, and gsc, all in /usr/bin. I suspect that gsi is the interpreter.
For more details, there's also the manual entry for gsi.
BTW: I don't know about the Fedora RPM, but I found that the Ubuntu repository's Gambit-C was quite outdated (4.0-ish), with missing features like simple compilation of stand-alone executables. The most recent version is 4.6. If your RPM's version is a few decimal places behind, I'd suggest just installing from source; it's a pretty standard configure -> make -> make install sequence. Just remember the following option when running configure:
./configure --enable-single-host
This speeds things up quite a bit.