On Tue, 2010-02-16 at 17:03 +0100, Enrico Scholz wrote:
> Gerd Hoffmann writes:
>
> > Well. Even pretty fundamental GNOME stuff like gtk2-devel is still
> > broken. Look here:
> >
> > [r...@localhost ~]# pkg-config --libs gtk+-2.0
> > -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -
Hi,
On Thu, Feb 18, 2010 at 4:26 AM, Kevin Kofler wrote:
> Parag N(पराग़) wrote:
>> Is it ok to backport changes to F-12 for fixed packages in F-13 for
>> this DSO feature?
>
> It's of course OK to apply those changes to all branches (they won't break
> anything for the older ld), but it doesn't
Parag N(पराग़) wrote:
> Is it ok to backport changes to F-12 for fixed packages in F-13 for
> this DSO feature?
It's of course OK to apply those changes to all branches (they won't break
anything for the older ld), but it doesn't make sense to push updates just
for those changes! Please only pus
On Wed, Feb 17, 2010 at 03:04:00AM -0800, Roland McGrath wrote:
> > Is it ok to backport changes to F-12 for fixed packages in F-13 for
> > this DSO feature?
>
> The changes to a package's linking lines that you make for this issue are
> cleaning up sloppy practice to what was always the right th
> Is it ok to backport changes to F-12 for fixed packages in F-13 for
> this DSO feature?
The changes to a package's linking lines that you make for this issue are
cleaning up sloppy practice to what was always the right thing to be doing.
So it should always be fine to do that in builds for earl
Hi,
On Tue, Feb 9, 2010 at 4:07 AM, Roland Grunberg wrote:
> This is just an update to let maintainers know that the changes to
> LD outlined here :
>
> https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking
>
> will be in fedora rawhide pretty soon.
>
> The details behind what this fe
> Sure? For the libpng case I have a build failure which looks like this
> isn't the case (bug 565047):
>
>
> /usr/bin/ld: /usr/lib/gcc/i686-redhat-linux/4.4.3/../../../libpng12.so:
> undefined reference to symbol 'crc32'
> /usr/bin/ld: note: 'crc32' is defined in DSO /lib/libz.so.1 so try
>
On Tue, Feb 16, 2010 at 05:03:24PM +0100, Enrico Scholz wrote:
> Gerd Hoffmann writes:
>
> > [r...@localhost ~]# pkg-config --libs gtk+-2.0
> > -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0
> > -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype
> > -lfont
Gerd Hoffmann writes:
> Well. Even pretty fundamental GNOME stuff like gtk2-devel is still
> broken. Look here:
>
> [r...@localhost ~]# pkg-config --libs gtk+-2.0
> -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0
> -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0
On 02/16/10 16:06, Jakub Jelinek wrote:
> On Tue, Feb 16, 2010 at 03:57:52PM +0100, Gerd Hoffmann wrote:
>> Well. Even pretty fundamental GNOME stuff like gtk2-devel is still
>> broken. Look here:
>>
>> [r...@localhost ~]# pkg-config --libs gtk+-2.0
>> -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1
On Tue, 2010-02-16 at 15:57 +0100, Gerd Hoffmann wrote:
> On 02/09/10 09:06, Richard Hughes wrote:
> > On 8 February 2010 22:46, Kevin Kofler wrote:
> >> As a result, you'll be causing dozens of FTBFS bugs just before the feature
> >> freeze. I think this is entirely the wrong time in the release
On Tue, Feb 16, 2010 at 03:57:52PM +0100, Gerd Hoffmann wrote:
> Well. Even pretty fundamental GNOME stuff like gtk2-devel is still
> broken. Look here:
>
> [r...@localhost ~]# pkg-config --libs gtk+-2.0
> -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0
> -lgdk_pixbuf-2
On 02/09/10 09:06, Richard Hughes wrote:
> On 8 February 2010 22:46, Kevin Kofler wrote:
>> As a result, you'll be causing dozens of FTBFS bugs just before the feature
>> freeze. I think this is entirely the wrong time in the release cycle to do
>> such a change, if it is done at all.
>
> I've bee
> But I'm asking about -pthread option (which is detect/use for this package).
-pthread is the same as -D_REENTRANT at the beginning (which is useless)
and -lpthread at the end. I don't recommend using it at all. Just use
-lpthread instead (at the end of the link line, like all other libraries).
Le 08/02/2010 23:37, Roland Grunberg a écrit :
> https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking
+ mysql++ should be fixed. now
http://koji.fedoraproject.org/koji/taskinfo?taskID=1981564
But I'm asking about -pthread option (which is detect/use for this package).
According to
On Thu, 2010-02-11 at 11:58 -0800, Roland McGrath wrote:
> > Note that _libraries_ generally do not have a problem building in a
> > --no-add-needed world. ELF does not require that all references in a
> > DSO be resolvable at ld time, and this linking change does not change
> > that. If your lib
> Note that _libraries_ generally do not have a problem building in a
> --no-add-needed world. ELF does not require that all references in a
> DSO be resolvable at ld time, and this linking change does not change
> that. If your library libfoo uses symbols from libbar but does not
> itself link a
Once upon a time, Kevin Kofler said:
> And this makes this ld (mis)feature particularly silly, ld now gratuitously
> errors on "undefined" symbols which would be found just fine at runtime.
No, it errors on undefined symbols that may or may not be found at
runtime. Why do you want binaries that
On 02/11/2010 07:17 AM, Adam Jackson wrote:
> If your library libfoo uses symbols from libbar but does not
> itself link against libbar, that's still legal (although probably
> impolite).
It is not really correct, it works only by accident in most cases. If
the library with is linked with is usi
Adam Jackson wrote:
> Also note that the runtime linker will still do recursive lookups. If
> you have a binary that did not link against some needed library, but one
> of its dependencies did link against it, the binary will still work.
And this makes this ld (mis)feature particularly silly, ld
On Thu, 2010-02-11 at 11:06 +0100, yersinia wrote:
> On Tue, Feb 9, 2010 at 3:38 PM, Adam Jackson wrote:
>
> --no-add-needed is quite different. Your binary a.out uses
> symbols from
> libfoo and libbar. libfoo is linked against libbar. But your
> link line
>
On Wed, 2010-02-10 at 10:34 -0800, Adam Williamson wrote:
> On Wed, 2010-02-10 at 20:42 +0900, Mamoru Tasaka wrote:
>
> > You should add "AC_CHECK_LIB(X11, XKeysymToString)" to configure.in,
> > for example.
>
> It's nicer to use pkg-config for libraries which provide .pc files,
> isn't it? X11 d
On Tue, Feb 9, 2010 at 3:38 PM, Adam Jackson wrote:
> On Tue, 2010-02-09 at 08:06 +, Richard Hughes wrote:
> > On 8 February 2010 22:46, Kevin Kofler wrote:
> > > As a result, you'll be causing dozens of FTBFS bugs just before the
> feature
> > > freeze. I think this is entirely the wrong ti
Ryan Rix wrote:
> On Wed 10 February 2010 7:00:42 pm Kevin Kofler wrote:
>> It's not in the interest of the GNU project (which GCC is supposed to be
>> a part of) to make it easy to compile code with other compilers!
>
> If that is the case it is extremely short sighted of them.
That was a state
On Wed 10 February 2010 7:00:42 pm Kevin Kofler wrote:
> It's not in the interest of the GNU project (which GCC is supposed to be a
> part of) to make it easy to compile code with other compilers!
If that is the case it is extremely short sighted of them.
--
Ryan Rix
== http://hackersramblings.
Björn Persson wrote:
> And what happens the day you need to compile that code with another
> compiler?
What compiler? A proprietary compiler? The BSD-style-licensed LLVM/clang
which any proprietary vendor can embrace&extend into a non-Free version?
It's not in the interest of the GNU project (wh
Kevin Kofler wrote:
> Jakub Jelinek wrote:
> > You are probably looking for bug compatibility, and that isn't something
> > GCC guarantees, definitely not between major versions.
>
> And that's one half of what I'm complaining about.
That sounds to me like you want the GCC team to keep their bugs
On 02/09/2010 05:40 PM, Charley Wang wrote:
> Also, packages that have failed to build under these new changes can
> be found here :
> https://fedoraproject.org/wiki/DSOLinkBugs
All of mine are fixed:
amanith:
Fixed in amanith-0.3-14.fc13
esperanza:
Fixed in esperanza-0.4.0-6.fc13
gbdfed:
Fixe
> Well, I'd say it's at least as important that the fix should be done in
> the appropriate place - the source code's configure step - and not
> wedged into the spec file. And then, of course, it should be sent
> upstream.
Absolutely!
Thanks,
Roland
--
devel mailing list
devel@lists.fedoraproje
On Wed, 2010-02-10 at 10:41 -0800, Roland McGrath wrote:
> > To answer the question, it works because the CFLAGS happen to be applied
> > to the linker command as well as the LDFLAGS. As Roland says, though,
> > adding it to CFLAGS is the wrongest fix, forcing it into LDFLAGS via the
> > spec file
> To answer the question, it works because the CFLAGS happen to be applied
> to the linker command as well as the LDFLAGS. As Roland says, though,
> adding it to CFLAGS is the wrongest fix, forcing it into LDFLAGS via the
> spec file is slightly less wrong, but having the upstream code add the
> fl
On Wed, 2010-02-10 at 10:20 -0800, Roland McGrath wrote:
> > Hi,
> > On Wed, Feb 10, 2010 at 12:51 AM, Roland McGrath wrote:
> > >> Replace
> > >> make CFLAGS="%{optflags} -X11" %{?_smp_mflags}
> > >> with
> > >> make CFLAGS="%{optflags}" LDFLAGS="-lX11" %{?_smp_mflags}
> > >
> > > This is sti
On Wed, 2010-02-10 at 20:42 +0900, Mamoru Tasaka wrote:
> You should add "AC_CHECK_LIB(X11, XKeysymToString)" to configure.in,
> for example.
It's nicer to use pkg-config for libraries which provide .pc files,
isn't it? X11 does:
/usr/lib64/pkgconfig/x11.pc
--
Adam Williamson
Fedora QA Communit
> Hi,
> On Wed, Feb 10, 2010 at 12:51 AM, Roland McGrath wrote:
> >> Replace
> >> make CFLAGS="%{optflags} -X11" %{?_smp_mflags}
> >> with
> >> make CFLAGS="%{optflags}" LDFLAGS="-lX11" %{?_smp_mflags}
> >
> > This is still not really ideal. For the long run, you should be fixing the
> > upst
Hi,
On Wed, Feb 10, 2010 at 5:27 PM, Jakub Jelinek wrote:
> On Wed, Feb 10, 2010 at 08:42:53PM +0900, Mamoru Tasaka wrote:
>> Parag N(पराग़) wrote, at 02/10/2010 02:58 AM +9:00:
>> > On Tue, Feb 9, 2010 at 11:18 PM, Jakub Jelinek wrote:
>> >> On Tue, Feb 09, 2010 at 11:09:50PM +0530, Parag N(पराग़
On Wed, Feb 10, 2010 at 08:42:53PM +0900, Mamoru Tasaka wrote:
> Parag N(पराग़) wrote, at 02/10/2010 02:58 AM +9:00:
> > On Tue, Feb 9, 2010 at 11:18 PM, Jakub Jelinek wrote:
> >> On Tue, Feb 09, 2010 at 11:09:50PM +0530, Parag N(पराग़) wrote:
> >>> Anyway I find adding missing DSO to CFLAGS in SPE
Parag N(पराग़) wrote, at 02/10/2010 02:58 AM +9:00:
> On Tue, Feb 9, 2010 at 11:18 PM, Jakub Jelinek wrote:
>> On Tue, Feb 09, 2010 at 11:09:50PM +0530, Parag N(पराग़) wrote:
>>> Anyway I find adding missing DSO to CFLAGS in SPEC is easy solution for
>>> now.
>> They don't belong to CFLAGS, those
Hi,
On Wed, Feb 10, 2010 at 12:51 AM, Roland McGrath wrote:
>> Replace
>> make CFLAGS="%{optflags} -X11" %{?_smp_mflags}
>> with
>> make CFLAGS="%{optflags}" LDFLAGS="-lX11" %{?_smp_mflags}
>
> This is still not really ideal. For the long run, you should be fixing the
> upstream package so th
Charley Wang wrote:
> The details behind what this feature will do, along with how to
> get failing packages to build can be found here :
> https://fedoraproject.org/wiki/UnderstandingDSOLinkChange
"a program that links with libxml2 and uses dlopen may not link with libdl"
Nothing forbids linking
Hi everyone,
This is an update to let maintainers know that the changes to
LD outlined here :
https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking
have been pushed to Fedora rawhide.
The details behind what this feature will do, along with how to
get failing packages to build can be
- "Adam Jackson" wrote:
> On Mon, 2010-02-08 at 17:37 -0500, Roland Grunberg wrote:
> > This is just an update to let maintainers know that the changes to
> > LD outlined here :
> >
> > https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking
> >
> > will be in fedora rawhide pre
I wrote:
> I've filed this proposal for FESCo, it should get considered at the
> meeting tonight (20:00 UTC):
> https://fedorahosted.org/fesco/ticket/338
> "Proposal: postpone ChangeInImplicitDSOLinking feature to F14 and revert
> its implementation from pre-branch Rawhide"
Sadly, this proposal go
On Mon, 2010-02-08 at 17:37 -0500, Roland Grunberg wrote:
> This is just an update to let maintainers know that the changes to
> LD outlined here :
>
> https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking
>
> will be in fedora rawhide pretty soon.
>
> The details behind what this f
Jakub Jelinek wrote:
> You are probably looking for bug compatibility, and that isn't something
> GCC guarantees, definitely not between major versions.
And that's one half of what I'm complaining about.
> The C/C++ standards (and standards governing the extensions to the
> languages) is what mat
On Tue, Feb 09, 2010 at 07:42:44PM +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
> > I disagree with that. Previous changes to the build environment - even
> > upstream GCC changes - have broken way more packages (every GCC .x
> > release tends to break a lot of things temporarily).
>
> And
> Replace
> make CFLAGS="%{optflags} -X11" %{?_smp_mflags}
> with
> make CFLAGS="%{optflags}" LDFLAGS="-lX11" %{?_smp_mflags}
This is still not really ideal. For the long run, you should be fixing the
upstream package so that it passes -lX11 where it needs it. The most proper
change keeps -l
On Tue, 9 Feb 2010 23:28:01 +0530, Parag wrote:
> On Tue, Feb 9, 2010 at 11:18 PM, Jakub Jelinek wrote:
> > On Tue, Feb 09, 2010 at 11:09:50PM +0530, Parag N(पराग़) wrote:
> >> Anyway I find adding missing DSO to CFLAGS in SPEC is easy solution for
> >> now.
> >
> > They don't belong to CFLAGS,
> Will there we a switch to give me the old behavior? I might want this for
> my own legacy code.
Not forever. You really should fix your makefiles. It's just cleaning
up usage that was sloppy originally.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mail
> They will only be so for a fairly short time, and you gave no specific
> time frame for landing the change (only 'pretty soon'), so it was not
> entirely clear. Thanks.
Sorry, we meant to be clear that it was "now" as of the posting.
--
devel mailing list
devel@lists.fedoraproject.org
https://a
Adam Williamson wrote:
> I disagree with that. Previous changes to the build environment - even
> upstream GCC changes - have broken way more packages (every GCC .x
> release tends to break a lot of things temporarily).
And that's something which really irks me about GCC upstream, they don't
seem
Parag N(पराग़) wrote:
> +1. Please revert the changes.
I've filed this proposal for FESCo, it should get considered at the meeting
tonight (20:00 UTC):
https://fedorahosted.org/fesco/ticket/338
"Proposal: postpone ChangeInImplicitDSOLinking feature to F14 and revert its
implementation from pre-b
On Tue, 2010-02-09 at 16:40 +0100, Kevin Kofler wrote:
> > 281 packages? Wov! (That's after the most often occurring problems have
> > been already resolved, am I right?)
> >
> > + let's say 300 "regular" FTBFS bugs -- the F13 mass rebuild will be
> > really great...
>
> To me, this shows that t
On Tue, Feb 9, 2010 at 11:18 PM, Jakub Jelinek wrote:
> On Tue, Feb 09, 2010 at 11:09:50PM +0530, Parag N(पराग़) wrote:
>> Anyway I find adding missing DSO to CFLAGS in SPEC is easy solution for now.
>
> They don't belong to CFLAGS, those are flags for compilation. You want
> LDFLAGS or even bett
On Tue, Feb 09, 2010 at 11:09:50PM +0530, Parag N(पराग़) wrote:
> Anyway I find adding missing DSO to CFLAGS in SPEC is easy solution for now.
They don't belong to CFLAGS, those are flags for compilation. You want
LDFLAGS or even better add it in configure to LIBS.
Jakub
--
devel mailin
On Tue, Feb 9, 2010 at 9:14 PM, Roland Grunberg wrote:
>>Most of the time upstream (myself included) just forgets to add a
>>library at the end of the LDADD line, so all I had to do was send a
>>trivial patch upstream to add "-lm" or something.
>
>>See here for an example:
>>http://bugzilla-attach
Hi,
On Tue, Feb 9, 2010 at 9:08 PM, Kevin Kofler wrote:
> Richard Hughes wrote:
>> I've been fixing upstream projects for weeks to build with
>> --no-[add]-needed. The list of projects that fail to build should be much
>> smaller now, especially for GNOME and Freedesktop stuff.
>
> 1. But have th
On Tuesday 09 February 2010 16:38:52 Kevin Kofler wrote:
> Richard Hughes wrote:
> > I've been fixing upstream projects for weeks to build with
> > --no-[add]-needed. The list of projects that fail to build should be much
> > smaller now, especially for GNOME and Freedesktop stuff.
>
> 1. But have
On Tue, Feb 09, 2010 at 09:38:05AM -0500, Adam Jackson wrote:
> No, you mean --add-needed.
Fair enough. BTW the man page seems to indicate that --add-needed is
deprecated (replaced by --copy-dt-needed-entries).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjo
Milos Jakubicek wrote:
> On 8.2.2010 23:37, Roland Grunberg wrote:
>>
>> https://fedoraproject.org/wiki/DSOLinkBugs
>
> 281 packages? Wov! (That's after the most often occurring problems have
> been already resolved, am I right?)
>
> + let's say 300 "regular" FTBFS bugs -- the F13 mass rebuild w
>Most of the time upstream (myself included) just forgets to add a
>library at the end of the LDADD line, so all I had to do was send a
>trivial patch upstream to add "-lm" or something.
>See here for an example:
>http://bugzilla-attachments.gnome.org/attachment.cgi?id=152993
In fact most of the
Richard Hughes wrote:
> I've been fixing upstream projects for weeks to build with
> --no-[add]-needed. The list of projects that fail to build should be much
> smaller now, especially for GNOME and Freedesktop stuff.
1. But have those fixes been applied in the Fedora packages? At least
NetworkMa
On Tue, 2010-02-09 at 08:06 +, Richard Hughes wrote:
> On 8 February 2010 22:46, Kevin Kofler wrote:
> > As a result, you'll be causing dozens of FTBFS bugs just before the feature
> > freeze. I think this is entirely the wrong time in the release cycle to do
> > such a change, if it is done a
On Tue, 2010-02-09 at 13:56 +, Richard W.M. Jones wrote:
> On Tue, Feb 09, 2010 at 06:55:11AM -0500, Neal Becker wrote:
> > Will there we a switch to give me the old behavior? I might want this for
> > my own legacy code.
>
> I have not tried it, but apparently --as-needed (or from gcc use
>
Hello Roland,
On Mon, Feb 08, 2010 at 05:37:13PM -0500, Roland Grunberg wrote:
[...]
> Also, packages that have failed to build under these new changes can
> be found here :
>
> https://fedoraproject.org/wiki/DSOLinkBugs
I have patched and re-built the ghex package, so it probably won't
belon
On Tue, Feb 09, 2010 at 06:55:11AM -0500, Neal Becker wrote:
> Will there we a switch to give me the old behavior? I might want this for
> my own legacy code.
I have not tried it, but apparently --as-needed (or from gcc use
-Wl,--as-needed):
--as-needed
--no-as-needed
T
On Mon, 2010-02-08 at 17:37 -0500, Roland Grunberg wrote:
> This is just an update to let maintainers know that the changes to
> LD outlined here :
>
> https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking
>
> will be in fedora rawhide pretty soon.
>
> The details behind what this f
Will there we a switch to give me the old behavior? I might want this for
my own legacy code.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
2010/2/9 Parag N(पराग़) :
> when one of my package fails to build? Should I ask upstream to
> hardcode required DSO names in Makefile or we need to modify CFLAGS in
> %build section?
Most of the time upstream (myself included) just forgets to add a
library at the end of the LDADD line, so all I had
Hi,
On Tue, Feb 9, 2010 at 8:17 AM, Roland McGrath wrote:
>> Worth clarifying here: Rawhide or (and?) F13?
>
> They are still the same thing, so both. gcc-4.4.3-5.fc13 is there right now.
>
I will say this change is introduced at wrong time, considering we
have only one week left for F13 Alph
On 8 February 2010 22:46, Kevin Kofler wrote:
> As a result, you'll be causing dozens of FTBFS bugs just before the feature
> freeze. I think this is entirely the wrong time in the release cycle to do
> such a change, if it is done at all.
I've been fixing upstream projects for weeks to build wit
On Mon, 2010-02-08 at 18:47 -0800, Roland McGrath wrote:
> > Worth clarifying here: Rawhide or (and?) F13?
>
> They are still the same thing, so both.
They will only be so for a fairly short time, and you gave no specific
time frame for landing the change (only 'pretty soon'), so it was not
entir
> Worth clarifying here: Rawhide or (and?) F13?
They are still the same thing, so both. gcc-4.4.3-5.fc13 is there right now.
Thanks,
Roland
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, 2010-02-08 at 17:37 -0500, Roland Grunberg wrote:
> This is just an update to let maintainers know that the changes to
> LD outlined here :
>
> https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking
>
> will be in fedora rawhide pretty soon.
Worth clarifying here: Rawhide or
On 8.2.2010 23:37, Roland Grunberg wrote:
>
> https://fedoraproject.org/wiki/DSOLinkBugs
281 packages? Wov! (That's after the most often occurring problems have
been already resolved, am I right?)
+ let's say 300 "regular" FTBFS bugs -- the F13 mass rebuild will be
really great...
>
> Thank-Yo
Roland Grunberg wrote:
> This is just an update to let maintainers know that the changes to
> LD outlined here :
>
> https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking
>
> will be in fedora rawhide pretty soon.
As a result, you'll be causing dozens of FTBFS bugs just before the f
This is just an update to let maintainers know that the changes to
LD outlined here :
https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking
will be in fedora rawhide pretty soon.
The details behind what this feature will do, along with how to
get failing packages to build can be fou
76 matches
Mail list logo
