Re: [gentoo-user] Gcc 4.3.4 ---> 4.4.1

[Neil Bothwick]

On Fri, 14 Aug 2009 16:17:56 -0700, fe...@crowfix.com wrote:

> Are any special steps needed to handle this upgrade, other than using
> gcc-config to change the current selection?  Do I need to follow the
> upgrade docs, such as  remergeing system and world?

I switched to gcc:4.4 a couple of months ago and didn't rebuild anything.


-- 
Neil Bothwick

The trouble with doing something right the first time is that nobody
appreciates how difficult it was.


signature.asc
Description: PGP signature

Re: [gentoo-user] Problem emerging alsa-utils-1.0.20-r4

[Mick]

On Friday 14 August 2009, Alan McKinnon wrote:
> On Friday 14 August 2009 22:23:14 Mick wrote:
> > > Obviously, the existence of /etc/modules.d/alsa does not allow emerge
> > > to continue. I think you must merge alsa file to alsa.conf and then
> > > delete alsa.
> >
> > Perhaps I'm too tired to understand the message ... is it telling to move
> > file /etc/modules.d/alsa to /etc/modprobe.d/alsa.conf by hand?
>
> Yes.
>
> /etc/modules.d/ is a kernel 2.4 thing. kernel 2.6 uses /etc/modprobe.d/ and
> the modprobe utilities will automatically search it for config files, which
> makes /etc/modprobe.conf and modules-update obsolete.
>
> Someone has obviously taken the brave step and put a stake in the sane with
> a signpost saying "2.4 is not supported".

Thank you all, job's done.

-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] prelink Gentoo docs confusing

[Albert Hopkins]

On Fri, 2009-08-14 at 18:27 +0300, Nikos Chantziaras wrote:
> On http://www.gentoo.org/doc/en/prelink-howto.xml is says:
> 
>You do not need to set FEATURES="prelink" in your make.conf
>file; Portage will automatically support prelink if it can
>find the prelink binary.
> 
> Does that mean there's a way portage will call prelink on its own when 
> it finds it?  Well, it doesn't here.  I still have to manually prelink 
> or have a cron job.

I've always wondered this too, so I decided to test it:

* Put "prelink" in my FEATURES in make.conf

* mv /usr/sbin/prelink /usr/sbin/prelink.0
* Created /usr/sbin/prelink shell script with the following:
# cat /usr/sbin/prelink
#!/bin/sh

echo `date` $* >> /tmp/prelink.txt

* # rm -f /tmp/prelink.txt ; emerge -1 tar

* # cat /tmp/prelink.txt 
Sat Aug 15 07:45:35 EDT 2009 --version
Sat Aug 15 07:45:41 EDT 2009 --version
Sat Aug 15 07:46:16 EDT 2009
--verify /var/scratch/portage/app-arch/tar-1.22/image/bin/tar
Sat Aug 15 07:46:16 EDT 2009
--verify 
/var/scratch/portage/app-arch/tar-1.22/image/usr/lib/debug/bin/tar.debug
Sat Aug 15 07:46:16 EDT 2009
--verify 
/var/scratch/portage/app-arch/tar-1.22/image/usr/lib/debug/usr/sbin/rmt.debug
Sat Aug 15 07:46:16 EDT 2009
--verify /var/scratch/portage/app-arch/tar-1.22/image/usr/sbin/backup-tar
Sat Aug 15 07:46:16 EDT 2009
--verify /var/scratch/portage/app-arch/tar-1.22/image/usr/sbin/restore-tar
Sat Aug 15 07:46:16 EDT 2009
--verify /var/scratch/portage/app-arch/tar-1.22/image/usr/sbin/dump-remind
Sat Aug 15 07:46:16 EDT 2009
--verify /var/scratch/portage/app-arch/tar-1.22/image/usr/sbin/rmt
Sat Aug 15 07:46:16 EDT 2009
--verify /var/scratch/portage/app-arch/tar-1.22/image/usr/sbin/backup.sh
[...]

So it appears that it *is* running it on its own.

[gentoo-user] Re: Xorg dropping keyboard events

[Moshe Kamensky]

* Stroller  [14/08/09 22:21]:
> 
> On 14 Aug 2009, at 21:26, Moshe Kamensky wrote:
> 
> > There was a thread with this subject a few months ago, which I have
> > deleted
> 
> LMGTHFY:
> http://www.google.com/search?ie=utf8&oe=utf8&q=Xorg%20dropping%20keyboard%20events
> 

Well, yes, that's where I found it, but there doesn't seem to be any 
solution there.



pgpiNrc4JKBhK.pgp
Description: PGP signature

Re: [gentoo-user] Re: Xorg dropping keyboard events

[Dale]

Moshe Kamensky wrote:
> * Stroller  [14/08/09 22:21]:
>   
>> On 14 Aug 2009, at 21:26, Moshe Kamensky wrote:
>>
>> 
>>> There was a thread with this subject a few months ago, which I have
>>> deleted
>>>   
>> LMGTHFY:
>> http://www.google.com/search?ie=utf8&oe=utf8&q=Xorg%20dropping%20keyboard%20events
>>
>> 
>
> Well, yes, that's where I found it, but there doesn't seem to be any 
> solution there.
>
>   

Have you tried emerging xorg-server with hal disabled?  That is assuming
you are using the 1.5 or 1.6 version.

Dale

:-)  :-) 

Re: [gentoo-user] Re: [OT] fast recursive local copy

[Dirk Heinrichs]

