FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 07-12-2012, 03:40 PM
Ezequiel Garcia
 
Default Can't emerge gnash

Hi,

I was trying to emerge gnash but failed. Here's the output....

The problem seems to be boost_thread not present. I'll try to emerge
that, but in any case this
looks like a gentoo bug in gnash ebuild.

If anyone helps me filling a new bug, I'll appreciate it.

---

CXX libgnashdevice_la-DeviceGlue.lo
/bin/sh ../libtool --silent --tag=CXX --mode=compile
i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I. -I..
-I../libmedia -I../libbase -I../librender -I../libcore -I../libcore/vm
-I../libcore/parser -I../libcore/swf -I../gui -pthread
-I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -pthread
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -pthread -I/usr/include/gtk-2.0
-I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/pixman-1 -I/usr/include/freetype2
-I/usr/include/libpng15 -pthread -I/usr/include/atk-1.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/libpng15 -I/usr/include/boost-1_42
-I/usr/include/agg2 -pthread -I/usr/include/cairo
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/pixman-1 -I/usr/include/freetype2
-I/usr/include/libpng15 -O2 -march=i686 -pipe -W
-Wall -Wcast-align -Wcast-qual -Wpointer-arith
-Wreturn-type -Wnon-virtual-dtor -Wunused
-fvisibility-inlines-hidden -c -o libgnashdevice_la-DeviceGlue.lo
`test -f 'DeviceGlue.cpp' || echo './'`DeviceGlue.cpp
In file included from
/usr/include/boost-1_42/boost/thread/detail/platform.hpp:17:0,
from /usr/include/boost-1_42/boost/thread/mutex.hpp:12,
from ../libbase/log.h:30,
from x11/X11Device.cpp:28:
/usr/include/boost-1_42/boost/config/requires_threads.hpp:29:4: error:
#error "Threading support unavaliable: it has been explicitly disabled
with BOOST_DISABLE_THREADS"In file included from
/usr/include/boost-1_42/boost/thread/detail/platform.hpp:17:0,
from /usr/include/boost-1_42/boost/thread/mutex.hpp:12,
from ../libbase/log.h:30,
from GnashDevice.h:28,
from DeviceGlue.h:30,
from DeviceGlue.cpp:23:
/usr/include/boost-1_42/boost/config/requires_threads.hpp:29:4: error:
#error "Threading support unavaliable: it has been explicitly disabled
with BOOST_DISABLE_THREADS"

In file included from /usr/include/boost-1_42/boost/thread/mutex.hpp:12:0,
from ../libbase/log.h:30,
from x11/X11Device.cpp:28:
/usr/include/boost-1_42/boost/thread/detail/platform.hpp:67:9: error:
#error "Sorry, no boost threads are available for this platform."In
file included from
/usr/include/boost-1_42/boost/thread/mutex.hpp:12:0,
from ../libbase/log.h:30,
from GnashDevice.h:28,
from DeviceGlue.h:30,
from DeviceGlue.cpp:23:
/usr/include/boost-1_42/boost/thread/detail/platform.hpp:67:9: error:
#error "Sorry, no boost threads are available for this platform."

In file included from ../libbase/log.h:30:0,
from x11/X11Device.cpp:28:
/usr/include/boost-1_42/boost/thread/mutex.hpp:18:2: error: #error
"Boost threads unavailable on this platform"In file included from
../libbase/log.h:30:0,
from GnashDevice.h:28,
from DeviceGlue.h:30,
from DeviceGlue.cpp:23:
/usr/include/boost-1_42/boost/thread/mutex.hpp:18:2: error: #error
"Boost threads unavailable on this platform"

