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


 
 
LinkBack Thread Tools
 
Old 11-14-2010, 08:03 PM
Thomas Kahle
 
Default fat binaries

Hi,

I have a package (sci-libs/mpir) whose configure supports building of
fat binaries with both x86 and amd64 assembler in the binary. While I
personally think it is not useful to gentoo users, one might still want
to give the choice to build the fat binary.

-) Are there other packages that can build fat binaries ?

If yes,

-) How to name the USE flag?

Cheers,
Thomas



--
Thomas Kahle
http://dev.gentoo.org/~tomka/
 
Old 11-14-2010, 10:30 PM
Diego Elio Pettenò
 
Default fat binaries

Il giorno dom, 14/11/2010 alle 22.03 +0100, Thomas Kahle ha scritto:
> I have a package (sci-libs/mpir) whose configure supports building of
> fat binaries with both x86 and amd64 assembler in the binary.

Oh the heck are they implemented? If they are FatELF, no they shouldn't
be used, ever, full stop.

In most cases, this sounds fishy and almost a hack deemed to failure so
my default vote would be "do not expose this functionality to the user".

--
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/

If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/
 
Old 11-14-2010, 10:41 PM
Thomas Kahle
 
Default fat binaries

On 00:30 Mon 15 Nov , Diego Elio Pettenò wrote:
> Il giorno dom, 14/11/2010 alle 22.03 +0100, Thomas Kahle ha scritto:
> > I have a package (sci-libs/mpir) whose configure supports building of
> > fat binaries with both x86 and amd64 assembler in the binary.
>
> Oh the heck are they implemented? If they are FatELF, no they shouldn't
> be used, ever, full stop.

They don't tell. From the manual:

Fat binary, ‘--enable-fat’

Using ‘--enable-fat’ selects a “fat binary” build on x86 or x86 64
systems, where optimized low level subroutines are chosen at runtime
according to the CPU de- tected. This means more code, but gives
reasonable performance from a single bi- nary for all x86 chips, or
similarly for all x86 64 chips. (This option might become available for
more architectures in the future.)

Cheers,
Thomas



--
Thomas Kahle
http://dev.gentoo.org/~tomka/
 
Old 11-14-2010, 11:30 PM
Nikos Chantziaras
 
Default fat binaries

On 11/15/2010 01:30 AM, Diego Elio Petten wrote:

Il giorno dom, 14/11/2010 alle 22.03 +0100, Thomas Kahle ha scritto:

I have a package (sci-libs/mpir) whose configure supports building of
fat binaries with both x86 and amd64 assembler in the binary.


Oh the heck are they implemented? If they are FatELF, no they shouldn't
be used, ever, full stop.

In most cases, this sounds fishy and almost a hack deemed to failure so
my default vote would be "do not expose this functionality to the user".


It's not FatELF. It's pretty much what the Intel compiler does, but in
this case it's done by hand; the binary includes several versions of the
code. Which version is executed depends on the CPU detected at runtime.
Has nothing to do with the FatELF brain damage :-)
 
Old 11-15-2010, 02:27 AM
Jeremy Olexa
 
Default fat binaries

On 11/14/2010 05:41 PM, Thomas Kahle wrote:

On 00:30 Mon 15 Nov , Diego Elio Pettenò wrote:

Il giorno dom, 14/11/2010 alle 22.03 +0100, Thomas Kahle ha scritto:

I have a package (sci-libs/mpir) whose configure supports building of
fat binaries with both x86 and amd64 assembler in the binary.


Oh the heck are they implemented? If they are FatELF, no they shouldn't
be used, ever, full stop.


They don't tell. From the manual:

Fat binary, ‘--enable-fat’

Using ‘--enable-fat’ selects a “fat binary” build on x86 or x86 64
systems, where optimized low level subroutines are chosen at runtime
according to the CPU de- tected. This means more code, but gives
reasonable performance from a single bi- nary for all x86 chips, or
similarly for all x86 64 chips. (This option might become available for
more architectures in the future.)


This is useless for Gentoo Users, IMO. Besides, the people that *want*
this (anyone?) can use 'EXTRA_ECONF="--enable-fat" emerge sci-libs/mpir'


-Jeremy
 
Old 11-15-2010, 07:30 AM
Mike Frysinger
 
Default fat binaries

On Sunday, November 14, 2010 16:03:12 Thomas Kahle wrote:
> I have a package (sci-libs/mpir) whose configure supports building of
> fat binaries with both x86 and amd64 assembler in the binary. While I
> personally think it is not useful to gentoo users, one might still want
> to give the choice to build the fat binary.

sounds like something upstream should switch to GNU_IFUNC
-mike
 
Old 11-15-2010, 01:28 PM
Diego Elio Pettenò
 
Default fat binaries

Il giorno lun, 15/11/2010 alle 00.41 +0100, Thomas Kahle ha scritto:
> Using ‘--enable-fat’ selects a “fat binary” build on x86 or x86 64
> systems, where optimized low level subroutines are chosen at runtime
> according to the CPU de- tected. This means more code, but gives
> reasonable performance from a single bi- nary for all x86 chips, or
> similarly for all x86 64 chips. (This option might become available
> for
> more architectures in the future.)

Okay this then has nothing to do with FatELF, and the name "fat binary"
here is misused by most canons. What you have is instead a "runtime cpu
detection", which is something glibc (via ifunc), ffmpeg, mplayer, xine
and so on already supports.

My personal suggestion having worked with that kind of code is not to
enable it unless it has more fine-grained logic than the simple
arch-based one (such as FFmpeg's way to detect broken SSE3
implementations). And if you do enable it, the USE flag you need is
"cpudetection" (already used by ffmpeg, mplayer and
jack-audio-connection-kit).

--
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/

If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/
 

Thread Tools




All times are GMT. The time now is 10:10 PM.

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