Am Freitag 14 August 2009 22:47:46 schrieb Joerg Schilling:
> Dirk Heinrichs  wrote:
> > Am Freitag 14 August 2009 10:50:45 schrieb Joerg Schilling:
> > > Note that on Linux you may need to add "-no-fsync" because file I/O is
> > > slow on Linux. On Solaris, not using -no-fsync slows things down by
> > > aprox. 10% but allows star to grant that everything was really copied
> > > to stable storage. On Linux, ot using -no-fsync slows things down by
> > > aprox. 400%, this is why I recommend to add "-no-fsync".
> >
> > This is also quite interesting. Do you have some (links to) recent
> > benchmarks which would second that? Could this even be depending on the
> > filesystem used on Linux?
>
> I did this test aprox. 3-4 years ago. You may try to do an own test and
> report.
>
> I did just rerun a test on a recent ubuntu in a VirtualBox environment and
> the speedup factor with -no-fsync was 8x.

OK, here's mine, then. Please note that the test happened on an encrypted 
logical volume containing an XFS filesystem. Source and destination directory 
are on the same LV.

# time star -copy -p -xdot -acl -sparse -C /gentoo/overlays/portage . 
/gentoo/build/portage
star: 0 blocks + 447532544 bytes (total of 447532544 bytes = 437043.50k).
star -copy -p -xdot -acl -sparse -C /gentoo/overlays/portage .   16,57s user 
60,22s system 11% cpu 11:23,63 total

# time star -copy -p -xdot -acl -sparse -no-fsync -C /gentoo/overlays/portage 
. /gentoo/build/portage
star: 0 blocks + 447532544 bytes (total of 447532544 bytes = 437043.50k).
star -copy -p -xdot -acl -sparse -no-fsync -C /gentoo/overlays/portage .   
12,33s user 35,39s system 10% cpu 7:44,13 total

Unfortunately, I can't compare with OSol :(

Bye...

Dirk


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: Gcc 4.3.4 ---> 4.4.1

[Alan McKinnon]

On Saturday 15 August 2009 02:33:56 fe...@crowfix.com wrote:
> This being 4.3.4 to 4.1.1 looks like a major version change according
> to the upgrade guide.  It doesn't mention what a switch manual takes,
> but it does list a whole series of steps such as remerging system and
> world without saying exactly when they or how much are necessary.  I'd
> just as soon not do that unless necessary, but I'd much more regret
> not doing it if I should have.

All you need to do for this gcc-config is select the new compiler for the 
system, but only if you choose to.

There are no other steps. If a system rebuild is necessary, the upgrade guide 
will say so in terms that make for no confusion, and the ebuild elog will say 
the same. They do not, so there is no need.

Look, the amount of confusion in gentoo-land about gcc upgrades defies belief. 
The upgrade guide explicitly says it is talking about going from a named 
version X to another named version Y, and somehow vast numbers of people morph 
this into somehow meaning that it must always be done. This is not true.

