Re: possible freetype transition; improved library handling needed for all C/C++ packages

2005-11-28 Thread Daniel Schepler
Le Vendredi 25 Novembre 2005 02:38, Steve Langasek a écrit :
  Try debian/patches/common/07_disable_no_undefined.diff from any of the
  core KDE packages.

 Er... that doesn't sound like a good thing, why would you want to allow
 undefined references?

If I recall correctly, the -no-undefined flag was being used along with 
--allow-undefined as an attempt to make all templates used by a library be 
instantiated.  Unfortunately, that _depended_ on libtool's broken behavior; 
without a full list of libraries, the link spews loads of undefined symbol 
warnings.  (Back when I wrote the patch, the link would actually succeed 
eventually despite all the warnings, but that might have changed since then.)

With the patch, KDE falls back to its old behavior of resolving this by 
linking a fake object file against the library object files before linking 
the libraries.
-- 
Daniel Schepler



Re: possible freetype transition; improved library handling needed for all C/C++ packages

2005-11-27 Thread Hamish Moffatt
On Tue, Nov 22, 2005 at 02:37:19PM -0800, Steve Langasek wrote:
 Due to upstream ABI changes, it looks very likely that libfreetype is
 going to have to undergo a library transition in the near future[0].
 The details are still being settled, and it's possible (though unlikely)
 that the library will be fixed so that no transition is needed, but in
 the meantime I'd like to leave you all with a public service
 announcement.

[...]

 This email, therefore, is a call-to-arms for maintainers to improve
 the library handling in their packages.  The impetus for this request is
 the prospective freetype transition, but if you maintain *any* packages
 in C and C++, this mail is still addressed to you.

So, I found out that my trustedqsl package is fairly guilty in this
regard. Not in regard to freetype, but it links directly to openssl and
libexpat, even though it doesn't use them. Upstream's autoconf setup
actually does this deliberately.

I've trimmed the configure scripts to avoid this, leaving me with the
link commands for the two binaries being:

g++ -Wall `/usr/bin/wx-config --cxxflags` -I/usr/include -I/usr/include 
-I/usr/include -g -O2  -o tqsl  tqsl.o extwizard.o tqslwiz.o dxcc.o 
stationdial.o qsodatadialog.o tqslvalidator.o tqsl_prefs.o wxutil.o -pthread 
-lwx_gtk-2.4 -ltqsllib

g++ -Wall `/usr/bin/wx-config --cxxflags` -I/usr/include -I/usr/include 
-I/usr/include -g -O2  -o tqslcert  tqslcert.o crqwiz.o dxcc.o certtree.o 
tqslcert_prefs.o getpassword.o extwizard.o loadcertwiz.o wxutil.o -pthread 
-lwx_gtk-2.4 -ltqsllib

(wx-config --libs says -pthread -lwx_gtk-2.4).

However, my built package depends on zlib1g, which it doesn't use
directly and doesn't -l during link. 

I'd welcome any suggestions on how this might be... dpkg-shlibdeps bug?

thanks

Hamish
-- 
Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: possible freetype transition; improved library handling needed for all C/C++ packages

2005-11-27 Thread Kurt Roeckx
On Sun, Nov 27, 2005 at 11:48:37PM +1100, Hamish Moffatt wrote:
 
 I've trimmed the configure scripts to avoid this, leaving me with the
 link commands for the two binaries being:
 
 g++ -Wall `/usr/bin/wx-config --cxxflags` -I/usr/include -I/usr/include 
 -I/usr/include -g -O2  -o tqsl  tqsl.o extwizard.o tqslwiz.o dxcc.o 
 stationdial.o qsodatadialog.o tqslvalidator.o tqsl_prefs.o wxutil.o -pthread 
 -lwx_gtk-2.4 -ltqsllib
 
 However, my built package depends on zlib1g, which it doesn't use
 directly and doesn't -l during link. 

./tqsl.cpp:#include zlib.h

And on line 691 you have a gzFile, 1157 calls gzopen, ...

