Daniel Jacobowitz wrote:
On Thu, Jul 31, 2003 at 01:14:33AM +0100, Philip Blundell wrote:
On Sun, 2003-07-27 at 02:41, Gianluigi Tiesi wrote:
This makes impossible to statically link a program using
gethostname/byname etc. since it uses dlopen and
need .so files, ld-so and libc.so.
D
On Thu, Jul 31, 2003 at 01:14:33AM +0100, Philip Blundell wrote:
> On Sun, 2003-07-27 at 02:41, Gianluigi Tiesi wrote:
> > This makes impossible to statically link a program using
> > gethostname/byname etc. since it uses dlopen and
> > need .so files, ld-so and libc.so.
>
> Doesn't --enable-stati
Jeff Bailey wrote:
On Thu, Jul 31, 2003 at 02:55:44AM +0200, Gianluigi Tiesi wrote:
Right now I dunno if --enable-static-nss means also for .so files...
I'll try and post restults about this. Anyway you can make a quick
rebuild in static mode, after normail install into debian/stuff and
then ins
On Thu, Jul 31, 2003 at 02:55:44AM +0200, Gianluigi Tiesi wrote:
> Right now I dunno if --enable-static-nss means also for .so files...
> I'll try and post restults about this. Anyway you can make a quick
> rebuild in static mode, after normail install into debian/stuff and
> then install only mis
Philip Blundell wrote:
On Sun, 2003-07-27 at 02:41, Gianluigi Tiesi wrote:
This makes impossible to statically link a program using
gethostname/byname etc. since it uses dlopen and
need .so files, ld-so and libc.so.
Doesn't --enable-static-nss actually disable the normal NSS mechanism?
Thi
On Sun, 2003-07-27 at 02:41, Gianluigi Tiesi wrote:
> This makes impossible to statically link a program using
> gethostname/byname etc. since it uses dlopen and
> need .so files, ld-so and libc.so.
Doesn't --enable-static-nss actually disable the normal NSS mechanism?
This switch is really just
Daniel Jacobowitz wrote:
On Thu, Jul 31, 2003 at 01:14:33AM +0100, Philip Blundell wrote:
On Sun, 2003-07-27 at 02:41, Gianluigi Tiesi wrote:
This makes impossible to statically link a program using
gethostname/byname etc. since it uses dlopen and
need .so files, ld-so and libc.so.
On Thu, Jul 31, 2003 at 01:14:33AM +0100, Philip Blundell wrote:
> On Sun, 2003-07-27 at 02:41, Gianluigi Tiesi wrote:
> > This makes impossible to statically link a program using
> > gethostname/byname etc. since it uses dlopen and
> > need .so files, ld-so and libc.so.
>
> Doesn't --enable-stati
Jeff Bailey wrote:
On Thu, Jul 31, 2003 at 02:55:44AM +0200, Gianluigi Tiesi wrote:
Right now I dunno if --enable-static-nss means also for .so files...
I'll try and post restults about this. Anyway you can make a quick
rebuild in static mode, after normail install into debian/stuff and
then i
On Thu, Jul 31, 2003 at 02:55:44AM +0200, Gianluigi Tiesi wrote:
> Right now I dunno if --enable-static-nss means also for .so files...
> I'll try and post restults about this. Anyway you can make a quick
> rebuild in static mode, after normail install into debian/stuff and
> then install only mis
Philip Blundell wrote:
On Sun, 2003-07-27 at 02:41, Gianluigi Tiesi wrote:
This makes impossible to statically link a program using
gethostname/byname etc. since it uses dlopen and
need .so files, ld-so and libc.so.
Doesn't --enable-static-nss actually disable the normal NSS mechanism?
Th
On Fri, 2003-07-25 at 16:49, Jeff Bailey wrote:
> On Fri, Jul 25, 2003 at 03:39:34PM +0200, Johan Walles wrote:
>
> > I would like to have an i686 optimized glibc package. The reason is
> > glibc is what is taking up the most time (23%) during my boot
> > sequence:
>
> Can you contrast this agai
On Sun, 2003-07-27 at 02:41, Gianluigi Tiesi wrote:
> This makes impossible to statically link a program using
> gethostname/byname etc. since it uses dlopen and
> need .so files, ld-so and libc.so.
Doesn't --enable-static-nss actually disable the normal NSS mechanism?
This switch is really just
Processing commands for [EMAIL PROTECTED]:
> reassign 203543 libc6
Bug#203543: illegal instruction triggered by grep inside ld-linux.so.2
Bug reassigned from package `libc' to `libc6'.
> thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system admini
On Fri, 2003-07-25 at 16:49, Jeff Bailey wrote:
> On Fri, Jul 25, 2003 at 03:39:34PM +0200, Johan Walles wrote:
>
> > I would like to have an i686 optimized glibc package. The reason is
> > glibc is what is taking up the most time (23%) during my boot
> > sequence:
>
> Can you contrast this agai
Processing commands for [EMAIL PROTECTED]:
> reassign 203543 libc6
Bug#203543: illegal instruction triggered by grep inside ld-linux.so.2
Bug reassigned from package `libc' to `libc6'.
> thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system admini
Repository: glibc-package/debian
who:jbailey
time: Wed Jul 30 09:29:39 MDT 2003
Log Message:
Update changelog with silly quip and final release date
Files:
changed:changelog
Repository: glibc-package/debian
who:jbailey
time: Wed Jul 30 09:29:39 MDT 2003
Log Message:
Update changelog with silly quip and final release date
Files:
changed:changelog
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAI
On Wed, 2003-07-30 at 01:18, Daniel Jacobowitz wrote:
> None here. Let's move forward.
Okay, great. Gotom, will you take care of building a new source
package? Let's try to build binaries for as many architectures as
possible in the next six hours.
p.
On Wed, 2003-07-30 at 01:18, Daniel Jacobowitz wrote:
> None here. Let's move forward.
Okay, great. Gotom, will you take care of building a new source
package? Let's try to build binaries for as many architectures as
possible in the next six hours.
p.
--
To UNSUBSCRIBE, email to [EMAIL PROT
Processing commands for [EMAIL PROTECTED]:
> merge 203322 203324
Bug#203322: python2.2: Python fails with illegal instruction during postinst on
sparc32
Bug#203324: libc6: __strtod_internal fails with illegal instruction on sparc32.
Merged 203322 203324.
> thanks
Stopping processing here.
Pleas
[EMAIL PROTECTED] (Harald Nordgård-Hansen) writes:
> In addition, there seems to be changes in how hardware multiplication
> and division is handled (umul/udiv/smul/sdiv). In 2.4.21-rc2,
> do_user_muldiv is only called for sun4 and sun4c architectures, while
> it is called unconditionally in 2.4.2
Processing commands for [EMAIL PROTECTED]:
> merge 203322 203324
Bug#203322: python2.2: Python fails with illegal instruction during postinst on sparc32
Bug#203324: libc6: __strtod_internal fails with illegal instruction on sparc32.
Merged 203322 203324.
> thanks
Stopping processing here.
Please
[EMAIL PROTECTED] (Harald Nordgård-Hansen) writes:
> In addition, there seems to be changes in how hardware multiplication
> and division is handled (umul/udiv/smul/sdiv). In 2.4.21-rc2,
> do_user_muldiv is only called for sun4 and sun4c architectures, while
> it is called unconditionally in 2.4.2
24 matches
Mail list logo
