[Buildroot] Help needed with cross-compiling libotr

[Buildroot] Help needed with cross-compiling libotr

[Stefan Fröberg]

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

      http://www.cypherpunks.ca/otr

#############################################################
#
# libotr
#
#############################################################

LIBOTR_VERSION = 4.0.0
LIBOTR_SITE = http://www.cypherpunks.ca/otr
LIBOTR_AUTORECONF = YES
LIBOTR_AUTORECONF_OPTS = --install --force
LIBOTR_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 )
endef

LIBOTR_POST_CONFIGURE_HOOKS += LIBOTR_POST_CONFIGURE_FIXUP

$(eval $(autotools-package))



Thank you!

Regards
Stefan

[Buildroot] Help needed with cross-compiling libotr

[Stefan Fröberg]

28.2.2013 17:04, Stefan Fr?berg kirjoitti:
> 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

Ach!
I meant from here:
http://www.cypherpunks.ca/otr/libotr-4.0.0.tar.gz

[Buildroot] Help needed with cross-compiling libotr

[Thomas Petazzoni]

Hello all,

On Thu, 28 Feb 2013 17:04:23 +0200, Stefan Fr?berg wrote:

> 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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Help needed with cross-compiling libotr

[Markos Chandras]

On 28 February 2013 15:21, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello all,
>
> On Thu, 28 Feb 2013 17:04:23 +0200, Stefan Fr?berg wrote:
>
>> 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
> --
> 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/

-- 
Regards,
Markos Chandras

[Buildroot] Help needed with cross-compiling libotr

[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...

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 -----
> On 28 February 2013 15:21, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > Hello all,
> >
> > On Thu, 28 Feb 2013 17:04:23 +0200, Stefan Fr?berg wrote:
> >
> >> 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
> > --
> > 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/
> 
> --
> Regards,
> Markos Chandras
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 

[Buildroot] Help needed with cross-compiling libotr

[Thomas Petazzoni]

Dear Jeremy Rosen,

Could you please avoid top-posting, and use a decent mailer than wraps
line properly? Thanks!

On Thu, 28 Feb 2013 16:43:01 +0100 (CET), Jeremy Rosen wrote:

> 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.

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?

> 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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Help needed with cross-compiling libotr

[Stefan Fröberg]

28.2.2013 17:48, Thomas Petazzoni kirjoitti:
> Dear Jeremy Rosen,
>
> Could you please avoid top-posting, and use a decent mailer than wraps
> line properly? Thanks!
>
> On Thu, 28 Feb 2013 16:43:01 +0100 (CET), Jeremy Rosen wrote:
>
>> 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.
> 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

[Buildroot] Help needed with cross-compiling libotr

[Gustavo Zacarias]

On 02/28/2013 12:36 PM, Markos Chandras wrote:
> 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/

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.

[Buildroot] Help needed with cross-compiling libotr

[Markos Chandras]

On 28 February 2013 15:43, Gustavo Zacarias <gustavo@zacarias.com.ar> wrote:
> On 02/28/2013 12:36 PM, Markos Chandras wrote:
>> 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/
>
> 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.

-- 
Regards,
Markos Chandras

[Buildroot] Help needed with cross-compiling libotr

[Thomas Petazzoni]

Dear Markos Chandras,

On Thu, 28 Feb 2013 15:49:26 +0000, Markos Chandras wrote:

> 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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Help needed with cross-compiling libotr

[Gustavo Zacarias]

On 02/28/2013 12:50 PM, Thomas Petazzoni wrote:

> 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.

[Buildroot] Help needed with cross-compiling libotr

[Markos Chandras]

On 28 February 2013 15:50, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Markos Chandras,
>
> On Thu, 28 Feb 2013 15:49:26 +0000, Markos Chandras wrote:
>
>> 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.

-- 
Regards,
Markos Chandras

[Buildroot] Help needed with cross-compiling libotr

[Stefan Fröberg]

28.2.2013 17:58, Stefan Fr?berg kirjoitti:
> 28.2.2013 17:21, Thomas Petazzoni kirjoitti:
>> Hello all,
>>
>> On Thu, 28 Feb 2013 17:04:23 +0200, Stefan Fr?berg wrote:
>>
>>> 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.



>
>> 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



>
>
>
>