Your configure script also checks for it, and adds it.  linking
tqslcert to -lz doesn't seem to be needed though.

 I'd welcome any suggestions on how this might be... dpkg-shlibdeps bug?

This is a linker feature which I dislike.  It adds missing
libraries if one of the libraries you link to happens to be
linked to the one you need.  For more info see:
http://sourceware.org/ml/binutils/2005-09/msg00200.html


Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: possible freetype transition; improved library handling needed for all C/C++ packages

2005-11-27 Thread Hamish Moffatt
On Sun, Nov 27, 2005 at 02:31:05PM +0100, Kurt Roeckx wrote:
 On Sun, Nov 27, 2005 at 11:48:37PM +1100, Hamish Moffatt wrote:
  g++ -Wall `/usr/bin/wx-config --cxxflags` -I/usr/include -I/usr/include 
  -I/usr/include -g -O2  -o tqsl  tqsl.o extwizard.o tqslwiz.o dxcc.o 
  stationdial.o qsodatadialog.o tqslvalidator.o tqsl_prefs.o wxutil.o 
  -pthread -lwx_gtk-2.4 -ltqsllib
  
  However, my built package depends on zlib1g, which it doesn't use
  directly and doesn't -l during link. 
 
 ./tqsl.cpp:#include zlib.h
 And on line 691 you have a gzFile, 1157 calls gzopen, ...

So it does. (And so much for my grep skills.)

 Your configure script also checks for it, and adds it.  linking

Not as of 1.11-3, where I removed the checks for libz, libexpat and
libssl. The latter two definitely aren't needed, and do disappear from
the binary package's Depends line as a result.

 tqslcert to -lz doesn't seem to be needed though.
 
  I'd welcome any suggestions on how this might be... dpkg-shlibdeps bug?
 
 This is a linker feature which I dislike.  It adds missing
 libraries if one of the libraries you link to happens to be
 linked to the one you need.  For more info see:
 http://sourceware.org/ml/binutils/2005-09/msg00200.html

Interesting. Thanks.

Hamish
-- 
Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: possible freetype transition; improved library handling needed for all C/C++ packages

2005-11-27 Thread Adam Heath
On Sun, 27 Nov 2005, Hamish Moffatt wrote:

 On Tue, Nov 22, 2005 at 02:37:19PM -0800, Steve Langasek wrote:
  Due to upstream ABI changes, it looks very likely that libfreetype is
  going to have to undergo a library transition in the near future[0].
  The details are still being settled, and it's possible (though unlikely)
  that the library will be fixed so that no transition is needed, but in
  the meantime I'd like to leave you all with a public service
  announcement.

 [...]

  This email, therefore, is a call-to-arms for maintainers to improve
  the library handling in their packages.  The impetus for this request is
  the prospective freetype transition, but if you maintain *any* packages
  in C and C++, this mail is still addressed to you.

 So, I found out that my trustedqsl package is fairly guilty in this
 regard. Not in regard to freetype, but it links directly to openssl and
 libexpat, even though it doesn't use them. Upstream's autoconf setup
 actually does this deliberately.

 I've trimmed the configure scripts to avoid this, leaving me with the
 link commands for the two binaries being:

 g++ -Wall `/usr/bin/wx-config --cxxflags` -I/usr/include -I/usr/include 
 -I/usr/include -g -O2  -o tqsl  tqsl.o extwizard.o tqslwiz.o dxcc.o 
 stationdial.o qsodatadialog.o tqslvalidator.o tqsl_prefs.o wxutil.o -pthread 
 -lwx_gtk-2.4 -ltqsllib

 g++ -Wall `/usr/bin/wx-config --cxxflags` -I/usr/include -I/usr/include 
 -I/usr/include -g -O2  -o tqslcert  tqslcert.o crqwiz.o dxcc.o certtree.o 
 tqslcert_prefs.o getpassword.o extwizard.o loadcertwiz.o wxutil.o -pthread 
 -lwx_gtk-2.4 -ltqsllib

