On Wed, 2011-03-23 at 00:57 +0100, Samuel Thibault wrote:
> I've uploaded a package with your fix on debian-ports. Upstream
> discussion still has to happen on
>
> http://sourceware.org/bugzilla/show_bug.cgi?id=1
Looks like the patch at sourceware.org is not the right one, neither is
the patc
I've uploaded a package with your fix on debian-ports. Upstream
discussion still has to happen on
http://sourceware.org/bugzilla/show_bug.cgi?id=1
Samuel
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debi
On Tue, 2011-03-22 at 10:21 +0100, Samuel Thibault wrote:
> Svante Signell, le Tue 22 Mar 2011 08:49:14 +0100, a écrit :
> > Attaching the patch for review.
>
> Thanks.
>
> > The need to explicitly link the lib*user libraries is probably due to
> > the recent ---as-needed linker changes. Was this
Svante Signell, le Tue 22 Mar 2011 08:49:14 +0100, a écrit :
> Attaching the patch for review.
Thanks.
> The need to explicitly link the lib*user libraries is probably due to
> the recent ---as-needed linker changes. Was this needed before?
It wasn't. Please remove this part from the patch for n
On Mon, 2011-03-21 at 22:53 +0100, Samuel Thibault wrote:
> Svante Signell, le Mon 21 Mar 2011 22:28:54 +0100, a écrit :
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x0804846c in main () at test.c:1
> > 1 int main(void){ *(int*)0=0;}
> >
> > Only quitting talks about bogus threa
Svante Signell, le Mon 21 Mar 2011 22:28:54 +0100, a écrit :
> Program received signal SIGSEGV, Segmentation fault.
> 0x0804846c in main () at test.c:1
> 1 int main(void){ *(int*)0=0;}
>
> Only quitting talks about bogus threads:
> (gdb) quit
> A debugging session is active.
>
> Infer
On Mon, 2011-03-21 at 22:19 +0100, Samuel Thibault wrote:
> Svante Signell, le Mon 21 Mar 2011 22:09:37 +0100, a écrit :
> > It also works, At least I could run random programs
> > with gdb: mutt+mutt-dbg and ls.
>
> Did you try to reproduce
> http://sourceware.org/bugzilla/show_bug.cgi?id=1
Svante Signell, le Mon 21 Mar 2011 22:09:37 +0100, a écrit :
> It also works, At least I could run random programs
> with gdb: mutt+mutt-dbg and ls.
Did you try to reproduce
http://sourceware.org/bugzilla/show_bug.cgi?id=1
?
Samuel
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debi
On Sun, 2011-03-20 at 22:45 +0100, Svante Signell wrote:
> On Sun, 2011-03-20 at 22:21 +0100, Samuel Thibault wrote:
> > Svante Signell, le Sun 20 Mar 2011 22:15:35 +0100, a écrit :
> > > On Sun, 2011-03-20 at 22:09 +0100, Samuel Thibault wrote:
> > > > Svante Signell, le Sun 20 Mar 2011 22:02:35 +
On Sun, 2011-03-20 at 22:21 +0100, Samuel Thibault wrote:
> Svante Signell, le Sun 20 Mar 2011 22:15:35 +0100, a écrit :
> > On Sun, 2011-03-20 at 22:09 +0100, Samuel Thibault wrote:
> > > Svante Signell, le Sun 20 Mar 2011 22:02:35 +0100, a écrit :
> > > > This function is defined in threads.c bud
Svante Signell, le Sun 20 Mar 2011 22:15:35 +0100, a écrit :
> On Sun, 2011-03-20 at 22:09 +0100, Samuel Thibault wrote:
> > Svante Signell, le Sun 20 Mar 2011 22:02:35 +0100, a écrit :
> > > This function is defined in threads.c bud does not seem to be recognized
> > > by the linker. What is the d
On Sun, 2011-03-20 at 22:09 +0100, Samuel Thibault wrote:
> Svante Signell, le Sun 20 Mar 2011 22:02:35 +0100, a écrit :
> > This function is defined in threads.c bud does not seem to be recognized
> > by the linker. What is the difference with a symbol reported as "T" or
> > "t" ?
>
> t is for st
Svante Signell, le Sun 20 Mar 2011 22:02:35 +0100, a écrit :
> This function is defined in threads.c bud does not seem to be recognized
> by the linker. What is the difference with a symbol reported as "T" or
> "t" ?
t is for static functions, which can't be used outside the .o file. Is
it hurd-o
Hi,
I tried to build gdb with the patch in bug #579834 but got into problems
with the linker:
srs@kvm-hurd:~/DEBs/gdb/gdb-7.2/build/objdir/gdb$ i486-gnu-gcc -g
-D_GNU_SOURCE -o gdb gdb.o libgdb.a
-lreadline ../opcodes/libopcodes.a ../bfd/libbfd.a ../libiberty/libiberty.a
../libdecnumber/libdecn
On Mon, 11 Apr 2005, Michael Banck wrote:
> What I am doing is hacking sbuild to add an
> LD_LIBRARY_PATH=/usr/X11R6/lib before the dpkg-buildpackage call.
Ah, that's it! I'll use this then:
diff -ru sbuild-0.35.orig/sbuild sbuild-0.35/sbuild
--- sbuild-0.35.orig/sbuild 2005-03-31 18:42:48.0
Hi,
On Mon, Apr 11, 2005 at 07:11:25PM +0200, Marco Gerards wrote:
> Santiago Vila <[EMAIL PROTECTED]> writes:
>
> > There was a similar problem in the kfreebsd-i386 architecture and it
> > was solved by modifying binutils to honor /etc/ld.so.conf.
What I am doing is hacking sbuild to add an
LD_
> There was a similar problem in the kfreebsd-i386 architecture and
> it was solved by modifying binutils to honor /etc/ld.so.conf.
Didn't Jeff fix this already? CC'ing Jeff to be sure he reads
this...
Adding support for ld.so.conf on Debian GNU/Hurd is not a fix.
Infact, that patch
Santiago Vila <[EMAIL PROTECTED]> writes:
> There was a similar problem in the kfreebsd-i386 architecture and it
> was solved by modifying binutils to honor /etc/ld.so.conf.
Didn't Jeff fix this already? CC'ing Jeff to be sure he reads this...
--
Marco
--
To UNSUBSCRIBE, email to [EMAIL PROT
o avoid gratuitous warnings.
rpath_link=
;;
esac
done
exec /usr/bin/`basename $0` ${1+"$@"} $rpath_link
If I put this in /usr/local/bin and symlink gcc, cc, i386-gnu-gcc, etc.
to it, the linking problems disappear as well.
This is of course a hack, but so was the modified dpkg-shlib
19 matches
Mail list logo