It only needs to be done when the compiler introduces ABI changes that make 
new object code incompatible with old object code that the new code intends to 
use. And it is always well-publicised when this happens (it couldn't be any 
other way, the dev's reputations depends on them doing exactly that.)

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Re: Gcc 4.3.4 ---> 4.4.1

[Mark Knecht]

On Sat, Aug 15, 2009 at 8:50 AM, Alan McKinnon wrote:
> On Saturday 15 August 2009 02:33:56 fe...@crowfix.com wrote:
>> This being 4.3.4 to 4.1.1 looks like a major version change according
>> to the upgrade guide.  It doesn't mention what a switch manual takes,
>> but it does list a whole series of steps such as remerging system and
>> world without saying exactly when they or how much are necessary.  I'd
>> just as soon not do that unless necessary, but I'd much more regret
>> not doing it if I should have.
>
> All you need to do for this gcc-config is select the new compiler for the
> system, but only if you choose to.
>
> There are no other steps. If a system rebuild is necessary, the upgrade guide
> will say so in terms that make for no confusion, and the ebuild elog will say
> the same. They do not, so there is no need.
>
> Look, the amount of confusion in gentoo-land about gcc upgrades defies belief.
> The upgrade guide explicitly says it is talking about going from a named
> version X to another named version Y, and somehow vast numbers of people morph
> this into somehow meaning that it must always be done. This is not true.
>
> It only needs to be done when the compiler introduces ABI changes that make
> new object code incompatible with old object code that the new code intends to
> use. And it is always well-publicised when this happens (it couldn't be any
> other way, the dev's reputations depends on them doing exactly that.)
>
> --
> alan dot mckinnon at gmail dot com
>
>
Alan,
   I agree with your description, but I disagree that the upgrade
guide is actually very clear about this. It has us upgrade the
compiler (OK), switch to the new compiler (OK), rebuild the libtool
stuff (OK) then then states:

http://www.gentoo.org/doc/en/gcc-upgrading.xml


To be completely safe that your system is in a sane state, you must
rebuild the toolchain and then world to make use of the new compiler.

Code Listing 2.2: Rebuilding system

# emerge -eav system
# emerge -eav world


   Who, reading this, wouldn't want to be safe and sane? I doesn't say
'might', 'could' or even 'should'. It says 'must'.

   I agree that in the case of 4.3 to 4.4 it *probably* isn't
necessary, but that isn't what the guide says. In fact, a bit earlier
on it specifically states that bug fix releases - 3.3.5 to 3.3.6 -
*should be* safe, implying to me that something bigger than a bug fix
(4.3 to 4.4?) might not be.

   Now, I'm not arguing with you in the least, but I think that if my
reading of the guide isn't correct in terms of simply understanding
what the words say then someone with the proper background needs to
work on the doc a bit.

- Mark

Re: [gentoo-user] Re: Gcc 4.3.4 ---> 4.4.1

[Mark Knecht]

On Fri, Aug 14, 2009 at 5:43 PM, Nikos Chantziaras wrote:
> On 08/15/2009 03:33 AM, fe...@crowfix.com wrote:
>>
>> [...]
>> This being 4.3.4 to 4.1.1 looks like a major version change according
>> to the upgrade guide.  It doesn't mention what a switch manual takes,
>> but it does list a whole series of steps such as remerging system and
>> world without saying exactly when they or how much are necessary.  I'd
>> just as soon not do that unless necessary, but I'd much more regret
>> not doing it if I should have.
>
> Switching the compiler with gcc-config is enough with this update. There are
> no ABI changes and packages built with GCC 4.3 will happily work together
> with the ones build with 4.4.
>
> I am doing an emerge -e system and emerge -e world anyway though since I
> want to take advantage of the faster code 4.4 produces in general, but also
> more specific whether or not the new "graphite" optimizer of GCC 4.4 (needs
> "graphite" USE flag enabled for gcc) will give additional performance gain.
>
> (If anyone is interested in that, you need to first add:
>
>  -floop-interchange -floop-strip-mine -floop-block
>
> to CFLAGS/CXXFLAGS (the options enabling the Graphite optimizer) and then
> "emerge -e" system and world.)
>

Are there any Gentoo upgrade instructions for these flags or did you
figure this out from other sources? If I was going to switch to 4.4
seems like I'd want to get as much performance as I could safely get.

I'm assuming that the list above is possibly not the complete list you
might have in make.conf???

Thanks,
Mark

[gentoo-user] Re: Gcc 4.3.4 ---> 4.4.1

[Nikos Chantziaras]

On 08/15/2009 07:42 PM, Mark Knecht wrote:

[...]
I agree with your description, but I disagree that the upgrade
guide is actually very clear about this. It has us upgrade the
compiler (OK), switch to the new compiler (OK), rebuild the libtool
stuff (OK) then then states:

http://www.gentoo.org/doc/en/gcc-upgrading.xml


To be completely safe that your system is in a sane state, you must
rebuild the toolchain and then world to make use of the new compiler.

Code Listing 2.2: Rebuilding system

# emerge -eav system
# emerge -eav world


Who, reading this, wouldn't want to be safe and sane? I doesn't say
'might', 'could' or even 'should'. It says 'must'.


No one knows.  The devs aren't magicians :P  For this specific update, 
there no problems *expected*.  But there's no guarantee.  If you want a 
guarantee, no one can give it to you other than yourself doing a rebuild 
of system&world.

[gentoo-user] Re: Gcc 4.3.4 ---> 4.4.1

[Nikos Chantziaras]

On 08/15/2009 07:48 PM, Mark Knecht wrote:

On Fri, Aug 14, 2009 at 5:43 PM, Nikos Chantziaras  wrote:

[...]
I am doing an emerge -e system and emerge -e world anyway though since I
want to take advantage of the faster code 4.4 produces in general, but also
more specific whether or not the new "graphite" optimizer of GCC 4.4 (needs
"graphite" USE flag enabled for gcc) will give additional performance gain.

(If anyone is interested in that, you need to first add:

  -floop-interchange -floop-strip-mine -floop-block

to CFLAGS/CXXFLAGS (the options enabling the Graphite optimizer) and then
"emerge -e" system and world.)


Are there any Gentoo upgrade instructions for these flags or did you
figure this out from other sources?


The upgrade instructions don't deal with CFLAGS.  The specific GCC flags 
are from GCC's documentation.  My CFLAGS were "-O2 -march=core2 -pipe" 
previously, and I just added to that the new GCC 4.4 graphite flags.




If I was going to switch to 4.4
seems like I'd want to get as much performance as I could safely get.


I'm afraid there's not enough testing on the graphite optimizer yet to 
tell if those flags are as safe as -O2.  In other words, you're on your own.




I'm assuming that the list above is possibly not the complete list you
might have in make.conf???


No, the complete list of CFLAGS/CXXFLAGS in my make.conf now is:

-march=core2 -O2 -floop-interchange -floop-strip-mine -floop-block -pipe

And that's it.  I was using very sane CFLAGS and I don't now if those 
three new "-floop" graphite flags count as "ricer CFLAGS" or not, since 
as I said previously, there's not enough testing yet :P

Re: [gentoo-user] Re: Gcc 4.3.4 ---> 4.4.1

[Dirk Heinrichs]

Am Samstag 15 August 2009 18:42:11 schrieb Mark Knecht:
> Code Listing 2.2: Rebuilding system
>
> # emerge -eav system
> # emerge -eav world

I still wonder about this one. Doesn't world include system, so that the above 
would result in rebuilding a vast amount of packages twice?

Bye...

Dirk


signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Re: Gcc 4.3.4 ---> 4.4.1

[7v5w7go9ub0o]

Nikos Chantziaras wrote:

On 08/15/2009 03:33 AM, fe...@crowfix.com wrote:
[...] This being 4.3.4 to 4.1.1 looks like a major version change 
according to the upgrade guide.  It doesn't mention what a switch 
manual takes, but it does list a whole series of steps such as 
remerging system and world without saying exactly when they or how 
much are necessary.  I'd just as soon not do that unless necessary,

 but I'd much more regret not doing it if I should have.


Switching the compiler with gcc-config is enough with this update. 
There are no ABI changes and packages built with GCC 4.3 will happily

 work together with the ones build with 4.4.

I am doing an emerge -e system and emerge -e world anyway though 
since I want to take advantage of the faster code 4.4 produces in 
general, but also more specific whether or not the new "graphite" 
optimizer of GCC 4.4 (needs "graphite" USE flag enabled for gcc) will

 give additional performance gain.

(If anyone is interested in that, you need to first add:

-floop-interchange -floop-strip-mine -floop-block

to CFLAGS/CXXFLAGS (the options enabling the Graphite optimizer) and 
then "emerge -e" system and world.)




Thanks for the information.


1. FWIW, I found the following note:

"To use this code transformation, GCC has to be configured with
--with-ppl and --with-cloog to enable the Graphite loop transformation
infrastructure."

on the following page:




2. Also FWIW, I found the following note:


* GCC can now emit code for protecting applications from
stack-smashing attacks. The protection is realized by buffer overflow
detection and reordering of stack variables to avoid pointer corruption.
* Some built-in functions have been fortified to protect them
against various buffer overflow (and format string) vulnerabilities.
Compared to the mudflap bounds checking feature, the safe builtins have
far smaller overhead. This means that programs built using safe builtins
should not experience any measurable slowdown.

on the following page: 

which suggests to me that the mudflap option should be disabled before
emerging world

HTH

Re: [gentoo-user] Re: Gcc 4.3.4 ---> 4.4.1

[Mark Knecht]

On Sat, Aug 15, 2009 at 9:49 AM, Nikos Chantziaras wrote:
> On 08/15/2009 07:42 PM, Mark Knecht wrote:
>>
>> [...]
>>    I agree with your description, but I disagree that the upgrade
>> guide is actually very clear about this. It has us upgrade the
>> compiler (OK), switch to the new compiler (OK), rebuild the libtool
>> stuff (OK) then then states:
>>
>> http://www.gentoo.org/doc/en/gcc-upgrading.xml
>>
>> 
>> To be completely safe that your system is in a sane state, you must
>> rebuild the toolchain and then world to make use of the new compiler.
>>
>> Code Listing 2.2: Rebuilding system
>>
>> # emerge -eav system
>> # emerge -eav world
>> 
>>
>>    Who, reading this, wouldn't want to be safe and sane? I doesn't say
>> 'might', 'could' or even 'should'. It says 'must'.
>
> No one knows.  The devs aren't magicians :P  For this specific update, there
> no problems *expected*.  But there's no guarantee.  If you want a guarantee,
> no one can give it to you other than yourself doing a rebuild of
> system&world.
>

Right, and hence why many people feel the need to rebuild system/world
EVERY time portage maintainers release ANY version of gcc. I simply
don't want to deal with the unknowns.

- Mark

Re: [gentoo-user] Re: Gcc 4.3.4 ---> 4.4.1

[Mark Knecht]

On Sat, Aug 15, 2009 at 10:06 AM, Dirk
Heinrichs wrote:
> Am Samstag 15 August 2009 18:42:11 schrieb Mark Knecht:
>> Code Listing 2.2: Rebuilding system
>>
>> # emerge -eav system
>> # emerge -eav world
>
> I still wonder about this one. Doesn't world include system, so that the above
> would result in rebuilding a vast amount of packages twice?
>
> Bye...
>
>        Dirk
>

In the dark ages (circa 1999/2000) it was actually suggested that we
could do even more:

emerge -eav @system
(gcc-config if required)
emerge -eav @system
emerge -eav @world

The first @system gets the new software on the system, but it's
unfortunately built with old compilers and linked to libraries built
with old compilers. gcc comes late in the upgrade usually.

The second @system rebuilds system again, but this time uses the new
compilers to get it really up to date.

The third one is a useless rebuild of @system but updates all of
@world. If there was a construct that looked like emerge
(@wor...@system) then I wouldn't rebuild the system stuff a 3rd time.

I do the above 3 steps when the major revision of gcc changes.

I've also done two builds of gcc instead of two @system builds. I
*think* that accomplishes the same thing, but what do I know as there
are no guarantees! ;-)

- Mark

Re: [gentoo-user] Re: Gcc 4.3.4 ---> 4.4.1

[Alan McKinnon]

On Saturday 15 August 2009 18:42:11 Mark Knecht wrote:
> Alan,
>I agree with your description, but I disagree that the upgrade
> guide is actually very clear about this. It has us upgrade the
> compiler (OK), switch to the new compiler (OK), rebuild the libtool
> stuff (OK) then then states:
>
> http://www.gentoo.org/doc/en/gcc-upgrading.xml
>
> 
> To be completely safe that your system is in a sane state, you must
> rebuild the toolchain and then world to make use of the new compiler.

And I disagree with you. The Gentoo docs are written in a style similar to 
RFCs, with very explicit meanings attached to words like SHOULD, MUST, MAY, 
CAN and others.

It is not the colloquial meaning, where these things pretty much all mean the 
same thing.

The document says "to be completely safe" - this does not mean that you will 
be unsafe it you don't do it, it simply means that it does in fact guarantee a 
form of safety if done. You cannot assume the negative must be true.

The later use of the word "must" does not apply to the general case (i.e. you 
must do it regardless), it depends on the prior "if" statement and should be 
read as "if you want to take advantage of this guarantee, do the following'

I do agree with you that the document should be reworded. Not because it's 
unclear, but because this topic comes up so often; and it almost always comes 
down to a lessened ability to read correct English - too many people have 
buggy language parses in their heads [I'm not accusing you of that :-) I'm 
speaking in general]

-- 
alan dot mckinnon at gmail dot com

[gentoo-user] Re: Gcc 4.3.4 ---> 4.4.1

[Nikos Chantziaras]

On 08/15/2009 08:06 PM, Dirk Heinrichs wrote:

Am Samstag 15 August 2009 18:42:11 schrieb Mark Knecht:

Code Listing 2.2: Rebuilding system

# emerge -eav system
# emerge -eav world


I still wonder about this one. Doesn't world include system, so that the above
would result in rebuilding a vast amount of packages twice?


system has to be rebuilt twice.  When you get a new toolchain 
("system"), you need to rebuilt it with itself.  The first time you do 
that, it is rebuilt using the *old* toolchain.  The second time it is 
rebuilt using the *new* toolchain that was just rebuilt.

Re: [gentoo-user] Re: Gcc 4.3.4 ---> 4.4.1

[Alan McKinnon]

On Saturday 15 August 2009 19:06:54 Dirk Heinrichs wrote:
> Am Samstag 15 August 2009 18:42:11 schrieb Mark Knecht:
> > Code Listing 2.2: Rebuilding system
> >
> > # emerge -eav system
> > # emerge -eav world
>
> I still wonder about this one. Doesn't world include system, so that the
> above would result in rebuilding a vast amount of packages twice?

The logic goes like this:

rebuilding system rebuilds (amongst other things) the entire toolchain. You 
then use that complete toolchain to rebuild itself in the second pass, along 
with everything else in world. The end effect is that you are 100% guaranteed 
that ever bit of code was built with the new compiler (taking advantage of any 
new features in that compiler).

A common misunderstanding is that you have to rebuild gcc twice. This is not 
true as gcc's own build system in fact builds gcc three times and does a 
binary diff between the last two, the build only proceeds if they are bit-for-
bit identical. So there is no need for portage to redo this as gcc already did 
it.

But the same cannot be said for everything else in the toolchain. So the above 
advice resolves down to it being the minimum necessary to absolutely guarantee 
consistency throughout the entire system. Anything less could possibly leave 
small gaps open.

In a way, building system then world, is exactly the same thing that binary 
distros do with a new release. They too can guarantee that the entire distro 
was built with the very compiler they ship.


-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Re: Gcc 4.3.4 ---> 4.4.1

[Alan McKinnon]

On Saturday 15 August 2009 19:18:36 Mark Knecht wrote:
> I've also done two builds of gcc instead of two @system builds. I
> think that accomplishes the same thing, but what do I know as there
> are no guarantees! ;-)

