packaging / distribution / installation

[jerabaul29]

I am having some difficulty installing on my system, as discussed in #64 . This is probably due to my n00bness on the topic of locally compiling / installing things.

This makes me think about a couple of questions:

• Is this well the repo used for building the package as distributed by Debian / Ubuntu et. co. for example? Looking there and there:

https://packages.debian.org/jessie/zbar-tools

https://manpages.ubuntu.com/manpages/bionic/man1/zbarimg.1.html

it does not seem so (the old SourceForge project is still what is linked I think).

• May it be possible to provide some regular builds / deb packages?

@matheusmoreira that may be of interest to you too, as you know I am especially interested in the features of your binary branch :)

[matheusmoreira]

Is this well the repo used for building the package as distributed by Debian / Ubuntu et. co. for example?

I don't know about Debian and Ubuntu but the Arch Linux package builds zbar by following the same instructions:

build() {
  cd zbar-$pkgver
  autoreconf -vfi
  PYTHON="/usr/bin/python2" \
  ./configure --prefix=/usr --with-qt --with-gtk=gtk3 CFLAGS="$CFLAGS -DNDEBUG"
  sed -i -e 's/ -shared / -Wl,-O1,--as-needed\0/g' libtool
  make
}

For some reason, the build system itself seems to be running into problems on your system. I don't understand autotools well enough to debug this issue. Perhaps there will be people who faced similar issues in a Ubuntu or Debian channel.

Problem is, I do not see any .so after having run the make command

I remember seeing a hidden .libs directory in zbarimg's directory. Try ls -la and if anything turns up try setting LD_LIBRARY_PATH to that directory before running zbarimg so that the dynamic linker will look there first. But honestly, the build system should be handling this in some way.

[mchehab]

Is this well the repo used for building the package as distributed by Debian / Ubuntu et. co. for example? Looking there and there:

https://packages.debian.org/jessie/zbar-tools

https://manpages.ubuntu.com/manpages/bionic/man1/zbarimg.1.html

Yes, since Buster:

https://packages.debian.org/buster/zbar-tools

May it be possible to provide some regular builds / deb packages?

No, we don't have enough time/resources for it, but you should probably be able to get it from Debian backports (or, if not, request Debian package maintainers to add it there).

[jerabaul29]

You are right @matheusmoreira , thank you for the help :)

So I get:

✔ jrlab-ThinkPad-T490:~/Desktop/Git/zbar/zbarimg [binary-decoding|✔]> ls -a
.  ..  .deps  .dirstamp  .libs  Makefile.am.inc  zbarimg  zbarimg.c  zbarimg.rc  zbarimg_zbarimg-zbarimg.o
✔ jrlab-ThinkPad-T490:~/Desktop/Git/zbar/zbarimg [binary-decoding|✔]> ls -a .deps/
.  ..  .dirstamp  zbarimg_zbarimg-zbarimg.Po
✔ jrlab-ThinkPad-T490:~/Desktop/Git/zbar/zbarimg [binary-decoding|✔]> ls -a .libs/
.  ..  zbarimg

and the zbarimg in this folder is a bash script, while the one in .libs is a binary :)

[jerabaul29]

@mchehab many thanks for the explanation. Sorry for getting a bit lost between Debian versions. Wondering if it may be useful to make it very clear from the repo description / Readme that it is this repo that is used for building the package on recent versions of Debian.

[hosiet]

Debian Developer here. If you would like to take a look at the maintenance status of zbar in Debian, please do NOT look at packages.debian.org. please see:

https://tracker.debian.org/pkg/zbar

Debian Stable (Debian 10) has zbar v0.22. Debian Testing/Unstable and prospective Ubuntu 20.04 LTS will have zbar v0.23. you are not encouraged to use older Debian/Ubuntu.

Let me know if you have any question.

[jerabaul29]

@matheusmoreira does not seem to work either using the binary in the .libs. Giving up on building locally.

[matheusmoreira]

