Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 134577 - kdehiddenvisibility USE flag alters make.conf CFLAGS (2.1_rc2-r3)
Summary: kdehiddenvisibility USE flag alters make.conf CFLAGS (2.1_rc2-r3)
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: AMD64 Linux
: High normal (vote)
Assignee: Diego Elio Pettenò (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-27 18:20 UTC by Thomas S. Howard
Modified: 2006-05-28 21:22 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas S. Howard 2006-05-27 18:20:56 UTC
After using this flag to re-emerge kde, "-fvisibility=hidden" was added to the CFLAGS in make.conf. This is not good (though it worked quite well with kde).
Comment 1 Alec Warner (RETIRED) archtester gentoo-dev Security 2006-05-27 18:28:16 UTC
This could be misread, I'm correct in assuming that make.conf was not modified, but only the CFLAGS for anything that inherits from kde eclass, in which case this is a KDE bug.

If I'm wrong, it is still probably a kde bug :P
Comment 2 Thomas S. Howard 2006-05-27 20:01:33 UTC
(In reply to comment #1)
> This could be misread, I'm correct in assuming that make.conf was not modified,
> but only the CFLAGS for anything that inherits from kde eclass, in which case
> this is a KDE bug.
> 
> If I'm wrong, it is still probably a kde bug :P
> 

No. make.conf was changed, so anything would have been compiled with -fvisibilty=hidden.  And how is a use flag not a portage issue?
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2006-05-27 22:34:22 UTC
Flameeyes - eh?
Comment 4 Jakub Moc (RETIRED) gentoo-dev 2006-05-28 01:57:43 UTC
(In reply to comment #2)
> No. make.conf was changed, so anything would have been compiled with
> -fvisibilty=hidden.  And how is a use flag not a portage issue?

Huh? Well, there's nothing in kde.eclass that would touch make.conf, this is completely bogus. 

If you are instead asking how the flag works, read 
http://farragut.flameeyes.is-a-geek.org/articles/2006/05/25/small-and-big-updates

There's no other way to enable -fvisibility for KDE stuff.

Closing, not a bug.


Comment 5 Thomas S. Howard 2006-05-28 16:28:42 UTC
(In reply to comment #4)
> (In reply to comment #2)
> > No. make.conf was changed, so anything would have been compiled with
> > -fvisibilty=hidden.  And how is a use flag not a portage issue?
> 
> Huh? Well, there's nothing in kde.eclass that would touch make.conf, this is
> completely bogus. 
> 
> If you are instead asking how the flag works, read 
> http://farragut.flameeyes.is-a-geek.org/articles/2006/05/25/small-and-big-updates
> 
> There's no other way to enable -fvisibility for KDE stuff.
> 
> Closing, not a bug.
> 
Let me be as clear as possible:

1. set kdehiddenvisibility
2. emerge -N world
3. emerge finished, CFLAGS contained -fvisibility=hidden, where before it did not. make.conf had been changed. I don't know how. I've tried to figure it out, and I realize that the kde.eclass doesn't alter make.conf. Admittedly, there are other possibilities:

a. I did it and forgot about it.

That would be no. I know that it breaks many a thing, and besides, I figured the use flag would handle it for me, that being the point of the use flag.

b. Someone else did it.

Well, no one else in the house would even know what -fvisibility=hidden means, much less know how to set it in make.conf. That leaves someone breaking in, either through the net, or doing some acutal breaking and entering while I wasn't in the room, and editing the file. Well, it's possible, but as a theory, it doesn't have much else to recommend it.

c. Something else did it and it just happened to, well, happen, right before or after setting kdehiddenvisibility.

Given that kdehiddenvisibility is related to the option -fvisibility=hidden, 
that said option was *not* in my CFLAGS when I edited make.conf to set the new use flag, and that it was in my CFLAGS after setting it and re-emerging my kde packages, it seemed reasonable to assume some sort of causal connection. I never claimed it made sense.

And yes, obviously, for kdehiddenvisibility to work, it needs to pass the hidden option to the compiler.  I understand that. What I don't understand is how and why that option suddenly appeared in my global CFLAGS.

That said, I won't alter the bug status, since it'd probably just be set back to what it is now anyway.
Comment 6 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-05-28 16:38:56 UTC
> 3. emerge finished, CFLAGS contained -fvisibility=hidden, where before it did
> not. make.conf had been changed. I don't know how. I've tried to figure it out,
> and I realize that the kde.eclass doesn't alter make.conf.
Nor any of the ebuild FWIW, and actually, it does not even alter CFLAGS variable.

> Given that kdehiddenvisibility is related to the option -fvisibility=hidden, 
> that said option was *not* in my CFLAGS when I edited make.conf to set the new
> use flag, and that it was in my CFLAGS after setting it and re-emerging my kde
> packages, it seemed reasonable to assume some sort of causal connection. I
> never claimed it made sense.
Okay just to make this clearer. KDE eclass does _not_ inject -fvisibility=hidden option in the CFLAGS variable at all, rather it filters it out. kdehiddenvisibility useflag enables a switch at ./configure that allows to *check* for the availability of -fvisibility=hidden, so the whole stuff is not even touched by portage.

You can use

grep -r --include 'C*FLAGS' fvisibility=hidden /var/db/pkg

to see if you ever had the flag enabled, KDE packages should result without the flag entirely.
Comment 7 Thomas S. Howard 2006-05-28 21:22:56 UTC
OK, my point was not that somehow you were wrong, but that something altered make.conf and it was reasonable, at the time I noticed it, to assume it had something to do with kdehiddenvisibility. That's why I said I would just leave the bug status as is: because it *is* invalid as far as kdehiddenvisibility is concerned. Unfortunately, this means I don't even have an incorrect explanation for why the file was changed.