In file included from GnashDevice.h:28:0,
from DeviceGlue.h:30,
from DeviceGlue.cpp:23:
../libbase/log.h:204:5: error: 'mutex' in namespace 'boost' does not name a type
make[2]: *** [libgnashdevice_la-DeviceGlue.lo] Error 1
make[2]: *** Waiting for unfinished jobs....
In file included from x11/X11Device.cpp:28:0:
../libbase/log.h:204:5: error: 'mutex' in namespace 'boost' does not name a type
make[2]: *** [libgnashdevice_la-X11Device.lo] Error 1
make[2]: Leaving directory
`/var/tmp/portage/www-plugins/gnash-0.8.10-r2/work/gnash-0.8.10/libdevice'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/var/tmp/portage/www-plugins/gnash-0.8.10-r2/work/gnash-0.8.10'
make: *** [all] Error 2
* ERROR: www-plugins/gnash-0.8.10-r2 failed (compile phase):
* emake failed
*
* If you need support, post the output of 'emerge --info
=www-plugins/gnash-0.8.10-r2',
* the complete build log and the output of 'emerge -pqv
=www-plugins/gnash-0.8.10-r2'.
* The complete build log is located at
'/var/tmp/portage/www-plugins/gnash-0.8.10-r2/temp/build.log'.
* The ebuild environment file is located at
'/var/tmp/portage/www-plugins/gnash-0.8.10-r2/temp/environment'.
* S: '/var/tmp/portage/www-plugins/gnash-0.8.10-r2/work/gnash-0.8.10'

>>> Failed to emerge www-plugins/gnash-0.8.10-r2, Log file:

>>> '/var/tmp/portage/www-plugins/gnash-0.8.10-r2/temp/build.log'

* Messages for package www-plugins/gnash-0.8.10-r2:

* ERROR: www-plugins/gnash-0.8.10-r2 failed (compile phase):
* emake failed
*
* If you need support, post the output of 'emerge --info
=www-plugins/gnash-0.8.10-r2',
* the complete build log and the output of 'emerge -pqv
=www-plugins/gnash-0.8.10-r2'.
* The complete build log is located at
'/var/tmp/portage/www-plugins/gnash-0.8.10-r2/temp/build.log'.
* The ebuild environment file is located at
'/var/tmp/portage/www-plugins/gnash-0.8.10-r2/temp/environment'.
* S: '/var/tmp/portage/www-plugins/gnash-0.8.10-r2/work/gnash-0.8.10'
---

Thanks,
Ezequiel.
 
Old 07-12-2012, 06:39 PM
Florian Philipp
 
Default Can't emerge gnash

Am 12.07.2012 17:40, schrieb Ezequiel Garcia:
> Hi,
>
> I was trying to emerge gnash but failed. Here's the output....
>
> The problem seems to be boost_thread not present. I'll try to emerge
> that, but in any case this
> looks like a gentoo bug in gnash ebuild.
>
> If anyone helps me filling a new bug, I'll appreciate it.
>
[...]

Could be related to
https://bugs.gentoo.org/show_bug.cgi?id=366407

Regards,
Florian Philipp
 
Old 07-12-2012, 07:36 PM
Ezequiel Garcia
 
Default Can't emerge gnash

On Thu, Jul 12, 2012 at 3:39 PM, Florian Philipp <lists@binarywings.net> wrote:
> Am 12.07.2012 17:40, schrieb Ezequiel Garcia:
>> Hi,
>>
>> I was trying to emerge gnash but failed. Here's the output....
>>
>> The problem seems to be boost_thread not present. I'll try to emerge
>> that, but in any case this
>> looks like a gentoo bug in gnash ebuild.
>>
>> If anyone helps me filling a new bug, I'll appreciate it.
>>
> [...]
>
> Could be related to
> https://bugs.gentoo.org/show_bug.cgi?id=366407
>

Thanks!

It seems this is a different bug.

Before filing a new bug, I should do emerge --sync,
(to have latest ebuilds), right?

I wonder why they've used boost! (I'm not a big fan of it)

Regards,
Ezequiel.
 
Old 07-12-2012, 07:48 PM
Michael Mol
 
Default Can't emerge gnash

On Thu, Jul 12, 2012 at 3:36 PM, Ezequiel Garcia <elezegarcia@gmail.com> wrote:
> On Thu, Jul 12, 2012 at 3:39 PM, Florian Philipp <lists@binarywings.net> wrote:
>> Am 12.07.2012 17:40, schrieb Ezequiel Garcia:
>>> Hi,
>>>
>>> I was trying to emerge gnash but failed. Here's the output....
>>>
>>> The problem seems to be boost_thread not present. I'll try to emerge
>>> that, but in any case this
>>> looks like a gentoo bug in gnash ebuild.
>>>
>>> If anyone helps me filling a new bug, I'll appreciate it.
>>>
>> [...]
>>
>> Could be related to
>> https://bugs.gentoo.org/show_bug.cgi?id=366407
>>
>
> Thanks!
>
> It seems this is a different bug.
>
> Before filing a new bug, I should do emerge --sync,
> (to have latest ebuilds), right?

For me, I'd go:

# In case there's something already broken I don't know about.
revdep-rebuild

# Remove 'theoretically' unused versions of things.
emerge --depclean

# Because we ran --depclean, something may now be broken.
revdep-rebuild

# does an emerge --sync
eix-sync

# Perhaps specify the particular package, instead of @world
emerge --update --deep --newuse @world

# Again, remove old versions of things.
emerge --depclean

# Again, because --depclean can break things.
revdep-rebuild

...and then see if I can reproduce it.

> I wonder why they've used boost! (I'm not a big fan of it)

Boost probably had some code in it they didn't want to reinvent
themselves. It's also pretty common, which makes things easier for a
developer who wants to get into more distributions' repositories.

--
:wq
 
Old 07-12-2012, 07:59 PM
Ezequiel Garcia
 
Default Can't emerge gnash

Hi Michael,

On Thu, Jul 12, 2012 at 4:48 PM, Michael Mol <mikemol@gmail.com> wrote:
> On Thu, Jul 12, 2012 at 3:36 PM, Ezequiel Garcia <elezegarcia@gmail.com> wrote:
>> On Thu, Jul 12, 2012 at 3:39 PM, Florian Philipp <lists@binarywings.net> wrote:
>>> Am 12.07.2012 17:40, schrieb Ezequiel Garcia:
>>>> Hi,
>>>>
>>>> I was trying to emerge gnash but failed. Here's the output....
>>>>
>>>> The problem seems to be boost_thread not present. I'll try to emerge
>>>> that, but in any case this
>>>> looks like a gentoo bug in gnash ebuild.
>>>>
>>>> If anyone helps me filling a new bug, I'll appreciate it.
>>>>
>>> [...]
>>>
>>> Could be related to
>>> https://bugs.gentoo.org/show_bug.cgi?id=366407
>>>
>>
>> Thanks!
>>
>> It seems this is a different bug.
>>
>> Before filing a new bug, I should do emerge --sync,
>> (to have latest ebuilds), right?
>
> For me, I'd go:
>
> # In case there's something already broken I don't know about.
> revdep-rebuild
>
> # Remove 'theoretically' unused versions of things.
> emerge --depclean
>
> # Because we ran --depclean, something may now be broken.
> revdep-rebuild
>
> # does an emerge --sync
> eix-sync
>
> # Perhaps specify the particular package, instead of @world
> emerge --update --deep --newuse @world
>
> # Again, remove old versions of things.
> emerge --depclean
>
> # Again, because --depclean can break things.
> revdep-rebuild
>
> ...and then see if I can reproduce it.
>

Ok, I'll do that.


>> I wonder why they've used boost! (I'm not a big fan of it)
>
> Boost probably had some code in it they didn't want to reinvent
> themselves. It's also pretty common, which makes things easier for a
> developer who wants to get into more distributions' repositories.
>

Of course. But then again, this is arguable.

In theory reusing code is a great thing,
in practice I've seen it leading to big bloating problems.

Also as a developer I don't really like to force my users
to have a monster library installed to use my code.

But that's just my humble opinion.
Ezequiel.
 
Old 07-12-2012, 08:14 PM
Michael Mol
 
Default Can't emerge gnash

On Thu, Jul 12, 2012 at 3:59 PM, Ezequiel Garcia <elezegarcia@gmail.com> wrote:
> Hi Michael,
>
> On Thu, Jul 12, 2012 at 4:48 PM, Michael Mol <mikemol@gmail.com> wrote:
>> On Thu, Jul 12, 2012 at 3:36 PM, Ezequiel Garcia <elezegarcia@gmail.com> wrote:
>>> On Thu, Jul 12, 2012 at 3:39 PM, Florian Philipp <lists@binarywings.net> wrote:
>>>> Am 12.07.2012 17:40, schrieb Ezequiel Garcia:
>>>>> Hi,
>>>>>
>>>>> I was trying to emerge gnash but failed. Here's the output....
>>>>>
>>>>> The problem seems to be boost_thread not present. I'll try to emerge
>>>>> that, but in any case this
>>>>> looks like a gentoo bug in gnash ebuild.
>>>>>
>>>>> If anyone helps me filling a new bug, I'll appreciate it.
>>>>>
>>>> [...]
>>>>
>>>> Could be related to
>>>> https://bugs.gentoo.org/show_bug.cgi?id=366407
>>>>
>>>
>>> Thanks!
>>>
>>> It seems this is a different bug.
>>>
>>> Before filing a new bug, I should do emerge --sync,
>>> (to have latest ebuilds), right?
>>
>> For me, I'd go:
>>
>> # In case there's something already broken I don't know about.
>> revdep-rebuild
>>
>> # Remove 'theoretically' unused versions of things.
>> emerge --depclean
>>
>> # Because we ran --depclean, something may now be broken.
>> revdep-rebuild
>>
>> # does an emerge --sync
>> eix-sync
>>
>> # Perhaps specify the particular package, instead of @world
>> emerge --update --deep --newuse @world
>>
>> # Again, remove old versions of things.
>> emerge --depclean
>>
>> # Again, because --depclean can break things.
>> revdep-rebuild
>>
>> ...and then see if I can reproduce it.
>>
>
> Ok, I'll do that.
>
>
>>> I wonder why they've used boost! (I'm not a big fan of it)
>>
>> Boost probably had some code in it they didn't want to reinvent
>> themselves. It's also pretty common, which makes things easier for a
>> developer who wants to get into more distributions' repositories.
>>
>
> Of course. But then again, this is arguable.
>
> In theory reusing code is a great thing,
> in practice I've seen it leading to big bloating problems.
>
> Also as a developer I don't really like to force my users
> to have a monster library installed to use my code.

Developer here, too. Mostly C++ on Windows, though I far prefer the
way Linux does things.

In theory, using in-house code seems like a great thing. Having
written it, I understand it, I understand its API, and it's not a big
blob of unknowns for me to fear when debugging my programs.

In practice, I've seen more time (and money!) spent reinventing the
wheel for any given project than it would take to pull in a library.
I've seen and participated, designed and/or led in the redevelopment
of locking mechanisms, nested image compositing engines, database
abstraction layers, deferred I/O abstraction frameworks and probably a
half-dozen other things I'm forgetting right now.

Each and _every_ time, a great deal amount of developer time is
consumed at the outset with development, and then over the life of the
code as bugs (some of which simply come from underestimating or
misunderstanding the resulting complexity of the system) turn up.

NIH costs. I'd rather use a widespread library than write my own,
wherever possible.

But, of course, that's just _my_ humble opinion. And each circumstance
warrants its own cost/benefit analysis.

--
:wq
 
Old 07-12-2012, 08:27 PM
"Walter Dnes"
 
Default Can't emerge gnash

On Thu, Jul 12, 2012 at 12:40:55PM -0300, Ezequiel Garcia wrote
> Hi,
>
> I was trying to emerge gnash but failed. Here's the output....
>
> The problem seems to be boost_thread not present. I'll try to emerge
> that, but in any case this looks like a gentoo bug in gnash ebuild.

Change the jobs option in /etc/make.conf to 1, i.e...

MAKEOPTS="-j1"

You'd be surprised how many "unreproducable" bugs that fixes. I
simply leave it at that setting all the time. Yes, it takes a little
bit longer to build, but the compiled binary runs just as fast. And any
time you "save" building will be lost the first time you spend a few
hours trying to figure out mysterious build failures.

--
Walter Dnes <waltdnes@waltdnes.org>
 
Old 07-12-2012, 08:37 PM
Ezequiel Garcia
 
Default Can't emerge gnash

On Thu, Jul 12, 2012 at 5:14 PM, Michael Mol <mikemol@gmail.com> wrote:

>
> Developer here, too. Mostly C++ on Windows, though I far prefer the
> way Linux does things.
>
> In theory, using in-house code seems like a great thing. Having
> written it, I understand it, I understand its API, and it's not a big
> blob of unknowns for me to fear when debugging my programs.
>
> In practice, I've seen more time (and money!) spent reinventing the
> wheel for any given project than it would take to pull in a library.
> I've seen and participated, designed and/or led in the redevelopment
> of locking mechanisms, nested image compositing engines, database
> abstraction layers, deferred I/O abstraction frameworks and probably a
> half-dozen other things I'm forgetting right now.
>
> Each and _every_ time, a great deal amount of developer time is
> consumed at the outset with development, and then over the life of the
> code as bugs (some of which simply come from underestimating or
> misunderstanding the resulting complexity of the system) turn up.
>
> NIH costs. I'd rather use a widespread library than write my own,
> wherever possible.
>
> But, of course, that's just _my_ humble opinion. And each circumstance
> warrants its own cost/benefit analysis.
>

This is off-topic now :-( But it's a nice discussion :-)

I agree with you mostly. I think you're a bit biased against
rolling-your-own, perhaps
because working on windows enforces that -there are less open
libraries/programs you can reuse-.

Again, it's a great thing to re-use and it's evil to reinvent the wheel.
It has all sorts of advantages, we all know that.

On the other hand, as you say, each circumstance needs its own analysis.

Let me use an example: I'm writing a middle-size application in C++ that
will run on an embedded device, linux only.
Let's say I need some threads and some mutexes.
Heck, I'm not going to use boost if I can just wrap pthreads around
some lightweight classes.

Regards,
Ezequiel.
 
Old 07-12-2012, 08:47 PM
Michael Mol
 
Default Can't emerge gnash

On Thu, Jul 12, 2012 at 4:37 PM, Ezequiel Garcia <elezegarcia@gmail.com> wrote:
> On Thu, Jul 12, 2012 at 5:14 PM, Michael Mol <mikemol@gmail.com> wrote:
>
>>
>> Developer here, too. Mostly C++ on Windows, though I far prefer the
>> way Linux does things.
>>
>> In theory, using in-house code seems like a great thing. Having
>> written it, I understand it, I understand its API, and it's not a big
>> blob of unknowns for me to fear when debugging my programs.
>>
>> In practice, I've seen more time (and money!) spent reinventing the
>> wheel for any given project than it would take to pull in a library.
>> I've seen and participated, designed and/or led in the redevelopment
>> of locking mechanisms, nested image compositing engines, database
>> abstraction layers, deferred I/O abstraction frameworks and probably a
>> half-dozen other things I'm forgetting right now.
>>
>> Each and _every_ time, a great deal amount of developer time is
>> consumed at the outset with development, and then over the life of the
>> code as bugs (some of which simply come from underestimating or
>> misunderstanding the resulting complexity of the system) turn up.
>>
>> NIH costs. I'd rather use a widespread library than write my own,
>> wherever possible.
>>
>> But, of course, that's just _my_ humble opinion. And each circumstance
>> warrants its own cost/benefit analysis.
>>
>
> This is off-topic now :-( But it's a nice discussion :-)
>
> I agree with you mostly. I think you're a bit biased against
> rolling-your-own, perhaps
> because working on windows enforces that -there are less open
> libraries/programs you can reuse-.
>
> Again, it's a great thing to re-use and it's evil to reinvent the wheel.
> It has all sorts of advantages, we all know that.
>
> On the other hand, as you say, each circumstance needs its own analysis.
>
> Let me use an example: I'm writing a middle-size application in C++ that
> will run on an embedded device, linux only.
> Let's say I need some threads and some mutexes.
> Heck, I'm not going to use boost if I can just wrap pthreads around
> some lightweight classes.

In that circumstance, you're mostly going to be distributing firmware
blobs. I'd probably rip the relevant code out of boost (perhaps set up
a script to do this), drop it somewhere in my project folders, and tie
it in with my build system. Respecting, of course, the license
requirements of boost.

It's unfortunate that boost's build system isn't modular, and
especially that it won't parallelize. I'll probably look at it at some
point to figure out if I know enough to rewrite it in autotools. I
could totally see a "--with-this-module=yes" per-module, as opposed to
an "--enable-all" for those users who don't know which parts they do
or don't need.

It's something that needs to be done. The question is who's going to
have the time and inclination.

--
:wq
 
Old 07-12-2012, 08:48 PM
Michael Mol
 
Default Can't emerge gnash

On Thu, Jul 12, 2012 at 4:27 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Thu, Jul 12, 2012 at 12:40:55PM -0300, Ezequiel Garcia wrote
>> Hi,
>>
>> I was trying to emerge gnash but failed. Here's the output....
>>
>> The problem seems to be boost_thread not present. I'll try to emerge
>> that, but in any case this looks like a gentoo bug in gnash ebuild.
>
> Change the jobs option in /etc/make.conf to 1, i.e...
>
> MAKEOPTS="-j1"
>
> You'd be surprised how many "unreproducable" bugs that fixes. I
> simply leave it at that setting all the time. Yes, it takes a little
> bit longer to build, but the compiled binary runs just as fast. And any
> time you "save" building will be lost the first time you spend a few
> hours trying to figure out mysterious build failures.

Good observation. I usually look at the build log and file bug reports
when I see that happen. It can take a while to learn to recognize, but
it usually takes less than a minute to spot. I could probably automate
it with a shell script and grep. Hm.

(Parallel building cuts my build time for a full system two a mere few
hours, IIRC. A serial build of a full system takes could be started
before I go to sleep, and wouldn't be done before I went into work the
next day.)

(I tried tricking genlop into giving me the build time of an emerge
-pe by putting -e in EMERGE_DEFAULT_OPTS, but it appears to be hung.
)

--
:wq
 

Thread Tools




All times are GMT. The time now is 02:17 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org