And what does wx-config produce?  Please expand everything when asking
questions.

 (wx-config --libs says -pthread -lwx_gtk-2.4).

But you use --cxxflags.

 However, my built package depends on zlib1g, which it doesn't use
 directly and doesn't -l during link.

objdump -p $binary|grep NEEDED.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: possible freetype transition; improved library handling needed for all C/C++ packages

2005-11-26 Thread Kurt Roeckx
On Thu, Nov 24, 2005 at 02:43:14PM +0100, Peter Eisentraut wrote:
 Steve Langasek wrote:
  * Use Debian's libtool.
 
 kmldonkey links with the following libraries: -lkdeui -lkio.  As shipped,
 libtool expands that to every library under the sun.  The new libtool
 indeed reduces this to /usr/lib/libkdeui.so /usr/lib/libkio.so and a few
 system libraries/objects, which is then greeted by ld with hundreds of
 error messages of the kind:
 
 /usr/share/qt3/include/qstring.h:847: undefined reference to 
 `QString::shared_null'
 /usr/share/qt3/include/qstring.h:848: undefined reference to 
 `QStringData::deleteSelf()'

kmldonkey seems to have alot (26?) includes of qstring.h, so to
me this doesn't looks like a bug in libtool but rather in your
package not linking to all the libraries it should be.  It just
used to work, which is not an excuse for not having a build
dependency on it or linking to it.

 Both libkdeui and libkio reference (as shown by ldd) libqt-mt (which
 I suppose is where these symbols should be).

So you probably should add a build dependency to libqt3-mt-dev,
and add a -lqt-mt

 The error messages in the rekall build are of the sort
 
 .../rekall-2.2.3-2/db/mysql/kb_mysql.cpp:595: undefined reference to 
 `i18n(char const*)'

Which is defined in /usr/include/kde/klocale.h, so that would be
part of kdelibs, and seems you need to link to -lkdecore for
that, which you don't seem to link atleast for that.

(Also see libs/common/kb_classes.h:408)

 Have other maintainers of Qt/KDE-related packages
 perhaps experienced this?

I'm not sure many people have actually tried to get things right,
since it just works.  I hope more people actually look at their
packages, and maybe ask for help if they can't figure it out
themself.


Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: possible freetype transition; improved library handling needed for all C/C++ packages

2005-11-24 Thread Steve Langasek
On Thu, Nov 24, 2005 at 01:25:07AM +0100, Henning Makholm wrote:
 Scripsit Steve Langasek [EMAIL PROTECTED]

  * Don't use other *-config tools.

  While many libraries these days use pkg-config, there are also other
  libs which ship their own tools for querying library and header include
  paths, libs needed for linking, etc.  The problem is that all of these
  tools I've seen are incapable of distinguishing between what's needed
  for static linking, and what's needed for dynamic linking.

 Would you recommend against *shipping* such a script when upstream
 provides it (in addition to a .pc file)?

If upstream ships both a .pc file (either correct, or fixable as described)
and a -config script that does the wrong thing, then yeah, I would recommend
to not ship the -config script unless there is a compelling reason why you
need to keep it...

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature


Re: possible freetype transition; improved library handling needed for all C/C++ packages

2005-11-24 Thread Peter Eisentraut
Steve Langasek wrote:
 * Use Debian's libtool.

I took one affected package (kmldonkey) from your list, relibtoolized
it as described, and rebuilt it, which failed spectacularly.  Then, I
took another one (rekall), relibtoolized it, rebuilt it, and that
failed with a strikingly similar pattern.

kmldonkey links with the following libraries: -lkdeui -lkio.  As shipped,
libtool expands that to every library under the sun.  The new libtool
indeed reduces this to /usr/lib/libkdeui.so /usr/lib/libkio.so and a few
system libraries/objects, which is then greeted by ld with hundreds of
error messages of the kind:

/usr/share/qt3/include/qstring.h:847: undefined reference to 
`QString::shared_null'
/usr/share/qt3/include/qstring.h:848: undefined reference to 
`QStringData::deleteSelf()'

Both libkdeui and libkio reference (as shown by ldd) libqt-mt (which
I suppose is where these symbols should be).

The error messages in the rekall build are of the sort

.../rekall-2.2.3-2/db/mysql/kb_mysql.cpp:595: undefined reference to `i18n(char 
const*)'

