Help needed with cross-compiling libotr
Hello all
I have been trying to cross-compile libotr package that makes it possible, with the help of pidgin-otr plugin, to send encrypted messages with Pidgin IM software
(which I already have successfully cross-compiled for buildroot and plan to submit soon).
Now, the problem is that no matter what I do that damn package picks "-I/usr/include" somewhere
and the build will fail complaining about undefined reference to __isoc99_sscanf (which it picks wrongly from
host system stdio.h).
Several remakes, autoreconf and configure switche changes and still no closer to success.
Even grepped the source for -I/usr/include and the only place it shows it is from
something called oldinclude from configure file...
Im totally lost here.
Could somebody more knowledgeable about autoconf/make please take a look of this package ?
It's not big and the only dependencies it needs are libgcrypt and libgpg-error
It can be downloaded from here:
http://www.cypherpunks.ca/otr/pidgin-otr-4.0.0.tar.gz
And here are my unworking Config.in and libotr.mk so far
config BR2_PACKAGE_LIBOTR
bool "libotr"
select BR2_PACKAGE_LIBGRCRYPT
select BR2_PACKAGE_LIBGPG_ERROR
help
libotr
#############################################################
#
# libotr # #############################################################
LIBOTR_VERSION = 4.0.0LIBOTR_SITE = http://www.cypherpunks.ca/otrLIBOTR_AUTORECONF = YESLIBOTR_AUTORECONF_OPTS = --install --forceLIBOTR_DEPENDENCIES = libgcrypt libgpg-error
LIBOTR_CONF_ENV = LIBGCRYPT_CONFIG=$(STAGING_DIR)/usr/bin/libgcrypt-config LIBOTR_CONF_OPT += --disable-gcc-hardening --disable-linker-hardening
--with-pic \
--with-libgcrypt-prefix="$(STAGING_DIR)/usr" \
--disable-dependency-tracking \
--oldincludedir="$(STAGING_DIR)/usr/include"# disable rpath stuff
define LIBOTR_POST_CONFIGURE_FIXUP
(cd $(@D); \
sed -i
's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool ; \
sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g'
libtool )
endefLIBOTR_POST_CONFIGURE_HOOKS += LIBOTR_POST_CONFIGURE_FIXUP
$(eval $(autotools-package))
Thank you!
Regards
Stefan
28.2.2013 17:04, Stefan Fr?berg kirjoitti:
Quoted 23 lines
Hello all
I have been trying to cross-compile libotr package that makes it possible, with the help of pidgin-otr plugin, to send encrypted messages with Pidgin IM software
(which I already have successfully cross-compiled for buildroot and plan to submit soon).Now, the problem is that no matter what I do that damn package picks "-I/usr/include" somewhere
and the build will fail complaining about undefined reference to__isoc99_sscanf(which it picks wrongly from
host systemstdio.h).Several remakes, autoreconf and configure switche changes and still no closer to success.
Even grepped the source for -I/usr/include and the only place it shows it is from
something called oldinclude from configure file...Im totally lost here.
Quoted 7 lines
Could somebody more knowledgeable about autoconf/make please take a look of this package ?
It's not big and the only dependencies it needs are libgcrypt and libgpg-errorIt can be downloaded from here:
http://www.cypherpunks.ca/otr/pidgin-otr-4.0.0.tar.gz
Ach!
I meant from here:
http://www.cypherpunks.ca/otr/libotr-4.0.0.tar.gz
Hello all,
Quoted 5 lines · Stefan Fr?berg
I have been trying to cross-compile libotr package that makes it possible, with the help of pidgin-otr plugin, to send encrypted messages with Pidgin IM software
(which I already have successfully cross-compiled for buildroot and plan to submit soon).
I'd like to state my feeling on this: I believe that packaging desktop-level software like Pidgin or the Network-Manager Applet in Buildroot is useless. I don't think Buildroot is appropriate to build a full-blown desktop distro, and even though Stefan is doing good work with all those packages, I fear that once Stefan's work is over, those packages will bit rot.
Stefan, are you sure that Buildroot is appropriate for what you're trying to achieve? Have you looked at something like Gentoo? It builds from source like Buildroot, has a package management system, and gazillions of desktop-level software already packaged. Since you're targeting x86, you don't need cross-compilation, which would have been the reason for using Buildroot in the first place.
And don't tell me you use Buildroot because of uClibc: when you're doing a full-blown desktop environment, using glibc or uClibc doesn't make *any* difference, be it from a size perspective or a performance perspective.
What do others think about this?
Best regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Quoted 33 lines · Thomas Petazzoni
Hello all,
Quoted 5 lines · Stefan Fr?berg
I have been trying to cross-compile libotr package that makes it possible, with the help of pidgin-otr plugin, to send encrypted messages with Pidgin IM software
(which I already have successfully cross-compiled for buildroot and plan to submit soon).I'd like to state my feeling on this: I believe that packaging desktop-level software like Pidgin or the Network-Manager Applet in Buildroot is useless. I don't think Buildroot is appropriate to build a full-blown desktop distro, and even though Stefan is doing good work with all those packages, I fear that once Stefan's work is over, those packages will bit rot.
Stefan, are you sure that Buildroot is appropriate for what you're trying to achieve? Have you looked at something like Gentoo? It builds from source like Buildroot, has a package management system, and gazillions of desktop-level software already packaged. Since you're targeting x86, you don't need cross-compilation, which would have been the reason for using Buildroot in the first place.
And don't tell me you use Buildroot because of uClibc: when you're doing a full-blown desktop environment, using glibc or uClibc doesn't make *any* difference, be it from a size perspective or a performance perspective.
What do others think about this?
Best regards,
Quoted 10 lines
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
I tend to agree that these kind of packages might be too much for buildroot, but keep in mind that Gentoo comes with a rather big uClibc rootfs by default [1]
[1] http://distfiles.gentoo.org/experimental/x86/uclibc/
Signature · 2 lines
Regards, Markos Chandras
I am torn on that one... the frontier between embedded and not embedded never was very clear, and there are lots of single-purpose computers that have a screen and a keyboard to run a single graphical app.
I don't know the exact project here, but having a small screen displaying messages and implementing it with pidgin... that wouldn't have been my technical choice but why not...
my point is that there are lots of "obviously desktop" apps that are sometime used in the embedded world without pulling in the whole infrastructure, so in a way it makes sense to have them in buildroot.
the reason not to is unmaintained packages, but is it really a problem ? most mail we get about broken packages are fixes, not complaints, so I am not sure this is a problem...
Cordialement
J?r?my Rosen
fight key loggers : write some perl using vim
----- Mail original -----
Quoted 71 lines
Quoted 43 lines · Thomas Petazzoni
Hello all,
Quoted 8 lines · Stefan Fr?berg
I have been trying to cross-compile libotr package that makes it possible,
with the help of pidgin-otr plugin, to send encrypted messages with
Pidgin IM software
(which I already have successfully cross-compiled for buildroot and plan
to submit soon).I'd like to state my feeling on this: I believe that packaging desktop-level software like Pidgin or the Network-Manager Applet in Buildroot is useless. I don't think Buildroot is appropriate to build a
full-blown desktop distro, and even though Stefan is doing good work
with all those packages, I fear that once Stefan's work is over, those
packages will bit rot.Stefan, are you sure that Buildroot is appropriate for what you're trying to achieve? Have you looked at something like Gentoo? It builds
from source like Buildroot, has a package management system, and gazillions of desktop-level software already packaged. Since you're targeting x86, you don't need cross-compilation, which would have been
the reason for using Buildroot in the first place.And don't tell me you use Buildroot because of uClibc: when you're doing a full-blown desktop environment, using glibc or uClibc doesn't
make *any* difference, be it from a size perspective or a performance
perspective.What do others think about this?
Best regards,
Quoted 10 lines
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildrootI tend to agree that these kind of packages might be too much for buildroot, but keep in mind that Gentoo comes with a rather big uClibc
rootfs by default [1][1] http://distfiles.gentoo.org/experimental/x86/uclibc/
--
Regards,
Markos Chandras
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Quoted 5 lines · Markos Chandras
I tend to agree that these kind of packages might be too much for buildroot, but keep in mind that Gentoo comes with a rather big uClibc rootfs by default [1]
A craftman would use catalyst to build his own stage(s) with a minimal custom profile that gets rid of portage (thus ditching toolchain, python and a ton other bloating things).
You could even use qmerge (portage-utils) to install extras if you needed so.
Regards.
Dear Jeremy Rosen,
Could you please avoid top-posting, and use a decent mailer than wraps line properly? Thanks!
Quoted 5 lines · Jeremy Rosen
I am torn on that one... the frontier between embedded and not embedded never was very clear, and there are lots of single-purpose computers that have a screen and a keyboard to run a single graphical app.
Quoted 7 lines
I don't know the exact project here, but having a small screen displaying messages and implementing it with pidgin... that wouldn't have been my technical choice but why not...
my point is that there are lots of "obviously desktop" apps that are sometime used in the embedded world without pulling in the whole infrastructure, so in a way it makes sense to have them in buildroot.
Agreed. But what Stefan is doing is really a general-purpose distribution, he already told about his global project on the list in the past. So not only Pidgin is going to be packaged, but maybe also Abiword, Firefox, and why not LibreOffice?
Quoted 3 lines
the reason not to is unmaintained packages, but is it really a problem ? most mail we get about broken packages are fixes, not complaints, so I am not sure this is a problem...
To me, it is a problem. Many unmaintained packages means stuff that will maybe no longer build, giving a bad feeling about Buildroot's quality for newcomers. And if they still build thanks to our autobuilders and the work we do to fix the build issues, they will probably remain at very old versions, also giving a bad impression to new users or potential users evaluating Buildroot.
I think we managed to keep the focus on the infrastructure (don't generate binary packages, don't try to be too smart to guess what needs to be rebuilt, etc.), and we also should be thinking of keeping the focus in terms of packages.
Best regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Quoted 5 lines · Gustavo Zacarias
Quoted 4 lines · Markos Chandras
I tend to agree that these kind of packages might be too much for buildroot, but keep in mind that Gentoo comes with a rather big uClibc rootfs by default [1]
Quoted 9 lines
Quoted 1 line
A craftman would use catalyst to build his own stage(s) with a minimal custom profile that gets rid of portage (thus ditching toolchain, python and a ton other bloating things).
You could even use qmerge (portage-utils) to install extras if you needed so.
Regards.
True, but using catalyst is not trivial (the Gentoo documentation is rather bad in this area). On the other hand, buildroot does this job pretty good so I can understand why people want to make use of the existing buildroot infrastructure to build their embedded rootfs.
Signature · 2 lines
Regards, Markos Chandras
Dear Markos Chandras,
Quoted 5 lines · Markos Chandras
True, but using catalyst is not trivial (the Gentoo documentation is rather bad in this area). On the other hand, buildroot does this job pretty good so I can understand why people want to make use of the existing buildroot infrastructure to build their embedded rootfs.
Again, Stefan project is *not* an embedded rootfs. He builds a LiveCD of a full-blown desktop distribution.
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Quoted 2 lines · Thomas Petazzoni
Again, Stefan project is *not* an embedded rootfs. He builds a LiveCD of a full-blown desktop distribution.
An even better target for catalyst since it can build ISOs! Regards.
Quoted 4 lines · Thomas Petazzoni
Dear Markos Chandras,
On Thu, 28 Feb 2013 15:49:26 +0000, Markos Chandras wrote:
Quoted 9 lines
Quoted 5 lines
True, but using catalyst is not trivial (the Gentoo documentation is rather bad in this area). On the other hand, buildroot does this job pretty good so I can understand why people want to make use of the existing buildroot infrastructure to build their embedded rootfs.
Again, Stefan project is *not* an embedded rootfs. He builds a LiveCD of a full-blown desktop distribution.
HI Thomas,
Sorry I was not aware of that ( I must have missed the thread where he explained his goals )
so indeed buildroot does not seem appropriate for this task.
Signature · 2 lines
Regards, Markos Chandras
28.2.2013 17:48, Thomas Petazzoni kirjoitti:
Quoted 16 lines
Dear Jeremy Rosen,
Could you please avoid top-posting, and use a decent mailer than wraps line properly? Thanks!
Quoted 9 lines · Jeremy Rosen
I am torn on that one... the frontier between embedded and not embedded never was very clear, and there are lots of single-purpose computers that have a screen and a keyboard to run a single graphical app.
I don't know the exact project here, but having a small screen displaying messages and implementing it with pidgin... that wouldn't have been my technical choice but why not...
Quoted 7 lines
Quoted 3 lines
my point is that there are lots of "obviously desktop" apps that are sometime used in the embedded world without pulling in the whole infrastructure, so in a way it makes sense to have them in buildroot.
Agreed. But what Stefan is doing is really a general-purpose distribution, he already told about his global project on the list in the past. So not only Pidgin is going to be packaged, but maybe also Abiword, Firefox, and why not LibreOffice?
Eh, LibreOffice is little bit too much even for me :-) And Abiwrod... well let's say im just happy with leafpad.
But why not Firefox ? After all there are mobile version of it ?
Regards
Stefan
28.2.2013 17:58, Stefan Fr?berg kirjoitti:
Quoted 23 lines
28.2.2013 17:21, Thomas Petazzoni kirjoitti:
Quoted 22 lines
Hello all,
Quoted 5 lines · Stefan Fr?berg
I have been trying to cross-compile libotr package that makes it possible, with the help of pidgin-otr plugin, to send encrypted messages with Pidgin IM software
(which I already have successfully cross-compiled for buildroot and plan to submit soon).I'd like to state my feeling on this: I believe that packaging desktop-level software like Pidgin or the Network-Manager Applet in Buildroot is useless. I don't think Buildroot is appropriate to build a full-blown desktop distro, and even though Stefan is doing good work with all those packages, I fear that once Stefan's work is over, those packages will bit rot.
Stefan, are you sure that Buildroot is appropriate for what you're trying to achieve? Have you looked at something like Gentoo? It builds from source like Buildroot, has a package management system, and gazillions of desktop-level software already packaged. Since you're targeting x86, you don't need cross-compilation, which would have been the reason for using Buildroot in the first place.
Yes Im a gentoo guy and been that since 2005 and even now my servers are running
hardened version of it.
Also done Linux from scratch for my own systems several years ago.
However both projects have two problems:
a ) Gentoo is great but to have ultimate flexibility I needed to go to "bare metal" without hacking portage and ebuild files.
b ) Linux from scratch is bare to the metal but after a while it gets tedious to *manually* grab source code, patch it, configure it yadda-yadda....
I wanted something of the combination of the two and buildroot with it's automatic build system filled that niche nicely for me.
Quoted 11 lines
Quoted 11 lines
And don't tell me you use Buildroot because of uClibc: when you're doing a full-blown desktop environment, using glibc or uClibc doesn't make *any* difference, be it from a size perspective or a performance perspective.
What do others think about this?
Best regards,
Thomas
Well, at least my home grown distro *feels* faster and takes less space than anything I have tried before :-)
I have a fully working, uClibc system now that can also compile code with native gcc, to rpm packages and use
those same rpm packages with also uClibc compiled yum and Fedora version of rpm tool.
So buildroot is not *absolute* necessity to me anymore...
It just that so far, it has been the most time saving mechanism for me (it's tedious to extract RPM .spec files from Fedora src.rpm's, edit them, compile them and
package them. or even worse, make completely new .spec file from scratch)
But if you guys don't need any of that desktop stuff (nm-applet, gnome-keyring, pidgin etc...) then
please tell me so and I will again fully concentrate on building slowly my own system repository
(it needs updating anyway):
http://binarytouch.com/Singularity/RPMS/i586/
Regards
Stefan