Benjamin Reed wrote:
So a side-effect of OSX's crappy linker is that when you have a
library specified multiple times on the command-line (-lkdecore
-lkdecore) it actually tries to mmap them twice when linking, even
though the resulting binary only has one link (as it should).
I'm hitting
Hello,
while preparing the 4.0 release in Gentoo we have hit a problem with split
packages (each app/lib in a separate package, like konqueror, libkonq, kdm
etc.). To present the problem I will use a concrete example of kdepasswd. In
order to build it we only unpack apps/kdepasswd (and
On Monday 07 of January 2008 19:01:45 Alexander Neundorf wrote:
I hope I understand correctly.
So the kcm links to the konq library. When building everything in one part,
the target konq is known as a library and so the kcm will link against it
and the dependent libraries.
Yes.
Now the
On Monday 07 January 2008, Piotr Jaroszyński wrote:
On Monday 07 of January 2008 19:23:56 Alexander Neundorf wrote:
Sounds like an idea.
This will be some work. It means that developers must not use the target
names anymore when linking to libraries :-/
Would it be an option for you
On Jan 7, 2008 11:27 AM, Bill Hoffman [EMAIL PROTECTED] wrote:
Can you create a bug report for this in the CMake bug tracker?
Heh, went to do so, and it turns out I already opened one... =)
http://www.cmake.org/Bug/view.php?id=4810
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X
On Monday 07 of January 2008 20:26:58 Alexander Neundorf wrote:
Rebuilding libs for each package is not an option as Gentoo is a source
based distributions, users would kill us :) Unpacking more stuff won't
hurt as far as we don't build everything over and over again. Would it be
possible
Piotr Jaroszyński wrote:
So, to be thorough, the following command-line:
/usr/lib64/ccache/bin/x86_64-pc-linux-gnu-g++ -fPIC -O2 -march=athlon64
-pipe -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align
-Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security
-fno-exceptions
On Monday 07 of January 2008 21:35:17 Alexander Neundorf wrote:
On Monday 07 January 2008, Piotr Jaroszyński wrote:
This looks really promising, just did a simple test and e.g. for split
libkonq build I get:
SET(konq_LIB_DEPENDS ... )
SET(konq_sound_LIB_DEPENDS ... )
On Monday 07 of January 2008 21:52:11 Thiago Macieira wrote:
Piotr Jaroszyński wrote:
So, to be thorough, the following command-line:
/usr/lib64/ccache/bin/x86_64-pc-linux-gnu-g++ -fPIC -O2 -march=athlon64
-pipe -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align
Piotr Jaroszyński wrote:
Please find the .so file (not .so.N, it has to be .so) that is defines
it.
I have already done so for other package when tracking down this problem
and to be honest I don't see the point of doing it again for this
particular package. I will be happy to do it once I
Thiago Macieira wrote:
We have the following situation:
libA contains symbol X
libB links to libA
libC is what we are building
libC links to libB
libC has an undefined reference to X
I had assumed so far that the above situation would work
On Monday 07 January 2008, Piotr Jaroszyński wrote:
On Monday 07 of January 2008 21:35:17 Alexander Neundorf wrote:
On Monday 07 January 2008, Piotr Jaroszyński wrote:
This looks really promising, just did a simple test and e.g. for split
libkonq build I get:
SET(konq_LIB_DEPENDS ... )
On Monday 07 of January 2008 22:56:24 Alexander Neundorf wrote:
I'd like to get a feel how much apps and libs are affected by this.
Actually if kdepasswd would be an independent application, and if it would
link to libkonq, it would do something like this:
find_package(LibKonq)
...
13 matches
Mail list logo