Look at gcc's makefiles. 

It builds gcc with the old compiler then uses that new compiler to rebuild the 
exact same source code twice. If, and only if, those two outputs are bitwise 
identical, then the last new compiler gets installed.

So your process is superfluous as you are duplicating work that gcc's build 
system has already done and guaranteed to be correct.

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Re: Gcc 4.3.4 ---> 4.4.1

[Dirk Heinrichs]

Am Samstag 15 August 2009 19:24:09 schrieb Nikos Chantziaras:

> system has to be rebuilt twice.  When you get a new toolchain
> ("system"), you need to rebuilt it with itself.  The first time you do
> that, it is rebuilt using the *old* toolchain.  The second time it is
> rebuilt using the *new* toolchain that was just rebuilt.

Why would I need to do that? If I install gcc 4.4.1 I have gcc 4.4.1. It will 
produce the same code no matter with what toolchain it has been built. So just 
rebuilding world should be sufficient.

Bye...

Dirk


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: Gcc 4.3.4 ---> 4.4.1

[Dirk Heinrichs]

Am Samstag 15 August 2009 19:25:39 schrieb Alan McKinnon:

> A common misunderstanding is that you have to rebuild gcc twice. This is
> not true as gcc's own build system in fact builds gcc three times and does
> a binary diff between the last two, the build only proceeds if they are
> bit-for- bit identical. So there is no need for portage to redo this as gcc
> already did it.

