config.ac is not cross-compile friendly about partclone HOT 11 OPEN

thank you.
I will update to pkg-config to test version as possible.

from partclone.

there are only ext2fs and ntfs3g could be check by pkgconfig and ntfs-3g do not check version, so i just update ext2fs.
The newer version of partclone is 0.2.74 or just clone from github and please give a try.

Thank you

from partclone.

This helps but I don't think the cross-compiling issue is fixed entirely. For example, in the btrfs section:

btrfs_version=`gcc $srcdir/src/deplib_version.c $srcdir/src/btrfs/version.h -o $srcdir/get_lib_version -DBTRFS`
btrfs_version=`$srcdir/get_lib_version btrfs`

Running get_lib_version would work fine if your host machine is x86 and your target platform is x86 but won't work if your target is an arm processor.

from partclone.

I can't find entry of btrfs from pkg-config, but I included part of source from btrfs, therefore I can just grep it.
like

diff --git a/configure.ac b/configure.ac
index 7d1bf34..e84a103 100644
--- a/configure.ac
+++ b/configure.ac
@@ -419,8 +419,7 @@ if test "$enable_btrfs" = yes; then
 AC_CHECK_HEADERS([blkid/blkid.h],,
 AC_MSG_ERROR([*** btrfs depend library (libblkid-dev) header not found]))
 supported_fs=$supported_fs" btrfs"
-btrfs_version=`gcc  $srcdir/src/deplib_version.c $srcdir/src/btrfs/version.h  -o $srcdir/get_lib_version -DBTRFS`
-btrfs_version=`$srcdir/get_lib_version btrfs`
+btrfs_version=`grep BTRFS_BUILD_VERSION src/btrfs/version.h | sed s/\#define\ //g`
 fi
 #end of check btrfs

after update configure.ac and run autoreconf.

if this work for cross-compile, I consider to remove get_lib_version from configure.ac.

from partclone.

I applied the patch and recompiled:

Support File System:
ext2/3/4...... yes, 1.42.12
reiserfs...... no, 
reiser4....... no, 
xfs........... no, version unknown, suggest 3.1.1
ntfs.......... yes, ntfs-3g
fat12/16/32... yes, build-in
exfat......... no, 
hfs plus...... yes, build-in
ufs .......... no, 
vmfs ......... no, 
jfs .......... no, 
btrfs......... yes, BTRFS_BUILD_VERSION "Btrfs v3.14.1"
minix......... no, 
f2fs.......... no, 

Yes, please consider removing get_lib_version.

from partclone.

Thomas, I would highly encourage you or Steven to fix your configure scripts for autotools so that this can be cross compiled. There are huge benefits in using a tool like partclone on very small systems (i.e. ARM based like a Raspberry Pi or Beaglebone) for recovery. There are also benefits in getting this included with tools like Yocto and/or Buildroot, as was mentioned above.

As it stands, since virtually every path is hardcoded in configure.ac, this is not doable. I'm going to provide an example of what I did to make at least the NTFS option cross-compile friendly, but the rest of the filesystems should follow this same route (as well as options like enabling ncursesw, which also does not work when you cross compile since the path is again hardcoded to only work on the host):

In configure.ac:

+PKG_PROG_PKG_CONFIG
...
-uuidcfg=pkg-config --cflags --libs uuid
+uuidcfg=$PKG_CONFIG --cflags --libs uuid
...
+PKG_CHECK_MODULES([NTFS3G], [libntfs-3g >= 2015.3.14], [ntfs_version=$PKG_CONFIG --modversion libntfs-3g])
#end of check ntfs

In Makefile.am:

-partclone_ntfs_CFLAGS=-DNTFS3G
-partclone_ntfs_LDADD=-lntfs-3g
+partclone_ntfs_LDADD = @NTFS3G_LIBS@
+partclone_ntfs_CFLAGS = @NTFS3G_CFLAGS@ -DNTFS3G

This is the bare minimum of what needs to be done to get a filesystem option to cross compile. I really hope get_lib_version can be completely removed and you can fix up these files completely so that this nice recovery tool can be compiled for any system.

If you need a cross compiling toolchain to test with, I would recommend generating one with crosstool-ng or Buildroot which make it effortless to do so.

from partclone.

Thank you for your contribution and comments. I will follow your suggestion and apply your patch for file configure.ac soon.

I am not the expert of cross compile and I have question why debian can build partclone for arm and other architecture. what's the different between debian build fram and Buildroot?

from partclone.

I am very far from being an expert in cross compilation myself but I can assure you the ac and am files are not written correctly to allow it (it's what the devs in the Buildroot mailing list also specified, in @MSumulong's provided links above; this is advice I would really follow because they are experts in this). I'm not really sure how Debian does it but since they simply release prepacked deb's, they may not even be cross compiling. Or they have their own wrapper to cross compile. The point remains that it should be fixed at the root of the problem which is partclone's own ac/am files.

Cross compiling is nothing magical ... it basically means using a host computer to target another architecture through a provided toolchain. If you want an easy way to test out your changes, you can grab a prebuilt ARM toolchain here (https://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz), export some env variables to point CC, LD, etc. to the proper ARM variants (see here for a simple tutorial: http://wiki.openwrt.org/doc/devel/crosscompile), and configure/make away. If it works there, you can be pretty certain it will work for other platforms. This is true cross compilation and this is what Buildroot, Yocto, Ptxdist, etc. will all do for you as they let you build an embedded Linux distribution on a host PC (say running Ubuntu) targeting a different architecture.

If we can get partclone cross compiling properly, we can push it into big open source projects and it can be used as the prominent recovery tool on many embedded systems. Autotools is something I am not very familiar with so I apologize I cannot be of more help than this.

from partclone.

Sorry to revive a (somewhat) dead thread here;

I too am looking to port Partclone in to my project, using Buildroot.
Unfortunately, I am also not having any success.

I'm currently using Buildroot 2015.11, and pulling the Partclone 0.2.86 release from here on GitHub.

It seems that the issue is related to what @nimaim said; the paths are all statically assigned.

from partclone.

I plan to spend some time over the next few days to see if I could make this work.

@Thomas-Tsai: are you open to the possiblity of Pull Requests?

from partclone.

Of course ! all patches and pull are welcome!
thank you

from partclone.