Leonard den Ottolander пишет:
In the glibc shipped from RH I found interesting defines about removing
this dependence.
Any pointers (which files)? What exactly is it's bearing on this case?
Isn't removing the dependency enough?
Another case (after described here by Jindrich) may be same as in
Leonard den Ottolander пишет:
In the glibc shipped from RH I found interesting defines about removing
this dependence.
Any pointers (which files)? What exactly is it's bearing on this case?
Isn't removing the dependency enough?
Another case (after described here by Jindrich) may be same as in
Hi Andy,
On Wed, 2005-11-16 at 10:58 +0200, Andy Shevchenko wrote:
> In the glibc shipped from RH I found interesting defines about removing
> this dependence.
Any pointers (which files)? What exactly is it's bearing on this case?
Isn't removing the dependency enough?
> Another case (after desc
Leonard den Ottolander wrote:
Hi Roland,
On Tue, 2005-11-15 at 23:17 +0100, Roland Illig wrote:
If you insist on this fix, please put the "0 &&" at the beginning of the
line. Otherwise it's likely to be missed.
Please do :)
-#if !defined(HAVE_ISSETUGID) && ...
+#if 0 /* was: !defined(HAVE
Hi Roland,
On Tue, 2005-11-15 at 23:17 +0100, Roland Illig wrote:
> If you insist on this fix, please put the "0 &&" at the beginning of the
> line. Otherwise it's likely to be missed.
Please do :)
> Do you really think they will fix it?
Well who knows. I've subscribed to the slang user list,
Leonard den Ottolander wrote:
AFAICT it's not unusual to fix such issues with a minimal diff.
If you insist on this fix, please put the "0 &&" at the beginning of the
line. Otherwise it's likely to be missed.
I could remove the entire block, but I might just wait for this to be
fixed upstre
Hi Jindrich,
On Tue, 2005-11-15 at 22:22 +0100, Jindrich Novy wrote:
> __libc_enable_secure is not a function, but int.
Oops. Fixed the Changelog.
> The fix:
> http://savannah.gnu.org/cgi-bin/viewcvs/mc/mc/slang/slcommon.c.diff?r1=1.1&r2=1.2
> that is done is a bad hack that just confuses a read
Hi Jindrich,
On Tue, 2005-11-15 at 22:07 +0100, Jindrich Novy wrote:
> The __libc_enable_secure usage in slcommon.c is easy to fix as there's a
> sufficient workaround present in the code
I've already committed a similar patch. But thanks anyway.
Leonard.
--
mount -t life -o ro /dev/dna /genet
Hi Leonard,
On Tue, 2005-11-15 at 21:53 +0100, Leonard den Ottolander wrote:
> Hi Pavel, list,
>
> On Tue, 2005-11-15 at 14:22 -0500, Pavel Roskin wrote:
> > "nm mc" shows that the only symbol from GLIBC_PRIVATE is
> > __libc_enable_secure. Search for __libc_enable_secure finds it in two
> > pla
Hello Leonard, Pavel,
On Tue, 2005-11-15 at 21:05 +0100, Leonard den Ottolander wrote:
> Hi Pavel,
>
> On Tue, 2005-11-15 at 14:22 -0500, Pavel Roskin wrote:
> > "nm mc" shows that the only symbol from GLIBC_PRIVATE is
> > __libc_enable_secure. Search for __libc_enable_secure finds it in two
> >
Hi Pavel, list,
On Tue, 2005-11-15 at 14:22 -0500, Pavel Roskin wrote:
> "nm mc" shows that the only symbol from GLIBC_PRIVATE is
> __libc_enable_secure. Search for __libc_enable_secure finds it in two
> places:
>
> intl/dcigettext.c - it's only used if that file is compiled as part of
> libc, w
On Tue, 2005-11-15 at 21:05 +0100, Leonard den Ottolander wrote:
> He he. I see the same issue indeed exists with my 2005-11-10 CVS
> checkout + slang2. Any suggestions on how to fix this?
You are going the right thing :-)
Ask S-Lang developers.
--
Regards,
Pavel Roskin
___
Hi Pavel,
On Tue, 2005-11-15 at 14:22 -0500, Pavel Roskin wrote:
> "nm mc" shows that the only symbol from GLIBC_PRIVATE is
> __libc_enable_secure. Search for __libc_enable_secure finds it in two
> places:
>
> intl/dcigettext.c - it's only used if that file is compiled as part of
> libc, which i
On Tue, 2005-11-15 at 18:30 +0100, Leonard den Ottolander wrote:
> Hi Pavel,
>
> I assume this is caused by one of the recent changes you've made. I
> haven't seen this ever before. Installing an rpm build from a
> distchecked tarball from a few days ago fails with the following error:
>
> $ sudo
Hi Pavel,
I assume this is caused by one of the recent changes you've made. I
haven't seen this ever before. Installing an rpm build from a
distchecked tarball from a few days ago fails with the following error:
$ sudo rpm -Fv /usr/src/redhat/RPMS/i386/mc-4.6.1a-1.lj.i386.rpm
Password:
error: Fa
15 matches
Mail list logo