That's exactly my point.

Bye...

Dirk


signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Re: Gcc 4.3.4 ---> 4.4.1

[Nikos Chantziaras]

On 08/15/2009 08:07 PM, 7v5w7go9ub0o wrote:

[...]
1. FWIW, I found the following note:

"To use this code transformation, GCC has to be configured with
--with-ppl and --with-cloog to enable the Graphite loop transformation
infrastructure."

on the following page:




On Gentoo you just need to enable the "graphite" GCC USE flag.  This 
will pull-in ">=dev-libs/ppl-0.10" and ">=dev-libs/cloog-ppl-0.15". 
Also, "gcc -v" will show: "--with-ppl --with-cloog".




2. Also FWIW, I found the following note:

* GCC can now emit code for protecting applications from
stack-smashing attacks. The protection is realized by buffer overflow
detection and reordering of stack variables to avoid pointer corruption.
* Some built-in functions have been fortified to protect them
against various buffer overflow (and format string) vulnerabilities.
Compared to the mudflap bounds checking feature, the safe builtins have
far smaller overhead. This means that programs built using safe builtins
should not experience any measurable slowdown.

on the following page: 

which suggests to me that the mudflap option should be disabled before
emerging world


AFAIK, the mudflap pointer checker is just a command line GCC switch. 
You need to enable it explicitly using "-fmudflap".

[gentoo-user] Re: Gcc 4.3.4 ---> 4.4.1

[Nikos Chantziaras]

On 08/15/2009 08:37 PM, Dirk Heinrichs wrote:

Am Samstag 15 August 2009 19:24:09 schrieb Nikos Chantziaras:


