Comments (20)
Forgot to reference the issue in commit 9570f24, which moves LibcWrapGenerator from .travis.yml
to CMake.
Right now, everything compiled in C should be built with this header, but I still haven't tested it thoroughly.
from appimagekit.
Compilation is broken right now.
Since we now have external projects using the AppImage codebase like the Subsurface project, I would suggest doing larger changes like these in a feature branch, see whether travis-ci succeeds building, then doing a Pull Request to master and then merge it into the master when we know for sure that the project still builds on travis.
from appimagekit.
Roger that, adopting git flow then
Looks like travis version of CMake is different from mine...
from appimagekit.
Building also fails with cmake-3.2.2-Linux-x86_64.tar.gz
, claiming attr/xattr.h
is missing. Do we have a dependency on libattr1-dev
?
from appimagekit.
I moved these commits to the experimental
branch. The master
branch builds again.
Once the experimental
branch is ready for primetime, let's do a PR and discuss it.
from appimagekit.
According to the Changelog, CMake impemented XZ in version 2.8.12, so
- bfc2d2d will probably not work, Ubuntu 12.04 LTS Server Edition 64 bit ships CMake 2.8.7
- 82169be will probably do work, Ubuntu 14.04 LTS Server Edition 64 bit ships CMake 2.8.12
Right now the only two dependencies that use CMake are:
- http://www.freedesktop.org/software/desktop-file-utils/releases/desktop-file-utils-0.22.tar.xz
- http://ftp.gnome.org/pub/GNOME/sources/vte/0.43/vte-0.43.0.tar.xz
and both packages are only provided in XZ format; BZ2 nor GZ are available.
from appimagekit.
The XZ issue works on Trusty. I guess using Trusty on Travis is not desirable, because it may change the compatibility of the output, and overall it's a beta distro (for Travis). What do you suggest to update CMake? PPA? Official binary distribution?
Regarding libattr, the fix it's almost there
from appimagekit.
Compilation almost fixed, now it fails when linking runtime
because of libcwrap.h
https://travis-ci.org/probonopd/AppImageKit/builds/90264515#L1746
CMakeFiles/runtime.dir/runtime.c.o: In function `md5_buffer':
/home/travis/build/probonopd/AppImageKit/md5.c:178: undefined reference to `memcpy@GLIBC_DONT_USE_THIS_VERSION_2.14'
etc
from appimagekit.
We'll need to take a look at the discussion in https://blogs.gnome.org/tvb/2013/12/14/application-bundles-revisited/comment-page-1/#comment-3830
from appimagekit.
@RazZziel Please make sure to not try this in the master
branch as expressed in #35 (comment)
I have, again, reverted the changes to the master
branch using
git clone https://github.com/probonopd/AppImageKit.git
cd AppImageKit/
git reset --hard eff3e06c573b0455a11ec7499df431d5be33fd83
git push --force
and this time I have enabled the branch protection features of GitHub, which hopefully means that these changes do not land inadvertently in master
again.
We have important projects trying to adopt AppImageKit for use in their build system and we drive them away from AppImageKit if we break (or substantially change) master
. One of these projects does not like the fact that, in addition to breaking the build entirely, the changes pull in so many build time dependencies. Which I can really relate to.
Please make extra sure that with your next git push
the changes don't land in master
again. (If they do, use my procedure above to remove them.)
Once the feature branch is working as intended, then let's discuss what we merge into master
and when, and how we announce that.
Thanks!
from appimagekit.
The XZ issue works on Trusty. I guess using Trusty on Travis is not desirable, because it may change the compatibility of the output, and overall it's a beta distro (for Travis).
Correct, this is not desirable. Let's continue to target Ubuntu 12.04 LTS as the build system. Using a newer distribution as the build system means it becomes harder to maintain compatibility of the build products with older distributions. Plus, other projects that may want to produce AppImages may not want to use something newer than Ubuntu 12.04 LTS.
What do you suggest to update CMake? Official binary distribution?
I have had positive results with the official binary distribution which I am using in https://github.com/probonopd/AppImages/blob/master/recipes/subsurface.sh
from appimagekit.
The use of LibcWrapGenerator should be optional, so that one can choose at build time whether to use it (or not).
from appimagekit.
Finally experimental
is building again in Travis. What a dependency rollercoaster ride.
from appimagekit.
The use of LibcWrapGenerator should be optional, so that one can choose at build time whether to use it (or not).
@probonopd defaulting to use LibcWrapGenerator, or defaulting not to?
By the way right now GNU xorriso is used by default, but libburnia can be selected using cmake . -DUSE_GNU_XORRISO=OFF
from appimagekit.
Cool @RazZziel I can imagine it wasn't easy. I'd say we should have it use LibcWrapGenerator by default, but also have an option to disable it.
Additionally, an option that really minimizes the build time dependencies if all you want is produce an AppImage for an upstream app project as part of a script that generates the AppImage. (Then you don't probably need more binaries than runtime and AppRun - everything else can be used from the host system). (I think we had another ticket on this, which might really be worth to reconsider now given the load of additional dependencies)
from appimagekit.
Actually, I thought third parties were supposed to use the binary distribution of AppImageAssistant
we release every now and then, like they use tar
or dpkg-deb
.
Anyway, running cmake . && make AppImageAssistant
should produce an AppImageAssistant
without building all the additional dependencies that stuff like AppImageMonitor
has. Actually in theory they could just cmake . && make runtime xorriso
, and use AppImageAssistant.AppDir/package
script.
from appimagekit.
@RazZziel
Is it possible to build the Experimental branch without LibcWrapGenerator?
from appimagekit.
Done:
cmake . -DUSE_LIBC_WRAP_GENERATOR=ON
(default)cmake . -DUSE_LIBC_WRAP_GENERATOR=OFF
If you for instance want to change the default, you must edit it on LibcWrapGenerator/CMakeLists.txt
:
option(USE_LIBC_WRAP_GENERATOR "Use LibcWrapGenerator" ON)
option(USE_LIBC_WRAP_GENERATOR "Use LibcWrapGenerator" OFF)
from appimagekit.
I can compile experimental now (tested on Ubuntu 15.10) with cmake . -DUSE_LIBC_WRAP_GENERATOR=OFF
but it fails with undefined reference to memcpy@GLIBC_DONT_USE_THIS_VERSION_2.14
when I just run cmake .
- see #44
from appimagekit.
Might try this on appimaged
, appimagetool
and friends now.
from appimagekit.
Related Issues (20)
- Packing .net core 6.0 into appimage HOT 1
- Make the fuse daemon process a parent of the payload process rather than a sibling HOT 3
- Appstream generator 404s HOT 1
- Just a note - could not run AppImage on Alma 8.8 - but here's how HOT 8
- Ability to set restriction to internet and file access by user HOT 1
- xdg-open on Ubuntu 22.04 refuses to open links HOT 3
- setup HOT 1
- Adding Github Sponsorship option HOT 1
- [docs] Add fedora fuse-libs to the wiki HOT 5
- Cannot mount AppImage, please check your FUSE setup on Debian 11 HOT 2
- Any timeline for an updated version? HOT 5
- appimagetool-i686.AppImage: cannot execute: required file not found HOT 1
- Unable to extract LBRY_0.53.9.AppImage HOT 4
- AppImage run troubles
- Run built AppImage on Yocto HOT 2
- Some Appimages stopped showing icons. HOT 7
- Monochrome logo HOT 1
- Does some way exist for an AppImage to create temporary a temporary x-scheme-handler? HOT 4
- Static appimage with new runtime gives a strange error on a Pop OS! 22.04 computer HOT 1
- AppImage hangs on startup when using fuse HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from appimagekit.