On 01/11/2010 01:45 PM, Charley Wang wrote:
> The change will force explicit declaration of links rather than implicitly
> detecting links. More detailed info is here:
>
It would be nice if libtool were also updated to not explicitly link all
dependent libraries transitively. rpmlint complains ab
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/13/2010 09:05 AM, John Reiser wrote:
> *weak undefined* means "I accept *any* definition, or even *no* definition."
> Both binutils and glibc must fix their errors of insisting on any particular
> symbol version for a *weak undefined* symbol.
No
> But, you have added an explicit dependency upon libdb to your executable
> by mentioning -ldb on the gcc command line. Therefore libdb will be
> loaded at execution start-up. But libdb has a dependency upon
> libpthread, so that library will also be loaded at execution start-up.
> Hence whe
> Right - Obviously I had not considered the case of a weak reference to a
> symbol defined in an as-needed DSO. I'll look into it today.
You're going to confuse the poor bystanders by using the wrong terminology.
There is no issue with as-needed. It's only --no-add-needed we are talking
about
> > That's correct. In other words, the libfoo.so DSO will only be used at
> > runtime if the presence of -lfoo at link time actually had any effect on
> > what symbols got resolved to what. But --as-needed is not really apropos
> > in this thread.
>
> OK, if RPM picks only the libraries that ar
On Wed, 2010-01-13 at 10:52 -0800, Roland McGrath wrote:
> > - "Jussi Lehtola" wrote:
> > >
> > > So is --as-needed within the current default flags?
> >
> > As far as I know, no. The default will still be --no-as-needed.
>
> That's correct. This change does not affect --as-needed at all.
>
> - "Jussi Lehtola" wrote:
> >
> > So is --as-needed within the current default flags?
>
> As far as I know, no. The default will still be --no-as-needed.
That's correct. This change does not affect --as-needed at all.
> The --as-needed flag will link libraries if
> A) they define symb
On Wed, Jan 13, 2010 at 12:10:06PM -0500, Adam Jackson wrote:
> On Wed, 2010-01-13 at 16:24 +, Nick Clifton wrote:
> > >> $ g++ -o string string.o -ldb
> > >> /usr/bin/ld.bfd: string.11980.test: undefined reference to symbol
> > >> 'pthread_cancel@@GLIBC_2.2.5'
> > >> /usr/bin/ld.bfd: note: 'pt
On Wed, 2010-01-13 at 16:24 +, Nick Clifton wrote:
> Hi Guys,
> >> SystemTap is failing on pthread_cancel, which is odd since we have no
> >> mention of pthread in our own sources. It seems to be pulled in by some
> >> headers in the STL. Consider this minimal example:
> >>
> >> $ cat string.
On 01/13/2010 08:24 AM, Nick Clifton wrote:
> Hi Guys,
>
>>> SystemTap is failing on pthread_cancel, which is odd since we have no
>>> mention of pthread in our own sources. It seems to be pulled in by some
>>> headers in the STL. Consider this minimal example:
>>>
>>> $ cat string.cxx
>>> #inclu
Hi Guys,
>> SystemTap is failing on pthread_cancel, which is odd since we have no
>> mention of pthread in our own sources. It seems to be pulled in by some
>> headers in the STL. Consider this minimal example:
>>
>> $ cat string.cxx
>> #include
>> int main()
>> {
>> return std::string("foo
- "Jussi Lehtola" wrote:
>
> So is --as-needed within the current default flags?
As far as I know, no. The default will still be --no-as-needed.
If anyone reading this is interested/confused, I think the
difference is:
The --as-needed flag will link libraries if
A) they define symbols re
On Wed, 2010-01-13 at 12:23 +0100, Michael Schwendt wrote:
> On Tue, 12 Jan 2010 19:54:40 -0500, Matthias wrote:
>
> > > The old semantics made this case work without the .la file, the new
> > > semantics lead to programs failing to link in Fedora, making Fedora
> > > incompatible with upstream (u
On Wed, 13 Jan 2010 09:04:21 +, Adam wrote:
> On Tue, 2010-01-12 at 20:04 -0500, Matthias Clasen wrote:
> > On Wed, 2010-01-13 at 00:06 +, Adam Williamson wrote:
> >
> > >
> > > if so, Mandriva has been enforcing the fixing of this type of error for
> > > a couple of years now (by having
On Tue, 12 Jan 2010 19:54:40 -0500, Matthias wrote:
> > The old semantics made this case work without the .la file, the new
> > semantics lead to programs failing to link in Fedora, making Fedora
> > incompatible with upstream (unless we start to ship .la files again).
>
> .pc files handle this
On Tue, 2010-01-12 at 20:04 -0500, Matthias Clasen wrote:
> On Wed, 2010-01-13 at 00:06 +, Adam Williamson wrote:
>
> >
> > if so, Mandriva has been enforcing the fixing of this type of error for
> > a couple of years now (by having --as-needed and --no-undefined in the
> > default ld flags).
On Wed, 2010-01-13 at 01:15 +0100, Kevin Kofler wrote:
> On Wednesday 13 January 2010, Adam Williamson wrote:
> > On Tue, 2010-01-12 at 01:59 +0100, Milos Jakubicek wrote:
> > > Also I have really doubts what concerns upstreamability of the necessary
> > > changes in packages. Especially if other d
Enrico Scholz writes:
> I have problems to understand the xmlrpc-c build failure
>
> | /usr/bin/ld.bfd: xml-rpc-api2cpp.5842.test: undefined reference to symbol
> 'pthread_cancel@@GLIBC_2.2.5'
It happens because a library where the program is linked against uses
pthread_* but is not linked agai
> I have problems to understand the xmlrpc-c build failure
>
> | /usr/bin/ld.bfd: xml-rpc-api2cpp.5842.test: undefined reference to symbol
> 'pthread_cancel@@GLIBC_2.2.5'
>
> pthread_cancel() is not used by the program. I see it in the .plt section
> only but not where it is referenced.
>
> I wo
> 78 of those seem to be caused by separated libtinfo. In default
> ncurses configuration libtinfo is included in libncurses, so I don't
> think the upstreams will be very happy about adding support for
> non-standard configurations.
>
> Petr Machata suggested we could work around it by replacing
> According to notting and the experimentation that I did after the FESCo
> meeting, the shared libraries bring in any libraries that they depend on.
> However, if the application linking to the shared library also requires the
> third shared library but doesn't explicitly link it then the link wil
On Wed, 2010-01-13 at 00:06 +, Adam Williamson wrote:
>
> if so, Mandriva has been enforcing the fixing of this type of error for
> a couple of years now (by having --as-needed and --no-undefined in the
> default ld flags). This has a few implications:
--as-needed is actually kinda the oppos
On Wednesday 13 January 2010, Adam Williamson wrote:
> On Tue, 2010-01-12 at 01:59 +0100, Milos Jakubicek wrote:
> > Also I have really doubts what concerns upstreamability of the necessary
> > changes in packages. Especially if other distributions will (???)
> > continue shipping ld with the tradi
On Wed, 2010-01-13 at 01:52 +0100, Kevin Kofler wrote:
> On Wednesday 13 January 2010, Adam Williamson wrote:
> > On Tue, 2010-01-12 at 01:59 +0100, Milos Jakubicek wrote:
> > > Also I have really doubts what concerns upstreamability of the necessary
> > > changes in packages. Especially if other d
On Wednesday 13 January 2010, Adam Williamson wrote:
> On Tue, 2010-01-12 at 01:59 +0100, Milos Jakubicek wrote:
> > Also I have really doubts what concerns upstreamability of the necessary
> > changes in packages. Especially if other distributions will (???)
> > continue shipping ld with the tradi
On Tue, 2010-01-12 at 01:59 +0100, Milos Jakubicek wrote:
> Also I have really doubts what concerns upstreamability of the necessary
> changes in packages. Especially if other distributions will (???)
> continue shipping ld with the traditional semantics, this means hours of
> headache discussi
>> SystemTap is failing on pthread_cancel, which is odd since we have no
>> mention of pthread in our own sources. It seems to be pulled in by some
>> headers in the STL.
>> $ nm -C string.o
>> w pthread_cancel
>> So it seems that now I have to know what my dependent libraries
Milos Jakubicek wrote:
> Also I have really doubts what concerns upstreamability of the necessary
> changes in packages.
These are absolutely upstreamable fixes. Using symbols from a library that
you do not explicity link is a bug, plain and simple.
-- Rex
--
devel mailing list
devel@lists.fe
Charley Wang writes:
> https://fedoraproject.org/wiki/DSOLinkBugs
>
> Please note that many of the packages may be failing because of a few
> DSO's. Further exploration is needed to evaluate this possibility so
> we can apply one patch to the source of the problem instead of dozens
> of superfluo
On Mon, Jan 11, 2010 at 01:45:55PM -0500, Charley Wang wrote:
> A rebuild was conducted, and a preliminary (unsorted) list of packages
> that have implicit linkage errors can be found here:
>
> https://fedoraproject.org/wiki/DSOLinkBugs
78 of those seem to be caused by separated libtinfo. In def
On Tue, Jan 12, 2010 at 01:45:07AM +0100, Kevin Kofler wrote:
> Charley Wang wrote:
> > Please note that many of the packages may be failing because of a few
> > DSO's. Further exploration is needed to evaluate this possibility so
> > we can apply one patch to the source of the problem instead of d
On 12.1.2010 01:14, Kevin Kofler wrote:
> semantics) hitting so many packages is a very bad idea and that it's
> unrealistic to get them all fixed for F13.
+ 1...speaking as somebody who's fixed dozens of packages after the F11
and F12 mass rebuilds and looking at the loong list referenced a
Kevin Kofler writes:
> I also think that this change will probably force us to ship .la files. The
> only reason we didn't need them so far was that implicit linking feature.
[ scratches head... ] How so? AFAICS the only change here is that
programs now have to explicitly list all the librarie
Charley Wang wrote:
> Please note that many of the packages may be failing because of a few
> DSO's. Further exploration is needed to evaluate this possibility so
> we can apply one patch to the source of the problem instead of dozens of
> superfluous patches. We also need (and would appreciate hel
Charley Wang wrote:
> A rebuild was conducted, and a preliminary (unsorted) list of packages
> that have implicit linkage errors can be found here:
>
> https://fedoraproject.org/wiki/DSOLinkBugs
I still think that a backwards-incompatible change to something as central
as linking semantics (the
> SystemTap is failing on pthread_cancel, which is odd since we have no
> mention of pthread in our own sources. It seems to be pulled in by some
> headers in the STL. Consider this minimal example:
>
> $ cat string.cxx
> #include
> int main()
> {
> return std::string("foo").length() != 3;
On 01/11/2010 10:45 AM, Charley Wang wrote:
> Hi Fedora Developers,
>
> This is a quick announcement of the proposed change to DSO linking
> (https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking).
>
> The change will force explicit declaration of links rather than implicitly
> detec
- "Ville Skyttä" wrote:
> On Monday 11 January 2010, Charley Wang wrote:
>
> > We also need (and would appreciate help with) the
> > linking of failed build logs to their package owners.
>
> If you want just an e-mail address per package, use -
> ow...@fedoraproject.org. If you want more
On Monday 11 January 2010, Charley Wang wrote:
> We also need (and would appreciate help with) the
> linking of failed build logs to their package owners.
If you want just an e-mail address per package, use -
ow...@fedoraproject.org. If you want more than that, see /usr/bin/fedoradev-
pkgowners
On 11.1.2010 19:45, Charley Wang wrote:
> Hi Fedora Developers,
>
> This is a quick announcement of the proposed change to DSO linking
> (https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking).
>
> The change will force explicit declaration of links rather than implicitly
> detecting l
Hi Fedora Developers,
This is a quick announcement of the proposed change to DSO linking
(https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking).
The change will force explicit declaration of links rather than implicitly
detecting links. More detailed info is here:
https://fedorapro
41 matches
Mail list logo