@jerabaul29 Debian packaging was discussed on issues #15 and #46, you should read those threads. There could be some relevant information there.

the zbarimg in this folder is a bash script, while the one in .libs is a binary

Huh... Now I remember accidentally discovering this fact at some point when I also experienced similar linking problems on my end. I'd completely forgotten about it... I don't recall exactly what I did to solve the problem but I remember reading the script and editing it.

[jerabaul29]

Ok, thanks @matheusmoreira . 'Good' to know that I am not totally doing something stupid. I am by no ways expert / experienced about those building processes, so I will personally give up for now. Maybe if you remember what the problem was / what you had to do that it would be great to push the fixes to this repo? :)

[jerabaul29]

So @mchehab @hosiet if I understand well it will be too late to have the branch from @matheusmoreira in the Ubuntu 20.04 LTS, right? Would be great to still have an easy way to get the latest version installed from source for n00bs like me :)

[hosiet]

If there comes a v0.24 tag right now I may try to contact Ubuntu for a exception to be included in 20.04 LTS; otherwise it is indeed quite late since 20.04 LTS will be released next month.

[matheusmoreira]

does not seem to work either using the binary in the .libs. Giving up on building locally.

When I remembered .libs, I assumed the .so files would get copied there. Instead the zbarimg binary was placed there which is pretty weird. It's likely that there are other hidden directories in the tree containing the .so files. That's probably why zbarimg is a script, it needs to somehow hook all of this stuff up in a way that's invisible to the developer testing the software. Now I remember it had something to do with libtool. I found this documentation:

https://autotools.io/libtool/wrappers.html

I am by no ways expert / experienced about those building processes, so I will personally give up for now. Maybe if you remember what the problem was / what you had to do that it would be great to push the fixes to this repo? :)

Don't worry, I'm not an expert on this matter either. I have to figure it out every time and it's pretty painful when it happens. My mind seems to have blocked out the memory. I'm trying to remember.

---

Ah yes, I discovered this libtool business when I tried to use gdb to debug zbarimg.

[jerabaul29]

Ok, thanks for the explanations, that's very kind of you @matheusmoreira to try to help on this. Sounds like you definitely are more experienced than me on the topic ^^ .

[matheusmoreira]

What if you ran ./configure LDFLAGS=-no-install? This should make the linker hardcode the path to the correct library in the binary itself, completely bypassing the need for the shell scripts. Documentation:

-no-install
Link an executable output-file that can’t be installed and therefore doesn’t need a wrapper script on systems that allow hardcoding of library paths. Useful if the program is only used in the build tree, e.g., for testing or generating other files.

[jerabaul29]

Looks like some other problems appear ^^

✔ jrlab-ThinkPad-T490:~/Desktop/Git/zbar [binary-decoding|✔]> autoreconf -vfi && ./configure LDFLAGS=-no-install --with-dbus && make
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I config
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'config'.
libtoolize: copying file 'config/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'config'.
libtoolize: copying file 'config/libtool.m4'
libtoolize: copying file 'config/ltoptions.m4'
libtoolize: copying file 'config/ltsugar.m4'
libtoolize: copying file 'config/ltversion.m4'
libtoolize: copying file 'config/lt~obsolete.m4'
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:13: installing 'config/compile'
configure.ac:8: installing 'config/missing'
Makefile.am: installing 'config/depcomp'
autoreconf: Leaving directory `.'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to print strings... printf
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/home/jrlab/Desktop/Git/zbar':
configure: error: C compiler cannot create executables
See `config.log' for more details

[jerabaul29]

This is only a suggestion and may be a bad idea - I do not know how this uses to be decided, if this is rude / not a good thing to suggest I apologize in advance - but it looks like you are very active on this repo @matheusmoreira , do you think you know enough about this code so that you may become a 'collaborator' and therefore become able to merge pull requests etc? May be good also to have a few people with control over the repository so that things can still happen even when people go to holidays / get sick etc.