In this case -lqt-mt is actually on the libtool command line.

So what is wrong here?  Have other maintainers of Qt/KDE-related packages
perhaps experienced this?

-- 
Please send copies of list mail to me.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: possible freetype transition; improved library handling needed for all C/C++ packages

2005-11-24 Thread Daniel Schepler
Le Jeudi 24 Novembre 2005 14:43, Peter Eisentraut a écrit :
 Steve Langasek wrote:
  * Use Debian's libtool.

 I took one affected package (kmldonkey) from your list, relibtoolized
 it as described, and rebuilt it, which failed spectacularly.  Then, I
 took another one (rekall), relibtoolized it, rebuilt it, and that
 failed with a strikingly similar pattern.

 kmldonkey links with the following libraries: -lkdeui -lkio.  As shipped,
 libtool expands that to every library under the sun.  The new libtool
 indeed reduces this to /usr/lib/libkdeui.so /usr/lib/libkio.so and a few
 system libraries/objects, which is then greeted by ld with hundreds of
 error messages of the kind:

 /usr/share/qt3/include/qstring.h:847: undefined reference to
 `QString::shared_null' /usr/share/qt3/include/qstring.h:848: undefined
 reference to `QStringData::deleteSelf()'

 Both libkdeui and libkio reference (as shown by ldd) libqt-mt (which
 I suppose is where these symbols should be).

 The error messages in the rekall build are of the sort

 .../rekall-2.2.3-2/db/mysql/kb_mysql.cpp:595: undefined reference to
 `i18n(char const*)'

 In this case -lqt-mt is actually on the libtool command line.

 So what is wrong here?  Have other maintainers of Qt/KDE-related packages
 perhaps experienced this?

Try debian/patches/common/07_disable_no_undefined.diff from any of the core 
KDE packages.
-- 
Daniel Schepler



Re: possible freetype transition; improved library handling needed for all C/C++ packages

2005-11-24 Thread Steve Langasek
On Thu, Nov 24, 2005 at 03:12:46PM +0100, Daniel Schepler wrote:
 Le Jeudi 24 Novembre 2005 14:43, Peter Eisentraut a écrit :
  Steve Langasek wrote:
   * Use Debian's libtool.

  I took one affected package (kmldonkey) from your list, relibtoolized
  it as described, and rebuilt it, which failed spectacularly.  Then, I
  took another one (rekall), relibtoolized it, rebuilt it, and that
  failed with a strikingly similar pattern.

  kmldonkey links with the following libraries: -lkdeui -lkio.  As shipped,
  libtool expands that to every library under the sun.  The new libtool
  indeed reduces this to /usr/lib/libkdeui.so /usr/lib/libkio.so and a few
  system libraries/objects, which is then greeted by ld with hundreds of
  error messages of the kind:

  /usr/share/qt3/include/qstring.h:847: undefined reference to
  `QString::shared_null' /usr/share/qt3/include/qstring.h:848: undefined
  reference to `QStringData::deleteSelf()'

  Both libkdeui and libkio reference (as shown by ldd) libqt-mt (which
  I suppose is where these symbols should be).

  The error messages in the rekall build are of the sort

  .../rekall-2.2.3-2/db/mysql/kb_mysql.cpp:595: undefined reference to
  `i18n(char const*)'

  In this case -lqt-mt is actually on the libtool command line.

  So what is wrong here?  Have other maintainers of Qt/KDE-related packages
  perhaps experienced this?

 Try debian/patches/common/07_disable_no_undefined.diff from any of the core 
 KDE packages.