system has to be rebuilt twice.  When you get a new toolchain
("system"), you need to rebuilt it with itself.  The first time you do
that, it is rebuilt using the *old* toolchain.  The second time it is
rebuilt using the *new* toolchain that was just rebuilt.


Why would I need to do that? If I install gcc 4.4.1 I have gcc 4.4.1. It will
produce the same code no matter with what toolchain it has been built. So just
rebuilding world should be sufficient.


"Should."  But not "must."



Bye...


Uhm, nice day.

[gentoo-user] netkit-rsh ./configure problem

[Albert Hopkins]

I can't get netkit-rsh (not that I want it but it's an (indirect)
runtime dependency of xinit).  This is a brand new machine that I'm
building.

Basically the error is:

Checking for BSD signal semantics... no
This package needs BSD signal semantics to run.
sed: can't read MCONFIG: No such file or directory


Upon inspection of the ./configure script, I see it is compiling and
running the following snippet:

#include 
#include 
int count=0;
void handle(int foo) { count++; }
int main() {
int pid=getpid();
signal(SIGINT, handle);
kill(pid,SIGINT);
kill(pid,SIGINT);
kill(pid,SIGINT);
if (count!=3) return 1;
return 0;
}

If I compile this on the target machine, it exits with 1. I checked and
count=0.  If I compile this on another machine it exits with 0.  Even
when I take the compiled exe from the other machine and copy it to the
target machine it exits 1.

This is disturbing.

Any ideas?

2.6.30-gentoo-r5
sys-devel/gcc-4.4.1
sys-libs/glibc-2.10.1
sys-kernel/linux-headers-2.6.30-r1

Re: [gentoo-user] netkit-rsh ./configure problem

[Albert Hopkins]

I should also mention that I also can't, for example, press CTRL-C at
the shell prompt to exit a program (such as emerge).  So somehow (some)
signals are not being sent/received.

-a

[gentoo-user] Re: Gcc 4.3.4 ---> 4.4.1

[7v5w7go9ub0o]

Nikos Chantziaras wrote:



AFAIK, the mudflap pointer checker is just a command line GCC switch.
 You need to enable it explicitly using "-fmudflap".



ah o.k.   I'm using the hardened overlay, and mudflap is a use flag
defaulting to enabled. I'll post that second comment over in hardened.

I'd guess that most here would appreciate it if you post your
impressions about graphite.

[gentoo-user] Re: Gcc 4.3.4 ---> 4.4.1

[Nikos Chantziaras]

On 08/15/2009 09:35 PM, 7v5w7go9ub0o wrote:

Nikos Chantziaras wrote:



AFAIK, the mudflap pointer checker is just a command line GCC switch.
You need to enable it explicitly using "-fmudflap".



ah o.k. I'm using the hardened overlay, and mudflap is a use flag
defaulting to enabled. I'll post that second comment over in hardened.


I'm not on hardened, but mudflap is enabled by default here too.  What I 
don't know is whether hardened has "-fmudflap" enabled by default. 
Perhaps someone who knows more about this feature can shed some light on 
how this works exactly.




I'd guess that most here would appreciate it if you post your
impressions about graphite.


Overall system performance seems unchanged.  I would need to actually 
benchmark it.  I didn't do it yet, but you could emerge stuff like gzip, 
bzip2, oggdec (and other stuff that is easy to benchmark) with 4.4.1, 
run them on in-memory files (that means in /dev/shm) and time them (with 
the 'time' command) to see how big a gain there is.  For example:


  time bzip2 --best /dev/shm/500gb-test-file

[gentoo-user] Re: Gcc 4.3.4 ---> 4.4.1

[Nikos Chantziaras]

On 08/15/2009 09:52 PM, Nikos Chantziaras wrote:

[...]
time bzip2 --best /dev/shm/500gb-test-file


More like "500mb-test-file" as I don't suppose you have a terrabyte of 
RAM :P

Re: [gentoo-user] netkit-rsh ./configure problem

[Andrey Falko]

On Sat, Aug 15, 2009 at 11:23 AM, Albert Hopkins wrote:

> I should also mention that I also can't, for example, press CTRL-C at
> the shell prompt to exit a program (such as emerge).  So somehow (some)
> signals are not being sent/received.
>
> -a
>
>
>
>
It looks like you sys-process/procps might be broke in some way. Try:

emerge -1 sys-process/procps

Re: [gentoo-user] netkit-rsh ./configure problem

[Albert Hopkins]

On Sat, 2009-08-15 at 12:08 -0700, Andrey Falko wrote:
> On Sat, Aug 15, 2009 at 11:23 AM, Albert Hopkins
>  wrote:
> I should also mention that I also can't, for example, press
> CTRL-C at
> the shell prompt to exit a program (such as emerge).  So
> somehow (some)
> signals are not being sent/received.
> 
> -a
> 
> 
> 
> 
> It looks like you sys-process/procps might be broke in some way. Try: 

Thanks for the suggestion but, unfortunately, no dice.  For some reason
I think this has something to do with the kernel or glibc (or some
combo).  I should mention also that I used (for the first time) the
minimal snapshot (which I guess is the only one supported) and also the
stage3 snapshot and also this is ~amd64.

 I may just try to do an 'emerge -e world' and see what happens.

-a

[gentoo-user] Re: netkit-rsh ./configure problem

[Nikos Chantziaras]

On 08/15/2009 10:22 PM, Albert Hopkins wrote:

