similar to: non-PIC code in shared libs again

Displaying 20 results from an estimated 10000 matches similar to: "non-PIC code in shared libs again"

2004 Sep 10
0
non-PIC code in shared libs again
--- Matt Zimmerman <mdz@debian.org> wrote: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=179434 > > In order to fix this for Debian, I changed things around to build the > .a > libraries as libtool convenience libraries; this takes care of PIC > and they > can be portably linked into shared libraries (I believe libtool would > complain about this otherwise).
2004 Sep 10
4
non-PIC code in shared libs again
On Wednesday, February 5, 2003, at 10:47 PM, Josh Coalson wrote: > --- Matt Zimmerman <mdz@debian.org> wrote: > > good, very good. it may take me a little bit to get to it > since I'm starting a new job next week. > > Ben, can you inspect the patch and confirm that it covers > what you also suggested? The patch fixed the problem with your libs. However, when
2004 Sep 10
2
[lamont+buildd@hp.com: Bug#162718: flac_1.0.4-1(hppa/unstable): FTBFS: non-PIC code in shared object]
It looks like libplugin_common.a is being linked into the shared object libxmms-flac.so. In that case, all of the objects in libplugin_common.a must be compiled with -fPIC. ----- Forwarded message from lamont+buildd@hp.com ----- Date: Sat, 28 Sep 2002 18:54:08 -0600 From: lamont+buildd@hp.com Resent-From: lamont+buildd@hp.com To: submit@bugs.debian.org Subject: Bug#162718:
2004 Sep 10
2
Re: non-PIC code in shared libs again
On Tue, Feb 11, 2003 at 05:14:45PM +0000, Christian Weisgerber wrote: > Ben Hines <bhines@alumni.ucsd.edu> wrote: > > > The patch fixed the problem with your libs. However, when linking the > > xmms plugin i still get: > > > > *** Warning: This library needs some functionality provided by -lstdc++. > > This is because of id3lib, which is written in
2004 Sep 10
2
1.0 candidate checked in
On Fri, Jul 20, 2001 at 02:42:21PM -0700, Josh Coalson wrote: > --- Matt Zimmerman <mdz@debian.org> wrote: > > It does work, but gives a warning: > > > > *** Warning: Linking the shared library libFLAC.la against the *** static > > library ia32/libFLAC-asm.a is not portable! > > > > I think this is just because libtool can't determine whether the
2004 Sep 10
2
1.0 candidate checked in
On Fri, Jul 20, 2001 at 04:17:38PM -0400, Matt Zimmerman wrote: > Maybe the easy way to get around all of this is to build a plain old .a archive > for the assembler stuff, instead of a libtool .la library. This may or may not > cause problems when linking the libFLAC shared library. I'll try it. It does work, but gives a warning: *** Warning: Linking the shared library
2004 Sep 10
2
XMMS plugin build fix
--- Matt Zimmerman <mdz@debian.org> wrote: > The only difference in the command lines seems to be that your > xmms-config > explicitly links with -lgthread, while I suppose mine lets the > dynamic linker > pull it in. The only significant difference between the old and new > _LIBADD > lines is that @XMMS_LIBS@ is at the beginning in the new one. Now > that I think
2004 Sep 10
2
metaflac man page
A volunteer wrote this man page and submitted it to the Debian bug tracking system. I have not had the time to review it, and I don't really use metaflac anyway (yet). It would be nice if 1.0.5 could ship with a full set of man pages. -- - mdz -------------- next part -------------- An embedded message was scrubbed... From: dannf@dannf.org (dann frazier) Subject: Bug#170598: manpage Date:
2004 Sep 10
4
1.0 candidate checked in
I have checked in what should be the code for 1.0. Unless I find some problems in the next two days (I'm doing one more exhaustive test on another 100 CDs) the only thing that will be changing is the new comparison table or maybe the configure stuff. So, last chance to checkout from CVS and break it! Josh P.S. Thanks to Andrey Astafiev, there's a Russian translation of the docs, which
2004 Sep 10
5
FLAC 1.0.4 beta released
All, I have just finished uploading the source release for FLAC 1.0.4 beta to Sourceforge; there are no binary releases. See the included doc/html/news.html for the changes since 1.0.3; there are quite a few. http://prdownloads.sourceforge.net/flac/flac-1.0.4_beta-src.tar.gz?download Please beat up on this as much as possible in the next week or two and try and turn up bugs. Here's a
2004 Sep 10
2
last minute changes
On Sat, Nov 17, 2001 at 04:26:48PM -0500, Matt Zimmerman wrote: > On Thu, Nov 15, 2001 at 01:57:16PM -0800, Josh Coalson wrote: > > > > yes, the ones a month ago. it's not clear that this is even related to > > 3dnow but since it was happening on Matt's new AMD box and I don't have > > enough info I turned it off by default. > > I don't remember
2004 Sep 10
2
1.0 candidate checked in
On Thu, Jul 19, 2001 at 04:58:44PM -0400, Matt Zimmerman wrote: > On Thu, Jul 19, 2001 at 10:38:14AM -0700, Josh Coalson wrote: > > > So, last chance to checkout from CVS and break it! > > Also, my libtool doesn't seem to recognize --tag=CC. What is its purpose? > > /bin/sh ../../../libtool --tag=CC --mode=compile \ > sh ../../../strip_fPIC.sh nasm -f
2004 Sep 10
2
1.0 candidate checked in
On Thu, Jul 19, 2001 at 05:05:46PM -0700, Josh Coalson wrote: > --- collver@linuxfreemail.com wrote: > > On Thu, Jul 19, 2001 at 04:58:44PM -0400, Matt Zimmerman wrote: > > > On Thu, Jul 19, 2001 at 10:38:14AM -0700, Josh Coalson wrote: > > > > > > > So, last chance to checkout from CVS and break it! > > > > > > Also, my libtool
2004 Sep 10
5
1.0 candidate checked in
On Sat, Jul 21, 2001 at 04:06:14PM -0400, Matt Zimmerman wrote: > Argh. Maybe libtool will have to get involved after all. I'll work on it > this afternoon. I think I give up. automake and libtool assume that the compiler will be able to assemble stuff, and compilers don't generally understand NASM input. I don't like the strip_fPIC bit, since just about anything that could
2004 Sep 10
2
Mac OS X - xmms plugin probs
On Wednesday, June 26, 2002, at 04:12 PM, Matt Zimmerman wrote: >> > > Was this problem new in the 1.0.3 beta? My 1.0.2 packages do not have > any > such problem; I didn't notice any weirdness with 1.0.3beta, but the > packages > have probably only been built on my machine so far. > How are you buildling it? Do you use make install DESTDIR to build into your
2004 Sep 10
1
plugin_xmms/Makefile.am incorrectly references .libs directory
When linking against a libtool library, you should simply specify it on the libtool command line as you would a library or an object file. Nothing should ever reference the .libs directory directly. diff -u -r1.1.1.1 Makefile.am --- Makefile.am 2001/01/29 18:13:29 1.1.1.1 +++ Makefile.am 2001/06/14 20:13:20 @@ -9,5 +9,6 @@ xmmsinputplugin_LTLIBRARIES = libxmms-flac.la
2004 Sep 10
1
Mac OS X - xmms plugin probs
--- Matt Zimmerman <mdz@debian.org> wrote: > I did not catch the beginning of this thread. What is the bug? > yeah, the thread's about a month old. you can see the whole thing here: http://sourceforge.net/mailarchive/forum.php?thread_id=738315&forum_id=6312 basically on OS X Ben's libtool is trying to "relink" libxmms-flac with the installed libFLAC before
2004 Sep 10
2
FLAC 1.0 Debian packages available
I just uploaded flac 1.0-1 to Debian unstable; it should appear in the archives tomorrow. In order to get things to work correctly with libtool 1.4, I had to apply the following patch: --- flac-1.0.orig/ltmain.sh +++ flac-1.0/ltmain.sh @@ -1862,6 +1862,7 @@ else # We cannot seem to hardcode it, guess
2004 Sep 10
2
libtool "missing sed" bug
I am putting the finishing touches on the next release. I got everything mostly working with the latest autotools, but I've noticed that the generated libtool after configure does not have $SED defined. searching around it seems to be a common problem. I thought as a simple workaround that I would just distribute a libtool script that sets $SED to 'sed' (expecting it to be in the
2004 Sep 10
3
Should FLAC join Xiph?
Matt Zimmerman <mdz@debian.org> wrote: > On Thu, Nov 21, 2002 at 08:11:13PM +0100, Steve Lhomme wrote: > > > Well, I think going GPL would be too much, only GPL softwares could use > > the library. > > This is a common misconception, but entirely untrue. There are many > free software licenses, including the BSD-style licenses, which are > compatible with the