Er... that doesn't sound like a good thing, why would you want to allow
undefined references?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature


Re: possible freetype transition; improved library handling needed for all C/C++ packages

2005-11-23 Thread Henning Makholm
Scripsit Steve Langasek [EMAIL PROTECTED]

 * Don't use other *-config tools.

 While many libraries these days use pkg-config, there are also other
 libs which ship their own tools for querying library and header include
 paths, libs needed for linking, etc.  The problem is that all of these
 tools I've seen are incapable of distinguishing between what's needed
 for static linking, and what's needed for dynamic linking.

Would you recommend against *shipping* such a script when upstream
provides it (in addition to a .pc file)?

-- 
Henning Makholm   Larry wants to replicate all the time ... ah, no,
   all I meant was that he likes to have a bang everywhere.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: possible freetype transition; improved library handling needed for all C/C++ packages

2005-11-23 Thread Christoph Berg
Re: Steve Langasek in [EMAIL PROTECTED]
 If you maintain a package that's affected by this issue, you can help
 today; there's no need to wait until your package is hit by a library
 transition to make the changes described above.  Indeed, for packages
 which depend on libfreetype6, it's important that we begin fixing these
 as soon as possible to avoid another multi-month transition.  A
 complete list of packages that are potentially affected by the freetype
 transition can be found at [6].

 [6] http://people.debian.org/~vorlon/freetype-without-builddeps.txt

Here's that list again, regenerated today with the command from [6],
and piped through dd-list.

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/
Anibal Avelar (Fixxxer) [EMAIL PROTECTED]
   idesk

Laszlo Boszormenyi (GCS) [EMAIL PROTECTED]
   xsidplay

J.H.M. Dassen (Ray) [EMAIL PROTECTED]
   pstoedit

Masayuki Hatta (mhatta) [EMAIL PROTECTED]
   abiword

Moray Allan [EMAIL PROTECTED]
   libmatchbox
   matchbox-desktop
   matchbox-panel
   matchbox-window-manager

Tore Anderson [EMAIL PROTECTED]
   obconf
   openbox

Ben Armstrong [EMAIL PROTECTED]
   came

Don Armstrong [EMAIL PROTECTED]
   libimage-imlib2-perl

Enrique Robledo Arnuncio [EMAIL PROTECTED]
   rosegarden4

Julien BLACHE [EMAIL PROTECTED]
   gphotocoll

Thomas Bushnell, BSG [EMAIL PROTECTED]
   bonobo
   gal0.x
   gnucash
   gtkhtml

Sebastien Bacher [EMAIL PROTECTED]
   evince
   gtk+2.0
   gtkterm
   totem

Michael Banck [EMAIL PROTECTED]
   exult

Romain Beauxis [EMAIL PROTECTED]
   kshutdown

Bradley Bell [EMAIL PROTECTED]
   kaptain

Jon Bernard [EMAIL PROTECTED]
   libimlib2-ruby

Michael Biebl [EMAIL PROTECTED]
   kdesvn

Eduard Bloch [EMAIL PROTECTED]
   icewm
   rxvt-unicode

Gonéri Le Bouder [EMAIL PROTECTED]
   klibido

Regis Boudin [EMAIL PROTECTED]
   tellico

Chris Boyle [EMAIL PROTECTED]
   klogic

Rob Bradford [EMAIL PROTECTED]
   anjuta
   screem

Ben Burton [EMAIL PROTECTED]
   kdeaddons
   kdeedu
   kdesdk
   kile
   regina-normal

Bruno Barrera C. [EMAIL PROTECTED]
   bbkeys
   blackbox

Giacomo Catenazzi [EMAIL PROTECTED]
   knapster2

Zack Cerza [EMAIL PROTECTED]
   kaffeine

Cyril Chaboisseau [EMAIL PROTECTED]
   qgo

Volker Christian [EMAIL PROTECTED]
   synce-kde

Paul Cupis [EMAIL PROTECTED]
   guarddog
   guidedog