Thanks for the suggestion but, unfortunately, no dice.  For some reason
I think this has something to do with the kernel or glibc (or some
combo).  I should mention also that I used (for the first time) the
minimal snapshot (which I guess is the only one supported) and also the
stage3 snapshot and also this is ~amd64.

  I may just try to do an 'emerge -e world' and see what happens.


If 'emerge -e system' won't fix it, I doubt 'emerge -e world' will. 
Perhaps it's some configuration (/etc) issue.

Re: [gentoo-user] Re: netkit-rsh ./configure problem

[Albert Hopkins]

On Sat, 2009-08-15 at 22:29 +0300, Nikos Chantziaras wrote:
> On 08/15/2009 10:22 PM, Albert Hopkins wrote:
> > Thanks for the suggestion but, unfortunately, no dice.  For some reason
> > I think this has something to do with the kernel or glibc (or some
> > combo).  I should mention also that I used (for the first time) the
> > minimal snapshot (which I guess is the only one supported) and also the
> > stage3 snapshot and also this is ~amd64.
> >
> >   I may just try to do an 'emerge -e world' and see what happens.
> 
> If 'emerge -e system' won't fix it, I doubt 'emerge -e world' will. 
> Perhaps it's some configuration (/etc) issue.

Hmmm.. I don't think people are seeing the original post in this thread.
I can hardly see how that's a problem with config files.

I haven't done an 'emerge -e system' so I don't know that won't fix it.

The problem is processes seem not to receive SIGINT.  The C code snippet
from the original post doesn't work.  CTRL-C within bash doesn't work.
'kill ' doesn't work (kill -9  does).  AFAIK there is no
config file in /etc that makes the entire OS ignore SIGINT.

-a

Re: [gentoo-user] netkit-rsh ./configure problem

[pk]

Albert Hopkins wrote:
> I can't get netkit-rsh (not that I want it but it's an (indirect)
> runtime dependency of xinit).  This is a brand new machine that I'm
> building.
> 
> Basically the error is:
> 
> Checking for BSD signal semantics... no
> This package needs BSD signal semantics to run.
> sed: can't read MCONFIG: No such file or directory

Hm. I may be way off here but do you have CONFIG_BSD_PROCESS_ACCT=y in
your kernel .config?

Best regards

Peter K

Re: [gentoo-user] netkit-rsh ./configure problem

[Albert Hopkins]

On Sat, 2009-08-15 at 21:38 +0200, pk wrote:
> Albert Hopkins wrote:
> > I can't get netkit-rsh (not that I want it but it's an (indirect)
> > runtime dependency of xinit).  This is a brand new machine that I'm
> > building.
> > 
> > Basically the error is:
> > 
> > Checking for BSD signal semantics... no
> > This package needs BSD signal semantics to run.
> > sed: can't read MCONFIG: No such file or directory
> 
> Hm. I may be way off here but do you have CONFIG_BSD_PROCESS_ACCT=y in
> your kernel .config?

Cheers.  That was it.  For some reason I glossed over that thinking it
only had to do with sar but I guess not.

Thanks again,
-a

Re: [gentoo-user] netkit-rsh ./configure problem

[Albert Hopkins]

On Sat, 2009-08-15 at 15:50 -0400, Albert Hopkins wrote:
> On Sat, 2009-08-15 at 21:38 +0200, pk wrote:
> > Albert Hopkins wrote:
> > > I can't get netkit-rsh (not that I want it but it's an (indirect)
> > > runtime dependency of xinit).  This is a brand new machine that I'm
> > > building.
> > > 
> > > Basically the error is:
> > > 
> > > Checking for BSD signal semantics... no
> > > This package needs BSD signal semantics to run.
> > > sed: can't read MCONFIG: No such file or directory
> > 
> > Hm. I may be way off here but do you have CONFIG_BSD_PROCESS_ACCT=y in
> > your kernel .config?
> 
> Cheers.  That was it.  For some reason I glossed over that thinking it
> only had to do with sar but I guess not.

