Jan,
I can start the ooffice1.1 without problems here on my debian ppc sid
box (this is under debian glibc cvs 2.3.2-1). Everything seems to run
fine so far.
Jack
Jan,
I can start the ooffice1.1 without problems here on my debian ppc sid
box (this is under debian glibc cvs 2.3.2-1). Everything seems to run
fine so far.
Jack
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECT
Anyone else using debian glibc cvs to build glibc 2.3.2-1?
Do you see the following as well...
ldd -r /lib/libthread_db.so.1
libc.so.6 => /lib/libc.so.6 (0x0fe8)
/lib/ld.so.1 => /lib/ld.so.1 (0x0800)
undefined symbol: ps_pglobal_lookup (/lib/libthread_db.so.1)
undefi
Matthias,
I rebuilt your test debian binutils 2.14.90.0.1-0.1 package
on my debian ppc sid box and it looks fine. The places where we diverge
are...
your build...
=== binutils Summary ===
# of expected passes28
# of untested testcases 4
and my build
Gotom,
I downloaded the file in question...
http://people.debian.org/~daenzer/Wissensw_1.pps
...and it loads fine under openoffice 1.0.3-2 from current
debian sid against glibc 2.3.2-1. I don't have glibc 2.3.1-17
installed but I know there are significant thread issues with
the recent debia
I am wondering if other arches have noticed as many thread
related issues with the recent glibc 2.3.1 debian packages in
sid as we have on ppc? In particular, if one uses a blackdown
jdk 1.3.1 built against gcc 3.2 with recent glibc 2.3.1 packages
(-16 at least), a gcc-3.2 built mozilla would be
I am wondering if there is a gameplan on adding the support for
enabling TLS support in the devtools in sid. In particular, in trying
to build the current debian glibc cvs 2.3.2-1 release I noticed that
linuxthreads support was broken upstream. Uli seems to think this
will happen more frequently
I saw a similar problem with the last couple of
glibc 2.3.1 packages on debian ppc sid. If I visited
http://news.bbc.co.uk which has a java news ticker
mozilla would crash on the next hyperlink I tried
to visit (or if I clicked on one of the links shown
in the news ticker). I found that making my
I can confirm now that glibc 2.3.2 eliminates the TEXTREL that
shows up in recent (since at least 2.3.1-12?) glibc builds in libc.so.6
on ppc sid. Using the current debian glibc 2.3.1-14 packaging and
patches with the release 2.3.2 tarballs I get a libc.so.6 that
no longer shows a TEXTREL using.
Now that Ulrich has officially released 2.3.2 will there
be a 2.3.1-15 or will debian go straight to 2.3.2-1?
Jack
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: libc6
Version: 2.3.1-9
On debian ppc sid, the current /lib/libc-2.3.1.so appears to have
non-PIC static code linked in which is a violation of debian policy.
objdump --all-headers /lib/libc-2.3.1.so | grep TEXTREL
TEXTREL 0x0
This appears to be unique to the debian glibc 2.3.1 bui
Marco,
Since you were tracking down the non-PIC static libs
linked incorrectly into shared libs in violation of debian
policy, here are the libs on my debian ppc sid machine
which seem in violation...
/usr/lib/libgcj.so.2.0.0
/usr/lib/libgcj.so.3.0.0
/usr/lib/libgdk-x11-2.0.so.0.200.0
/usr/l
Jeff,
I believe so as he has a arch-ia64.c in the src. The test
is simple enough.
rpm --nodeps -i prelink-0.2.0-15.src.rpm
make sure libelfg0-dev is installed as well as a recent 2.4.1x kernel
and glibc 2.3.1
cd /usr/src/rpm/SPECS
rpmbuild -bp prelink.spec
cd ../BUILD/prelink/src
./configur
Jeff,
I believe so as he has a arch-ia64.c in the src. The test
is simple enough.
rpm --nodeps -i prelink-0.2.0-15.src.rpm
make sure libelfg0-dev is installed as well as a recent 2.4.1x kernel
and glibc 2.3.1
cd /usr/src/rpm/SPECS
rpmbuild -bp prelink.spec
cd ../BUILD/prelink/src
./configur
Jeff,
Oh, by the way, according to the specfile for the phoebe prelink srpm
the supported arches are now...
i386 alpha sparc sparc64 s390 s390x x86_64 ppc
I think the only ones we would have to work with Jakub on in getting
up and running are mips and hppa.
J
Jeff,
Why don't you just do a new cvs pull as well? There are fixes
up stream like...
http://sources.redhat.com/ml/libc-hacker/2002-12/msg00044.html
that could be useful.
Jack
Jeff,
Oh, by the way, according to the specfile for the phoebe prelink srpm
the supported arches are now...
i386 alpha sparc sparc64 s390 s390x x86_64 ppc
I think the only ones we would have to work with Jakub on in getting
up and running are mips and hppa.
J
Jeff,
Why don't you just do a new cvs pull as well? There are fixes
up stream like...
http://sources.redhat.com/ml/libc-hacker/2002-12/msg00044.html
that could be useful.
Jack
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscr
Jeff,
Well I have been using it on debian ppc sid since Oct and prelink
works fine. Basically the test suite is pretty solid so each arch
can tell immediately if they are suitable for using prelink. RedHat
hasn't really addressed auto-prelinking yet. I had something rigged
up which would cron pr
Well if someone is planning on doing the prelink
packages they should be aware that the latest version
of prelink is in the new RedHat beta...
ftp://ftp.redhat.com/pub/redhat/linux/beta/phoebe/en/os/i386/SRPMS/prelink-0.2.0-15.src.rpm
Although they are now using elfutils 0.72 instead of libel
Jeff,
Well I have been using it on debian ppc sid since Oct and prelink
works fine. Basically the test suite is pretty solid so each arch
can tell immediately if they are suitable for using prelink. RedHat
hasn't really addressed auto-prelinking yet. I had something rigged
up which would cron pr
Well if someone is planning on doing the prelink
packages they should be aware that the latest version
of prelink is in the new RedHat beta...
ftp://ftp.redhat.com/pub/redhat/linux/beta/phoebe/en/os/i386/SRPMS/prelink-0.2.0-15.src.rpm
Although they are now using elfutils 0.72 instead of libel
Jim,
On current debian ppc sid, the debian source package that you
have for 2.3.1-6 build fine and passes all of make check. Looks
good to go here.
Jack
Jim,
On current debian ppc sid, the debian source package that you
have for 2.3.1-6 build fine and passes all of make check. Looks
good to go here.
Jack
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED
Does anyone know what the plans are for introduction of debian
packages for prelink in sid? On debian ppc sid, prelink seems to
be working fine and I was surprised we didn't have packages for it
in sid yet.
Jack
Does anyone know what the plans are for introduction of debian
packages for prelink in sid? On debian ppc sid, prelink seems to
be working fine and I was surprised we didn't have packages for it
in sid yet.
Jack
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subj
Jeff,
Talking to Franz Sirl I just found out the real reason that
RedHat doesn't suffer from OpenOffice aborting on the first launches
like we do under debian glibc 2.3.1. It appears that they have
been undoing the GLIBC_PRIVATE on __libc_wait and __libc_waitpid.
Check a recent redhat glibc 2.3.
Jeff,
Talking to Franz Sirl I just found out the real reason that
RedHat doesn't suffer from OpenOffice aborting on the first launches
like we do under debian glibc 2.3.1. It appears that they have
been undoing the GLIBC_PRIVATE on __libc_wait and __libc_waitpid.
Check a recent redhat glibc 2.3.
Jeff,
Are you sure the regex leaks are specific to the current glibc cvs
and not in 2.3.1 as well. The way I read things was that these regex
leaks were just being discovered. I haven't seen anyone claim they
were just introduced in the cvs. Speaking of regex...while we are
waiting for the next
Jeff,
Are you sure the regex leaks are specific to the current glibc cvs
and not in 2.3.1 as well. The way I read things was that these regex
leaks were just being discovered. I haven't seen anyone claim they
were just introduced in the cvs. Speaking of regex...while we are
waiting for the next
Is there a particular reason why debian ppc sid has not had any
of the three glibc 2.3.1 package builds installed in it? We have been
passing make check on all three and Daniel Jacobowitz has already
requested that the ftp-masters do this. Thanks in advance for any
help on this.
What happened to the glibc 2.3.1-1 ppc deb packages built
on voltaire yesterday? They showed up on incoming.debian.org
and seemed to pass okay according to the log at buildd.debian.org
but were never moved into sid. Are they on hold or something?
Jack
What happened to the glibc 2.3.1-1 ppc deb packages built
on voltaire yesterday? They showed up on incoming.debian.org
and seemed to pass okay according to the log at buildd.debian.org
but were never moved into sid. Are they on hold or something?
Jack
--
To UNSUBSCRIBE,
Goto,
I thought the plan was to simply push glibc 2.3.1 into sid, no?
I have been running the glibc 2.3 debian cvs source patches
and glibc cvs (built almost daily) on debian ppc sid for about
a month now. I have seen no issues running gcc 2.95.4/glibc 2.2.5
built binaries under it. I would vote
Jeff,
Debian ppc sid should be good to go for glibc 2.3.1. I
built the current glibc cvs last night with the debian sources
from the glibc 2.3 cvs (using those debian patches) and the
resulting glibc 2.3.1-cvs passes make check fine. Now that
binutils 2.10.93.0.10-1 is in debian sid, we have no
Goto,
I thought the plan was to simply push glibc 2.3.1 into sid, no?
I have been running the glibc 2.3 debian cvs source patches
and glibc cvs (built almost daily) on debian ppc sid for about
a month now. I have seen no issues running gcc 2.95.4/glibc 2.2.5
built binaries under it. I would vot
Jeff,
Debian ppc sid should be good to go for glibc 2.3.1. I
built the current glibc cvs last night with the debian sources
from the glibc 2.3 cvs (using those debian patches) and the
resulting glibc 2.3.1-cvs passes make check fine. Now that
binutils 2.10.93.0.10-1 is in debian sid, we have no
Guido,
I believe that is the broken behavior. These undefined symbols
are going out and getting resolved by some random library in an
undependable manner. If you rebuild the package providing
/lib/libuuid.so.1 with gcc 3.2.1pre, I suspect you'll see the
breakage. The point is that with gcc >= 3
Guido,
I believe that is the broken behavior. These undefined symbols
are going out and getting resolved by some random library in an
undependable manner. If you rebuild the package providing
/lib/libuuid.so.1 with gcc 3.2.1pre, I suspect you'll see the
breakage. The point is that with gcc >=
Guido,
Well, if you have rebuilt any of those binaries with gcc > 3.1
they will work. Also double check which package your installed
libgcc_s_so belongs to. If you have a copy installed from
gcc 3.0.x it will not have those symbols .hidden. It should
be the combination of gcc 3.2.1pre (with its
Guido,
Here is a mockup patch that should be roughly what you need. Note
that I haven't sanity checked the exact types and sizes for the calls
in libgcc-compat. Someone on mips will have to do that. Also if you
haven't gone through every single debian package and scanned for symbols
you may nee
Guido,
Well, if you have rebuilt any of those binaries with gcc > 3.1
they will work. Also double check which package your installed
libgcc_s_so belongs to. If you have a copy installed from
gcc 3.0.x it will not have those symbols .hidden. It should
be the combination of gcc 3.2.1pre (with it
Guido,
The problem is running binaries built under gcc < 3.1 with this
glibc. If you have installed the glibc 2.3 that you built with gcc 3.2,
check if those binaries with the undefined symbols...
__divdi3
__ucmpdi2
__udivdi3
__umoddi3
still run. I suspect they will not. A sysdeps/mips/libgc
Guido,
Here is a mockup patch that should be roughly what you need. Note
that I haven't sanity checked the exact types and sizes for the calls
in libgcc-compat. Someone on mips will have to do that. Also if you
haven't gone through every single debian package and scanned for symbols
you may ne
Guido,
The problem is running binaries built under gcc < 3.1 with this
glibc. If you have installed the glibc 2.3 that you built with gcc 3.2,
check if those binaries with the undefined symbols...
__divdi3
__ucmpdi2
__udivdi3
__umoddi3
still run. I suspect they will not. A sysdeps/mips/libg
Matthias,
I'm not sure. I know I was told that hppa was okay. Also from my
conversations with Jakub it appears i386, ia-64, alpha and sparc32
should be fine. So I would suggest we focus on checking the status
of arm, hurd-i386, m68k, mips, mipsel, s390 and sh. I'm not sure
how many of those arch
Matthias,
I'm not sure. I know I was told that hppa was okay. Also from my
conversations with Jakub it appears i386, ia-64, alpha and sparc32
should be fine. So I would suggest we focus on checking the status
of arm, hurd-i386, m68k, mips, mipsel, s390 and sh. I'm not sure
how many of those arch
Daniel,
I am still confused. How does this differ from the case of the
.hidden symbols from libgcc that we put in libgcc-compat? It would
seem to be an identical situation, no? We just need to export for
run-time resolution but not linking. No one seems to have the same
complaint about the li
Chris Chimelis may be awhile in getting prelink
debs ready due to hardware problems. Was anyone else
considering a prelink debian source cvs along side
the existing glibc one? Since libelfg0 was updated
to 0.8.2-1 last night we are prelink compatible in
debian sid (with glibc 2.3-1 installed an
Daniel,
I take it that this hack of removing the
"compat_symbol" lines from ctype/ctype-info.c
only exports these symbols for run-time
resolution but not for linking. If that is the
case, there really isn't pressing reason to
remove such a hack from glibc 2.3 until the
next major release. It
Daniel,
Actually I take that back. Technically there is a reason to
upgrade to binutils 2.13.90.0.6 for even our current gcc 2.95
and glibc 2.2.5 based builds on ppc sid. The reason is that
a number of packages are getting shared libs built that aren't
really -zcombreloc even though they shou
Daniel,
Ben accurately pointed out that this should be a Depends for
gcc 3.2 and not glibc since prelink requires glibc 2.3 which in
turn requires gcc 3.2. I have passed that on to Matthias.
On the otherhand, I am always of the mind that there is no
reason to build with a buggy binutils
Ben,
Well on ppc we will have one specific requirement. All builds will
have to be done on binutils 2.13.90.0.6 or greater. This is because
in binutils 2.13.90.0.5 a glitch in how *r_offset was set was corrected
(now its always zero) that prevented prelink from unprelinking back to
the original
Daniel,
The prelink tarball has been released by Jakub, as Ulrich pointed
out to me. I have packaged prelink myself and passed this on to
Chris Chimelis (who had done a test packaging himself last year).
I think Chris intends, as debian binutils maintainer, to be the
prelink maintainer. Unfortu
What are the current glibc 2.3 migration plans for debian sid?
Are we coupling this with the gcc 3.2 build transition? Or are
we going before that. I am currently running the debian glibc cvs
package for glibc 2.3-1 on debian ppc sid with everything
prelinked on the machine save for j2sdk and
Hi,
With the release of prelink and glibc 2.3, we should start thinking
about creating a cron script for the prelink package. What this prelink
cron script would need to do is maintain a timestamp of the last
successful prelinking of the system in /var/tmp. At each cron'd run
of the prelink scr
Carlos,
Did you regenerate your sysdeps/hppa/fpu/libm-test-ulps?
You have to do that for glibc 2.3. Look at...
http://sources.redhat.com/ml/libc-alpha/2002-09/msg1.html
which shows the steps you need to go through.
Jack
--
To UNSUBSCRIBE, email to [EMAIL
Hi,
If anyone has run my findsyms perl script..
http://lists.debian.org/debian-glibc/2002/debian-glibc-200209/msg00148.html
http://lists.debian.org/debian-glibc/2002/debian-glibc-200209/msg00164.html
...and has results for a particular arch, they may want to share this
information upstream wi
Carlos,
I thought someone told me that the debian packages
for hppa had been run through my findsyms perl script
and that no undefined libgcc symbols were detected in
any of the binaries or libraries? If that is the case
you don't need a libgcc-compat at all.
Jack
Carlos,
It looks like Ulrich is preparing to kick out glibc shortly
and roll any remaining fixes into glibc 2.3.1...
http://sources.redhat.com/ml/libc-hacker/2002-09/msg00072.html
Is hppa building cleanly and passing all of make check from
current glibc cvs? If not you might want to push any
Randolph,
Okay. I kinda figured that was the case. If there were
any symbols and he had installed glibc 2.2.94, some breakage
would have surfaced. Sounds good. Once they get a hppa
build machine stablized on glibc 2.2.94, the hppa maintainers
may want to offer it up to Jakub Jelinek since preli
Carlos,
So hppa doesn't need any additional libgcc-compat code? Did you
try running the perl script I posted to see if there are any libgcc
symbols that are being left undefined in binaries?
http://sources.redhat.com/ml/libc-alpha/2002-09/msg00164.html
Just curious.
Ross,
Actually, no. Other arches can be effected. Currently work
on glibc 2.2.x in debian has been depreciated in favor of
work on glibc 2.3. In glibc 2.3, i386, ppc and ia64 currently clearly
have the libgcc-compat issue addressed. Other arches really should
be throughly tested. I have created
Jeff,
Well someone from each arch should run the perl script I wrote
to check for symbols that may require a libgcc-compat to be created
for their arch. We know i386, ia64 and ppc are fine. The rest should
check. To look at the binaries installed on their own machine they
can use the perl scrip
ndsym perl script by Jack Howarth <[EMAIL PROTECTED]>
# v 1.0.8 Sept. 8, 2002
#
# This program creates a table of symbols being resolved in libgcc_s.so.1
# as parsed.list. These symbols are then searched for in all the paths set
# below in the creation of the files.list. The program keeps a run
libgcc symbols. The tmpdir is cleaned out the
start each run but you will have to do something to script
archiving of the final.list and found.list after each call to
dpkgdeb-findsyms.pl.
Jack
#!/usr/bin/perl
# findsym perl script by Jack Howarth <[EMAIL PROTEC
Daniel,
No, the patch, glibc2.2.6-nice, never went into a release. It
was introduced into the 2.2.5-15 cvs and fortunately hasn't
migrated into the debian glibc 2.3 cvs yet. I have talked to
HJ about this one since it's his patch. He still likes the
concept but admits it unneccessary to have n
Zack,
Ulrich declines on this one for glibc 2.3. His reponse is...
---
Did anybody actually read the standard? The return after interrupt is a
'may' error. The implementation is correct.
- --
- ---.
Carlos,
Well actually the correct thing to do is to go ahead and
see what symbols you really need to be exporting from glibc
via libgcc-compat for run time resolution. I'll see if I
can puzzle out the form of such a script this weekend.
Jack
--
To UNSUBSCRIBE,
While I have no objection to moving straight to glibc 2.3,
there is still the libgcc-compat issue to be resolved on all
of the arches. One approach we can take is to have an arch
specific Build-Depends on whether the gcc should be >= 3.1
or < 3.1. The reason is that these problematic libgcc sym
Thanks for testing this on glibc 2.2.5. It has
now been determined that this is in fact a regression
in glibc 2.2.93 which has been testcased. Hopefully
a fix will follow shortly.
Jack
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe"
Carlos,
The problem with this issue is that it was only explored
gradually on libc-alpha so you'll not find one message that
entirely lays it out. Basically in gcc 3.1 a bunch of symbols
in libgcc were made .hidden. Before this change, gcc < 3.1 allowed
creation of shared libs that could be ree
Carlos,
I think you are looking in the wrong place. The libgcc symbols
in question, that were improperly exported from libgcc, were made
.hidden at gcc 3.1 and later. So if you were exporting libgcc symbols,
the binaries built with gcc 3.0 would definitely be impacted when these
symbols disapp
Jeff,
It appears that the breakage in the glibc 2.2.93 catgets/tst-catgets
test is due to sed breakage. Interestingly the problem appears to lie
in libc perhaps as we are unique in building sed with --with-regex=
which uses the libc regex instead of seds own regex.
Can someone with access t
Jeff,
At Ulrich's suggestion I took a look at the
sed program a source of our catgets/tst-catgets
failure. It seems to be the source as I can't
build it properly against gcc 3.2 now...
../sed/sed -n -f ../dc.sed < ./dc.inp >tmp.dc
make[2]: *** [dc] Error 139
make[2]: Leaving directory `/home/
Carlos,
You don't have to resort to the full blown assembly version of
libgcc-compat.S for hppa. You could just use the original version
that was written in c...it won't be optimized but it will suffice...
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/powerpc/Attic/libgcc-compat.c
Jeff,
Good. I see the error with gettext 0.10.40-8. I was worried
until I saw your message.
Jack
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Jeff,
So you're saying that on your build obj/catgets/tst-catgets.out is
properly an empty file? On my machine it is filled with error messages
such as...
expected "%s: Wert Feld
�%s� muss im Intervall %d...%d sein", got "Eintr�ge a
Jeff and Gotom,
Please do look through your log-test--linux to see
if you are getting failure on catgets/tst-catgets. Ulrich
thinks this may be due to a buggy gettext. Rawhide has
a heavily patched gettext 0.11.4 whereas we are on 0.11.5
in sid. So we may need this fixed by our gettext maintai
Jeff,
I suspect they indeed will need a sysdeps/hppa/divdi3.c.
I wouldn't be shy about taking this discussions directly to
the libc-alpha mailing list. Ulrich just released glibc 2.2.93
with the comment that he isn't getting any new bug reports.
So if you guys want this stuff fixed for glibc 2
Jeff and Gotom,
Could you see if you can reproduce...
http://sources.redhat.com/ml/libc-alpha/2002-09/msg00010.html
http://sources.redhat.com/ml/libc-alpha/2002-09/msg00011.html
...on any of the debian arches. The linuxthreads/tst-static-locale
test is only available upstream in glibc cvs c
Jeff and Gotom,
I'm not sure how many different arches you fellows are currently
working on at the moment but if you run into math test failures you can
help get those fixed for 2.3. I had about 220 or so all related to the
libm-test-ulps being stale on powerpc. If you have the glibc 2.2.92
in
Jeff,
I just rebuilt glibc 2.2.92-1 from a fresh pull of the
debian glibc-2.3 sandbox (with my ppc-libm-test-ulps.dpatch
added in to fully pass make check). I still am seeing no
problems with ld.so.cache here. Perhaps gotom can check it
on the same arch as you are using to see if he has breaka
Jeff and Gotom,
Could you please delete the file debian/ppc-memset.S
from the debian glibc-2.3 cvs? We don't need to be dragging
that around now as memset.S if fixed and fully functional on
ppc as of glibc 2.2.92 on ppc.
Thanks in advance.
Carlos,
I should have replied again to this thread last night. I went
ahead and installed the 2.2.92-1 packages and they work fine.
Now that I regenerated the libm-test-ulps on ppc as Jakub and
Ulrich request we also pass all of make check. I really wasn't that
concerned about stock glibc 2.2
Ulrich,
I have created a new sysdeps/powerpc/fpu/libm-test-ulps
file using the protocol documented in math/README.libm-test.
This libm-test-ulps was created on a Powermac G4/450 AGP
running debian ppc sid with glibc 2.2.92 plus debian patches,
binutils 2.13.90.0.4 and gcc 3.2.1pre (20020830 deb
Jeff,
I noticed one thing in my muddled attempts toward,
the finally successful, migration to glibc 2.2.92. We
may have an issue with a patch that was in glibc 2.2.5-15
debian cvs but not in current glibc-2.3 debian cvs.
I have been testing the libgcc-compat code recently
checked into glibc-2-
Jeff,
I am using the same debian glibc-2.3 cvs patches and
build scripts for glibc 2.2.92 and am having much more
luck here on debian ppc sid. After a muddled attempt
to create installable debian packages (always remember
to remove all the CVS crude from the build dir first, doh),
I got some
Well I am finally recovered from the failed attempt
to install the glibc 2.2.92-1 packages on debian ppc sid
this morning. It's my own fault for not paying attention
that the build directory still have CVS subdirs left from
the glibc-2.3 cvs pull. I have run the glibc-2.3 dir through
tar with -
Argh. I would be careful trying to install the glibc 2.2.92-1 packages.
I just nuked my system because dpkg didn't like all the CVS subdirs in
the installed packages. Now I need to create a rescue drive and try to
get dpkg to install the old glibcs back.
Jack
--
To
Gerhard,
Using find . -name '*out' -exec grep -H Fail {} \; in the
powerpc-linux/obj directory of the glibc 2.2.92 build I get
the following failures...and as I said before I suspect these
are related to the compiler warnings on those tests.
Jack
Ben,
Yes, it looks like it got bumped from libpthread-0.9.so to
libpthread-0.10.so. The Banner file that is placed in
~/debian-glibccvs/glibc-2.3/glibc-2.2.92/linuxthreads now cats..
linuxthreads-0.10 by Xavier Leroy
I'll see if I can figure how to correct for that and finish my
packaging.
Jeff,
The binary only install-info from texinfo 4.2 works fine here.
However now that the build proceeds further I can see a new
packaging problem...
install --mode=0755
/home/howarth/debian-glibccvs/glibc-2.3/powerpc-linux/install_root/lib/ld-2.2.92.so
/home/howarth/debian-glibccvs/glibc-2.
Jeff,
I'm not sure I understand you about the debian patches applied?
You are referring to patches to glibc right? In that case, I have
them all applied...
if [ ! -d patched ]; then mkdir patched; fi
trying to apply patch makeconfig ...
trying to apply patch locale-es_AR ...
trying to apply pa
Jeff,
As I said in my previous message, I have built the current
debian glibc 2.3 cvs and it passes make check fine. As you saw
I also have run into the install-info perl problem. However look
at the other message I just posted in debian-glibc. I believe
I have a hack around the install-info p
I am currently rebuilding debian glibc 2.3 cvs again to see if
this works but I am hopeful. After noticing that redhat uses a
binary version of install-info, I grabbed their texinfo-4.2 package
and applied their patches...
texinfo-3.12h-fix.patch
texinfo-fileextension.patch
texinfo-4.1-zlib
Good news...bad news. The good news is that I can take the current
debian glibc-2.3 cvs, drop in the glibc-2.2.92.tar.bz2 and
glibc-linuxthreads-2.2.92.tar.bz2, build it on debian ppc sid
against the new gcc-3.2-3.2.1-0pre1 and it passes make check
just as well as Franz Sirls builds do on entr
Well unless we get perl 5.80 fixed in sid, nobody is building
any glibc packages at all. Not unless they hack around install-info.
Jack
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROT
Gotom,
Have you tried to build glibc packages since the perl 5.80 upgrade?
I think we have some breakage in dpkg with install-info. On my
debian ppc sid machine I am seeing the following reproducible
failure...
/usr/bin/install -c -m 644 $file
/home/howarth/debian-glibc/glibc-2.2.5/powerpc
Jeff,
After debian/patches in the cvs is cleaned up, we ought
to take a minute and review the remaining patches. In particular
to identify if any of those patches are deemed worthy of
glibc-2-2-branch and see if we can get them in. Not so much
for glibc-2-2-branch itself, but to make sure the
1 - 100 of 126 matches
Mail list logo