Julien Danjou [EMAIL PROTECTED]
   telak
   torsmo

Debian Edu Developers debian-edu@lists.debian.org
   kgeography

Debian GCC Maintainers debian-gcc@lists.debian.org
   gcc-snapshot

Debian Install System Team debian-boot@lists.debian.org
   gtk+2.0-directfb

Debian OCaml Maintainers debian-ocaml-maint@lists.debian.org
   advi

Debian OpenOffice Team debian-openoffice@lists.debian.org
   oooqs

Debian Qt/KDE Maintainers debian-qt-kde@lists.debian.org
   kdeadmin
   kdebase
   kdebindings
   kdegames
   kdegraphics
   kdelibs
   kdemultimedia
   kdenetwork
   kdepim
   kdeutils
   kdewebdev
   koffice

Julien Delange [EMAIL PROTECTED]
   amule

Murat Demirten [EMAIL PROTECTED]
   sim

Eric Dorland [EMAIL PROTECTED]
   mozilla-firefox

Benjamin Drieu [EMAIL PROTECTED]
   prestimel

Peter Eisentraut [EMAIL PROTECTED]
   kmldonkey
   rekall

Free Ekanayaka [EMAIL PROTECTED]
   creox

Rene Engelhard [EMAIL PROTECTED]
   kover

Peter Van Eynde [EMAIL PROTECTED]
   cl-gd

Helen Faulkner [EMAIL PROTECTED]
   kaquarium
   kcpuload
   kfish
   knetload
   labplot

Bartosz Fenski [EMAIL PROTECTED]
   adesklets
   asc
   pypanel

Fabian Franz [EMAIL PROTECTED]
   qtparted

Hans Fugal [EMAIL PROTECTED]
   csound

Sylvain Le Gall [EMAIL PROTECTED]
   mldonkey

David Moreno Garza [EMAIL PROTECTED]
   tilda

Igor Genibel [EMAIL PROTECTED]
   kexi

Daniel Glassey [EMAIL PROTECTED]
   bibletime

Debian QA Group [EMAIL PROTECTED]
   gfax
   kbear
   ksetisaver
   ksocrat
   libgtk-perl
   mysql-navigator
   okle
   windowlab

Yu Guanghui [EMAIL PROTECTED]
   fcitx

Francois Gurin [EMAIL PROTECTED]
   kismet

Stefan Gybas [EMAIL PROTECTED]
   kflog

Peter Hawkins [EMAIL PROTECTED]
   libqt-perl

Adam Heath [EMAIL PROTECTED]
   jmagick

Andres Seco Hernandez [EMAIL PROTECTED]
   swscanner

Matt Hope [EMAIL PROTECTED]
   fluxbox

Morten Hustveit [EMAIL PROTECTED]
   kwavecontrol

Mark Hymers [EMAIL PROTECTED]
   kst

Masami Ichikawa [EMAIL PROTECTED]
   bookmarkbridge

Teemu Ikonen [EMAIL PROTECTED]
   imview

Alberto Gonzalez Iniesta [EMAIL PROTECTED]
   hotswap
   kmyfirewall

Aurelien Jarno [EMAIL PROTECTED]
   keybled
   kid3
   klineakconfig
   ksensors
   ksimus
   quiteinsane
   quiteinsanegimpplugin

Steffen Joeris [EMAIL PROTECTED]
   score-reading-trainer

Joel Johnson [EMAIL PROTECTED]
   ktorrent

Norman Jordan [EMAIL PROTECTED]
   kdevelop3

Tomohiro KUBOTA [EMAIL PROTECTED]
   mlterm

Zdenek Kabelac [EMAIL PROTECTED]
   avifile

Theodore Karkoulis [EMAIL PROTECTED]
   kbarcode
   kxdocker

Jean-Michel Kelbert [EMAIL PROTECTED]
   k3b
   karamba
   kbiff
   komba2
   kuake
   showimg
   superkaramba

Gerd Knorr [EMAIL PROTECTED]
   motv
   xawtv