Maybe I spoke too soon... Either I was on the wrong system when I tested
or there's some inconsistency.  Nevertheless the problem doesn't appear
fixed :(

Re: [gentoo-user] Re: [OT] fast recursive local copy

[Volker Armin Hemmann]

On Samstag 15 August 2009, Dirk Heinrichs wrote:
> Am Freitag 14 August 2009 22:47:46 schrieb Joerg Schilling:
> > Dirk Heinrichs  wrote:
> > > Am Freitag 14 August 2009 10:50:45 schrieb Joerg Schilling:
> > > > Note that on Linux you may need to add "-no-fsync" because file I/O
> > > > is slow on Linux. On Solaris, not using -no-fsync slows things down
> > > > by aprox. 10% but allows star to grant that everything was really
> > > > copied to stable storage. On Linux, ot using -no-fsync slows things
> > > > down by aprox. 400%, this is why I recommend to add "-no-fsync".
> > >
> > > This is also quite interesting. Do you have some (links to) recent
> > > benchmarks which would second that? Could this even be depending on the
> > > filesystem used on Linux?
> >
> > I did this test aprox. 3-4 years ago. You may try to do an own test and
> > report.
> >
> > I did just rerun a test on a recent ubuntu in a VirtualBox environment
> > and the speedup factor with -no-fsync was 8x.
>
> OK, here's mine, then. Please note that the test happened on an encrypted
> logical volume containing an XFS filesystem. Source and destination
> directory are on the same LV.
>
> # time star -copy -p -xdot -acl -sparse -C /gentoo/overlays/portage .
> /gentoo/build/portage
> star: 0 blocks + 447532544 bytes (total of 447532544 bytes = 437043.50k).
> star -copy -p -xdot -acl -sparse -C /gentoo/overlays/portage .   16,57s
> user 60,22s system 11% cpu 11:23,63 total
>
> # time star -copy -p -xdot -acl -sparse -no-fsync -C
> /gentoo/overlays/portage . /gentoo/build/portage
> star: 0 blocks + 447532544 bytes (total of 447532544 bytes = 437043.50k).
> star -copy -p -xdot -acl -sparse -no-fsync -C /gentoo/overlays/portage .
> 12,33s user 35,39s system 10% cpu 7:44,13 total
>
> Unfortunately, I can't compare with OSol :(
>
> Bye...
>
>   Dirk

and you dropped caches in between?

Re: [gentoo-user] Re: [OT] fast recursive local copy

[Volker Armin Hemmann]

On Freitag 14 August 2009, Joerg Schilling wrote:
> Dirk Heinrichs  wrote:
> > Am Freitag 14 August 2009 10:50:45 schrieb Joerg Schilling:
> > > Note that on Linux you may need to add "-no-fsync" because file I/O is
> > > slow on Linux. On Solaris, not using -no-fsync slows things down by
> > > aprox. 10% but allows star to grant that everything was really copied
> > > to stable storage. On Linux, ot using -no-fsync slows things down by
> > > aprox. 400%, this is why I recommend to add "-no-fsync".
> >
> > This is also quite interesting. Do you have some (links to) recent
> > benchmarks which would second that? Could this even be depending on the
> > filesystem used on Linux?
>
> I did this test aprox. 3-4 years ago. You may try to do an own test and
> report.
>
> I did just rerun a test on a recent ubuntu in a VirtualBox environment and
> the speedup factor with -no-fsync was 8x.
>
> Jörg

reiser4 on raid5, compression is on, since no barriers, sync mode. Three runs, 
first without, second with, third without -no-fsync. echo 1 > 
/proc/sys/vm/drop_caches in between each run. temp was removed and recreated 
between each run. source and target on different md devices.

star: 0 blocks + 96006656 bytes (total of 96006656 bytes = 93756.50k).  
   
star -copy -p -xdot -acl -sparse -C /usr/local/portage . temp/  0,85s user 
16,79s system 6% cpu 4:48,77 total 

star: 0 blocks + 96006656 bytes (total of 96006656 bytes = 93756.50k).
star -copy -p -xdot -acl -sparse -no-fsync -C /usr/local/portage . temp/  
0,43s user 3,14s system 24% cpu 14,389 total


star: 0 blocks + 96006656 bytes (total of 96006656 bytes = 93756.50k).
star -copy -p -xdot -acl -sparse -C /usr/local/portage . temp/  0,88s user 
15,93s system 6% cpu 4:13,76 total
  
but reiser4 is infamous for not loving fsync ;)

[gentoo-user] Re: Xorg dropping keyboard events

[Moshe Kamensky]

* Dale  [15/08/09 09:30]:
> 
> Have you tried emerging xorg-server with hal disabled?  That is assuming
> you are using the 1.5 or 1.6 version.
> 

I'll try that, thanks.



pgpLl0FkYmJuE.pgp
Description: PGP signature

Re: [gentoo-user] netkit-rsh ./configure problem

[Andrey Falko]

On Sat, Aug 15, 2009 at 1:23 PM, Albert Hopkins wrote:

> On Sat, 2009-08-15 at 15:50 -0400, Albert Hopkins wrote:
> > On Sat, 2009-08-15 at 21:38 +0200, pk wrote:
> > > Albert Hopkins wrote:
> > > > I can't get netkit-rsh (not that I want it but it's an (indirect)
> > > > runtime dependency of xinit).  This is a brand new machine that I'm
> > > > building.
> > > >
> > > > Basically the error is:
> > > >
> > > > Checking for BSD signal semantics... no
> > > > This package needs BSD signal semantics to run.
> > > > sed: can't read MCONFIG: No such file or directory
> > >
> > > Hm. I may be way off here but do you have CONFIG_BSD_PROCESS_ACCT=y in
> > > your kernel .config?
> >
> > Cheers.  That was it.  For some reason I glossed over that thinking it
> > only had to do with sar but I guess not.
>
> Maybe I spoke too soon... Either I was on the wrong system when I tested
> or there's some inconsistency.  Nevertheless the problem doesn't appear
> fixed :(
>
>
Have you done an update to this system where glibc might have been upgraded
but not gcc or vice versa? Have you updated any system packages in general
on the system? As was mentioned earlier an emerge -e system might solve the
problem. If not, then we'll know that it's not a problem with one of the
system packages.

[gentoo-user] When will the ~ go from Firefox 3.0.12?

[Konstantinos Agouros]

Hi,

normally gentoo was quick with security updates for Firefox but it is
almost a month now since 3.0.12 and still the ~ is attached. What's
going on there?

Konstantin
-- 
Dipl-Inf. Konstantin Agouros aka Elwood Blues. Internet: elw...@agouros.de
Otkerstr. 28, 81547 Muenchen, Germany. Tel +49 89 69370185

"Captain, this ship will not survive the forming of the cosmos." B'Elana Torres

[gentoo-user] ISDN4k Utils masekd

[Konstantinos Agouros]

Hi,

is there an alternative? I need ISDN in at least one machine.

Regards,

Konstantin
-- 
Dipl-Inf. Konstantin Agouros aka Elwood Blues. Internet: elw...@agouros.de
Otkerstr. 28, 81547 Muenchen, Germany. Tel +49 89 69370185

"Captain, this ship will not survive the forming of the cosmos." B'Elana Torres