https://bugzilla.redhat.com/show_bug.cgi?id=1194167
Basically everything in Rawhide which uses the normal RPM
opt flags will now have to be compiled with -fPIC, otherwise
you get errors like:
/usr/bin/ld: /tmp/ccqyK5ia.o: relocation R_X86_64_32S against `virConnectOpen'
can not be used when mak
On Thu, Feb 19, 2015 at 09:14:32AM +, Richard W.M. Jones wrote:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1194167
>
> Basically everything in Rawhide which uses the normal RPM
> opt flags will now have to be compiled with -fPIC, otherwise
> you get errors like:
>
> /usr/bin/ld: /tmp/cc
On Thu, Feb 19, 2015 at 10:22:03AM +0100, Jakub Jelinek wrote:
> On Thu, Feb 19, 2015 at 09:14:32AM +, Richard W.M. Jones wrote:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1194167
> >
> > Basically everything in Rawhide which uses the normal RPM
> > opt flags will now have to be comp
And in another case I had (qemu), it's not predictable. If you just
compile part of qemu twice, the first time it gives the error and the
second time not.
I had to add this hack to qemu.spec:
http://pkgs.fedoraproject.org/cgit/qemu.git/commit/?id=6c3741c2769a21542a34716fa9188e520887a803
Rich.
On Thu, Feb 19, 2015 at 09:37:16AM +, Richard W.M. Jones wrote:
> The thing is, I'm not adding -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> explicitly in the real program. It's being added to everything by
> something in RPM. I'm not exactly sure what, maybe %{configure}?
>
> So I don't k
On Thu, Feb 19, 2015 at 10:42:02AM +0100, Jakub Jelinek wrote:
> On Thu, Feb 19, 2015 at 09:37:16AM +, Richard W.M. Jones wrote:
> > The thing is, I'm not adding -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> > explicitly in the real program. It's being added to everything by
> > something in
On Thu, Feb 19, 2015 at 09:51:33AM +, Richard W.M. Jones wrote:
> There is definitely new/different behaviour in Rawhide, and recently.
>
> Also I was only able to see the new behaviour by updating from gcc 4.x
> -> gcc 5. ie. Updating redhat-rpm-config isn't what causes the
> problem.
Well,
I'm still no closer to being able to fix the problem.
I have to add -fPIE (or is that -pie or -fpie or -DPIE) to every
executable? Upstream? Will that break on some platforms/architectures?
And indeed what is the difference between -fPIE / -pie / -fpie /
-fPIC / -fpic / -DPIC / etc? Where is
On Thu, Feb 19, 2015 at 10:11:07AM +, Richard W.M. Jones wrote:
>
> I'm still no closer to being able to fix the problem.
>
> I have to add -fPIE (or is that -pie or -fpie or -DPIE) to every
> executable? Upstream? Will that break on some platforms/architectures?
It really should be just a
On Thu, Feb 19, 2015 at 11:23:18AM +0100, Jakub Jelinek wrote:
> On Thu, Feb 19, 2015 at 10:11:07AM +, Richard W.M. Jones wrote:
> >
> > I'm still no closer to being able to fix the problem.
> >
> > I have to add -fPIE (or is that -pie or -fpie or -DPIE) to every
> > executable? Upstream? W
On Thu, Feb 19, 2015 at 10:30:50AM +, Richard W.M. Jones wrote:
> info gcc, of course yes. -DPIC is not documented at all, and the
> various pie/pic options are obscure to say the least.
Why should -DPIC be documented? -D is documented. -DPIC means define
macro PIC to 1. There is no magic
On Thu, Feb 19, 2015 at 11:35:17AM +0100, Jakub Jelinek wrote:
> On Thu, Feb 19, 2015 at 10:30:50AM +, Richard W.M. Jones wrote:
> > info gcc, of course yes. -DPIC is not documented at all, and the
> > various pie/pic options are obscure to say the least.
>
> Why should -DPIC be documented?
On Thu, Feb 19, 2015 at 10:37:46AM +, Richard W.M. Jones wrote:
> On Thu, Feb 19, 2015 at 11:35:17AM +0100, Jakub Jelinek wrote:
> > On Thu, Feb 19, 2015 at 10:30:50AM +, Richard W.M. Jones wrote:
> > > info gcc, of course yes. -DPIC is not documented at all, and the
> > > various pie/pic
On Thu, Feb 19, 2015 at 10:37:46AM +, Richard W.M. Jones wrote:
> On Thu, Feb 19, 2015 at 11:35:17AM +0100, Jakub Jelinek wrote:
> > On Thu, Feb 19, 2015 at 10:30:50AM +, Richard W.M. Jones wrote:
> > > info gcc, of course yes. -DPIC is not documented at all, and the
> > > various pie/pic
On Thu, Feb 19, 2015 at 11:45:01AM +0100, Jakub Jelinek wrote:
> On Thu, Feb 19, 2015 at 10:37:46AM +, Richard W.M. Jones wrote:
> > On Thu, Feb 19, 2015 at 11:35:17AM +0100, Jakub Jelinek wrote:
> > > On Thu, Feb 19, 2015 at 10:30:50AM +, Richard W.M. Jones wrote:
> > > > info gcc, of cour
On 02/18/2015 01:21 PM, adamw...@fedoraproject.org wrote:
https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150218_Installation
Text-mode installation does not work - noted in the matrix.
The installation source spoke does not work. No matter what I choose, even
specifying a r
Hi,
a list of things that usually break with each new gcc (like fortran
modules) would be nice to avoid a lot of pain with debugging. Does it
already exist?
WxGTK keeps a string WX_BUILD_OPTIONS_SIGNATURE currently saying "2.8
(no debug,Unicode,compiler with C++ ABI 1002,wx containers,compat
On Thu, Feb 19, 2015 at 04:12:43PM +0100, Frantisek Kluknavsky wrote:
> a list of things that usually break with each new gcc (like fortran modules)
> would be nice to avoid a lot of pain with debugging. Does it already exist?
>
> WxGTK keeps a string WX_BUILD_OPTIONS_SIGNATURE currently saying "2
On Wed, Feb 18, 2015 at 8:36 AM, Paul Howarth wrote:
> On 18/02/15 15:12, Dave Johansen wrote:
>
>> I'm running into an issue where odb won't build on rawhide (
>> http://koji.fedoraproject.org/koji/taskinfo?taskID=8966447 ) and I need
>> to be able to take a look at the config.log file but it's
On Wed, Feb 18, 2015 at 9:54 AM, Marcin Juszkiewicz wrote:
> On 18.02.2015 16:31, Miroslav Suchý wrote:
> > On 02/18/2015 04:12 PM, Dave Johansen wrote:
> >> I'm running into an issue where odb won't build on rawhide (
> http://koji.fedoraproject.org/koji/taskinfo?taskID=8966447
> >> ) and I need
On Wed, 18 Feb 2015 22:24:47 -0800, Adam Williamson wrote:
> Today's - 2015-02-18 - F22 nightlies seem not to have any anaconda
> showstoppers, so for now probably using one of them is the best way to
> install F22.
Thanks! Fetched it.
Also the -02-18 one for Rawhide x86_64 Live Workstation, w
On Thu, Feb 19, 2015 at 10:42:02AM +0100, Jakub Jelinek wrote:
> On Thu, Feb 19, 2015 at 09:37:16AM +, Richard W.M. Jones wrote:
> > The thing is, I'm not adding -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> > explicitly in the real program. It's being added to everything by
> > something in
On Thu, Feb 19, 2015 at 06:00:41PM +0100, Till Maas wrote:
> On Thu, Feb 19, 2015 at 10:42:02AM +0100, Jakub Jelinek wrote:
> > On Thu, Feb 19, 2015 at 09:37:16AM +, Richard W.M. Jones wrote:
> > > The thing is, I'm not adding -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> > > explicitly in th
On Thu, 2015-02-19 at 18:05 +0100, Jakub Jelinek wrote:
> On Thu, Feb 19, 2015 at 06:00:41PM +0100, Till Maas wrote:
> > I plan to change this to 1 now in Rawhide for the upcoming Fedora 23
> > feature:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1192183
> >
> > Since I did not get any feedbac
On Thu, Feb 19, 2015 at 01:02:29PM -0500, Adam Jackson wrote:
> On Thu, 2015-02-19 at 18:05 +0100, Jakub Jelinek wrote:
> > On Thu, Feb 19, 2015 at 06:00:41PM +0100, Till Maas wrote:
> > > I plan to change this to 1 now in Rawhide for the upcoming Fedora 23
> > > feature:
> > > https://bugzilla.red
==
#fedora-meeting-2: Env and Stacks (2015-02-19)
==
Meeting started by hhorak at 18:02:53 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-2/2015-02-19/env-and-stacks.2015-
On Thu, Feb 19, 2015 at 07:07:45PM +0100, Jakub Jelinek wrote:
> Even on x86_64 it was quite a measurable slowdown last time I've benchmarked
> it, now in F22+ we might have smaller slowdown with the x86_64 copyreloc for
Which packages are there that do not process untrusted data and are
slowed d
Hi,
I were trying to compile f22 mongoDB package with enabled
_hardened_build . And it always failed with:
collect2: fatal error: ld terminated with signal 9 [Killed]
compilation terminated.
scons: *** [build/linux2/ssl/use-system-all/usev8/mongo/mongod] Error 1
scons: building terminated because
Am 19.02.2015 um 19:48 schrieb Till Maas:
On Thu, Feb 19, 2015 at 07:07:45PM +0100, Jakub Jelinek wrote:
Even on x86_64 it was quite a measurable slowdown last time I've benchmarked
it, now in F22+ we might have smaller slowdown with the x86_64 copyreloc for
Which packages are there that do
On Thu, Feb 19, 2015 at 07:48:30PM +0100, Till Maas wrote:
> On Thu, Feb 19, 2015 at 07:07:45PM +0100, Jakub Jelinek wrote:
>
> > Even on x86_64 it was quite a measurable slowdown last time I've benchmarked
> > it, now in F22+ we might have smaller slowdown with the x86_64 copyreloc for
>
> Which
On Thu, 19 Feb 2015 19:51:38 +0100
Marek Skalický wrote:
> Hi,
> I were trying to compile f22 mongoDB package with enabled
> _hardened_build . And it always failed with:
>
> collect2: fatal error: ld terminated with signal 9 [Killed]
> compilation terminated.
> scons: *** [build/linux2/ssl/use-s
On Thu, Feb 19, 2015 at 07:58:10PM +0100, Reindl Harald wrote:
>
> Am 19.02.2015 um 19:48 schrieb Till Maas:
> >On Thu, Feb 19, 2015 at 07:07:45PM +0100, Jakub Jelinek wrote:
> >
> >>Even on x86_64 it was quite a measurable slowdown last time I've benchmarked
> >>it, now in F22+ we might have smal
Am 19.02.2015 um 20:15 schrieb Jakub Jelinek:
On Thu, Feb 19, 2015 at 07:58:10PM +0100, Reindl Harald wrote:
Am 19.02.2015 um 19:48 schrieb Till Maas:
On Thu, Feb 19, 2015 at 07:07:45PM +0100, Jakub Jelinek wrote:
Even on x86_64 it was quite a measurable slowdown last time I've benchmarked
i
On Thu, Feb 19, 2015 at 08:15:19PM +0100, Jakub Jelinek wrote:
> I've never argumented against the goal that web browser or all network aware
> services should be PIEs, after all, why would we (Ulrich Drepper and myself)
> add the PIE support into the toolchain otherwise?
> I'm just not convinced
On Thu, Feb 19, 2015 at 12:34 PM, Till Maas wrote:
> On Thu, Feb 19, 2015 at 08:15:19PM +0100, Jakub Jelinek wrote:
>
> > I've never argumented against the goal that web browser or all network
> aware
> > services should be PIEs, after all, why would we (Ulrich Drepper and
> myself)
> > add the P
I have just updated libuv in F22 and rawhide to the 1.x series (1.4.0
to be exact) which introduces a proper soname upstream that is bumped
from the previous Fedora package.
libuv currently only has two dependencies in Fedora. One dependent,
moarvm, has already been rebuilt. The other, nodejs, w
I'd like to know the performance loss estimated/examined by FESCO, or
I think it's a bad idea on i686 systems, it's already slow enough.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-
On Thu, 2015-02-19 at 08:38 -0600, Michael Cronenworth wrote:
> On 02/18/2015 01:21 PM, adamw...@fedoraproject.org wrote:
> >
> > https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150218_Installation
> >
>
> Text-mode installation does not work - noted in the matrix.
Thanks!
Fai
Dan Horák píše v Čt 19. 02. 2015 v 20:12 +0100:
> On Thu, 19 Feb 2015 19:51:38 +0100
> Marek Skalický wrote:
>
> > Hi,
> > I were trying to compile f22 mongoDB package with enabled
> > _hardened_build . And it always failed with:
> >
> > collect2: fatal error: ld terminated with signal 9 [Killed
39 matches
Mail list logo