On Thu, Feb 21, 2013 at 01:53:44PM -0500, Mark Saad wrote:
> All
> So Xin's patch works so far I see no unexpected issues; can I get a MFC ?
> Also on a unrelated MFC request would someone be willing to merge
> stable/7/sys/netinet/tcp_input.cr246999 into 6-STABLE . This cleanly
> applied and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/21/13 10:53, Mark Saad wrote:
> All So Xin's patch works so far I see no unexpected issues; can I
> get a MFC ? Also on a unrelated MFC request would someone be
> willing to merge stable/7/sys/netinet/tcp_input.cr246999 into
> 6-STABLE . Th
On Thu, Feb 21, 2013 at 01:53:44PM -0500, Mark Saad wrote:
> All
> So Xin's patch works so far I see no unexpected issues; can I get a MFC ?
> Also on a unrelated MFC request would someone be willing to merge
> stable/7/sys/netinet/tcp_input.cr246999 into 6-STABLE . This cleanly
> applied and
All
So Xin's patch works so far I see no unexpected issues; can I get a MFC ?
Also on a unrelated MFC request would someone be willing to merge
stable/7/sys/netinet/tcp_input.cr246999 into 6-STABLE . This cleanly
applied and I saw no issues.
On Wed, Feb 20, 2013 at 6:18 PM, Adrian Chadd wr
On 20 February 2013 12:01, Mark Saad wrote:
> Xin
> I am rebuilding now, I'll let you know how it works.
As I've said before, if someone wants to take ownership of 6.x and
backport changes / push them into STABLE_6, be my guest. Yahoo was
doing that for some unsupported old releases for a while.
Xin
I am rebuilding now, I'll let you know how it works.
On Wed, Feb 20, 2013 at 1:32 PM, Xin Li wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 02/20/13 09:29, Mark Saad wrote:
> > All I was wondering if anyone knows, off hand if SA-13:02/libc
&
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/20/13 09:29, Mark Saad wrote:
> All I was wondering if anyone knows, off hand if SA-13:02/libc
> applies to FreeBSD 6-STABLE and if it would be committed to the
> 6-STABLE branch ?
The patch itself won't apply, there were many
n Feb 20, 2013, at 6:29 PM, Mark Saad wrote:
>>
>>> All
>>> I was wondering if anyone knows, off hand if SA-13:02/libc applies to
>>> FreeBSD 6-STABLE and if it would be committed to the 6-STABLE branch ?
>>>
>>> --
>>> mark saad | n
>
> On Feb 20, 2013, at 6:29 PM, Mark Saad wrote:
>
> > All
> > I was wondering if anyone knows, off hand if SA-13:02/libc applies to
> > FreeBSD 6-STABLE and if it would be committed to the 6-STABLE branch ?
> >
> > --
> > mark saad | nones...@longcount
http://www.freebsd.org/security/#sup
6 has been EOL for a looong time.
So hmmm, guessing you won't see a patch.
On Feb 20, 2013, at 6:29 PM, Mark Saad wrote:
> All
> I was wondering if anyone knows, off hand if SA-13:02/libc applies to
> FreeBSD 6-STABLE and if it would be co
All
I was wondering if anyone knows, off hand if SA-13:02/libc applies to
FreeBSD 6-STABLE and if it would be committed to the 6-STABLE branch ?
--
mark saad | nones...@longcount.org
___
freebsd-hackers@freebsd.org mailing list
http
On Dec 4, 2012, at 1:24 AM, Myles C. Maxfield wrote:
> Hello, all,
> I'm interested in learning about the internals of how libc works, so I was
> hoping to link a test application with a version of libc that has debugging
> symbols (reading the raw sources only gets me so far
wheel by introducing an aligned version of
> malloc(3) called aligned_alloc(3), instead of posix_memalign(3). Instead
> of returning the allocation by reference, it returns the address, just
> like malloc(3).
> I'm MFCing this now, as it seems aligned_alloc(3) is n
GOT via absolute addressing and
> therefore does not need %ebx.
Doh, right.
Still, this manipulations can be removed, we just need to resolve
__error in some libc ctr. It is not very important after your patch,
because ABI is not much more regular, but I think removing additional
stack operatio
ther architectures, and there may be
> > more symbols that are exported but need not be.
> Sure, would you handle at least amd64 too ?
The below patch handles amd64.
I'm a bit annoyed that most of the syscall stubs are 17 bytes long now
and have the maximum 15 by
On Sat, Aug 25, 2012 at 12:16:55AM +0200, Jilles Tjoelker wrote:
> For some reason, libc exports the symbol .cerror (HIDENAME(cerror)),
> albeit in the FBSDprivate_1.0 version. It looks like there is no reason
> for this since it is not used from other libraries. Given that it cannot
>
For some reason, libc exports the symbol .cerror (HIDENAME(cerror)),
albeit in the FBSDprivate_1.0 version. It looks like there is no reason
for this since it is not used from other libraries. Given that it cannot
be accessed from C and its strange calling convention, it is rather
unlikely that
On Mon, May 2, 2011 at 8:57 AM, Arnaud Lacombe wrote:
> Hi,
>
> On Mon, May 2, 2011 at 8:13 AM, Martin Möller
> wrote:
>> Hello,
>>
>> Thanks for all the replies.
>> We have so far discovered the following suggetions for the parsing Problem:
>> Using:
>> o a tokenizer/parser is too much overhe
Hi,
On Mon, May 2, 2011 at 8:13 AM, Martin Möller
wrote:
> Hello,
>
> Thanks for all the replies.
> We have so far discovered the following suggetions for the parsing Problem:
> Using:
> o a tokenizer/parser is too much overhead for such a simple task
> o strchr, memchr is too low-level and
Hi,
Am 02.05.2011 16:41, schrieb Artem Belevich:
if(ptr&& (ptr=strstr(ptr," HTTP/1.1"))) /* find end of res */
Contrary to the comment in the code you're not checking for "HTTP/1.1"
at the end but you're checking for it *anywhere* in the string. While
it will occur at the end of val
For goodness sake, it's not even NP-complete.
char *start = strchr(line, ' ') + 1; char *end = strrchr(line, ' ');
char *ret;
*end = '\0';
ret = strdup(start);
*end = ' ';
return ret;
Obviously there's no error checking, but there you go. I don't see
what's inelegant about that.
This is C, use
On Mon, May 2, 2011 at 7:15 AM, Robert Schulze wrote:
> Hi,
>
> Am 02.05.2011 16:06, schrieb Artem Belevich:
>>
>> Second problem -- res on success will always be "" as you've just did
>> *ptr=0.
>
> thats right, the copy should look like:
>
> res=strdup(str+4);
>
>> Bzzt!
>>
>> Try it on "GET bla
Hi,
Am 02.05.2011 16:06, schrieb Artem Belevich:
Second problem -- res on success will always be "" as you've just did *ptr=0.
thats right, the copy should look like:
res=strdup(str+4);
> Bzzt!
>
> Try it on "GET blah_HTTP/1.1.1.1.1.1_whatever HTTP/1.1"
will return "blah_HTTP/1.1.1.1.1.1_w
On Mon, May 2, 2011 at 6:00 AM, Robert Schulze wrote:
> Hi,
>
> Am 02.05.2011 14:13, schrieb Martin Möller:
>>
>> Criteria:
>> o Receive the value of
>> o Check the Environment: Is really sourrounded by 'GET '
>> and
>> 'HTTP/1.1' ?!
>
> these quite simple criteria might be matched
Hi,
Am 02.05.2011 14:13, schrieb Martin Möller:
Criteria:
o Receive the value of
o Check the Environment: Is really sourrounded by 'GET ' and
'HTTP/1.1' ?!
these quite simple criteria might be matched by code like this one:
char *ptr=NULL;
char *res=NULL;
if(strstr(str,"GET
On Mon, May 02, 2011 at 02:13:11PM +0200, Martin Möller wrote:
> o strchr, memchr is too low-level and not elegant enough
Actually, you are looking for strstr.
Joerg
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listi
Hello,
Thanks for all the replies.
We have so far discovered the following suggetions for the parsing Problem:
Using:
o a tokenizer/parser is too much overhead for such a simple task
o strchr, memchr is too low-level and not elegant enough
o strtok would not even parse (tokenize) this
On Sun, May 01, 2011 at 04:45:14PM +0200, Martin M?ller wrote:
> Am 01.05.11 00:53 schrieb "Daniel O'Connor" unter :
>
> Thanks for your reply.
> Ok, another example. I try to parse a request, coming from a client in the
> form:
> GET HTTP/1.1.
>
> It is expected that can contain space char
On Sat, Apr 30, 2011 at 06:44:43PM +0200, Martin Möller wrote:
> This is my first email to this list, so hello to all members.
> The current version of sscanf, stops when a whitespace characters occurs in
> a string
> when the "%s" (string) type is used.
> The following code:
> char name [20], va
Am 01.05.11 00:53 schrieb "Daniel O'Connor" unter :
Thanks for your reply.
Ok, another example. I try to parse a request, coming from a client in the
form:
GET HTTP/1.1.
It is expected that can contain space characters (even if
its not the case in reality).
How would you do that with sscan
On 01/05/2011, at 2:14, Martin Möller wrote:
> outputs total garbage on my FreeBSD-7.0-RELEASE #0 amd64.
> Is there already a way to do this or should we release a new version of
> sscanf, e.g. called sscanfWS.
>
> This modified version would output: Test 2->Test 3.
I think it does what it shoul
Hi to all,
This is my first email to this list, so hello to all members.
The current version of sscanf, stops when a whitespace characters occurs in
a string
when the %s¹ (string) type is used.
The following code:
char name [20], value [20];
sscanf (³Test 2->Test 3², ³%s->%s², name, value)
prin
On Wednesday, February 02, 2011 01:04:15 pm Andrew Duane wrote:
> We are still using the FreeBSD 6 malloc routines, and are rather suddenly
> having a large number of problems with one or two of our programs. Before
> I dig into the 100+ crash dumps I have, I thought I'd see if anyone else
> has ev
We are still using the FreeBSD 6 malloc routines, and are rather suddenly
having a large number of problems with one or two of our programs. Before I dig
into the 100+ crash dumps I have, I thought I'd see if anyone else has ever
encountered this.
The problems all seem to stem from some case of
Hi,
A handful of source files in libc are missing time.h includes for
clock_* and timer_* functions, as well as related macros and other
bits defined by the POSIX 2008.1 spec and our manpages. The attached
patch makes libc more POSIX and requirements compliant with time.h and
stddef.h
El 2010. 06. 04. 17:34, Jilles Tjoelker escribió:
Patch is here: http://kovesdan.org/patches/iconv-libc.diff
There is a .include in iconv/Makefile.inc, what happens
if you take that out?
OMG, I overlooked that. It remained there from the original Makefile
that was used to build it
On Fri, Jun 04, 2010 at 12:58:34PM +0200, Gabor Kovesdan wrote:
> I'm trying to integrate the result of my last SoC work to the base
> system but I'm facing some difficulties with libc symbol versioning. I
> placed the iconv code into an iconv subdirectory inside src/lib/li
On Fri, 4 Jun 2010, Gabor Kovesdan wrote:
Hello folks,
I'm trying to integrate the result of my last SoC work to the base system but
I'm facing some difficulties with libc symbol versioning. I placed the iconv
code into an iconv subdirectory inside src/lib/libc and I added a Makef
Hello folks,
I'm trying to integrate the result of my last SoC work to the base
system but I'm facing some difficulties with libc symbol versioning. I
placed the iconv code into an iconv subdirectory inside src/lib/libc and
I added a Makefile and a symbol map, just like another par
On Fri, Apr 23, 2010 at 04:40:36PM +0200, Jilles Tjoelker wrote:
> The patch:
>
> Index: lib/libc/nls/msgcat.c
> ===
> --- lib/libc/nls/msgcat.c (revision 206760)
> +++ lib/libc/nls/msgcat.c (working copy)
this is not correct.
> Am I using a configuration that is not supposed to work (NFS mounted
> /usr/local with DHCP in particular), or should this be fixed in some
> other way?
The patch:
Index: lib/libc/nls/msgcat.c
===
--- lib
The changes to use NLS for strerror sometimes cause one of my virtual
machines to deadlock. This virtual machine runs 9-CURRENT, acquires its
IP address via DHCP (virtualbox host-only networking), has no default
route and has /usr/local and /usr/home NFS mounted.
When the DHCP lease expires such a
Jaakko Heinonen schrieb am 2010-03-26:
> On 2010-03-05, Jaakko Heinonen wrote:
> > I have updated the patch taking some of bde's comments into
> > account. The
> > new version also includes updates for namei(9) manual page.
> Yet another update:
> http://people.freebsd.org/~jh/patches/loo
On 2010-03-05, Jaakko Heinonen wrote:
> I have updated the patch taking some of bde's comments into account. The
> new version also includes updates for namei(9) manual page.
Yet another update:
http://people.freebsd.org/~jh/patches/lookup-root.4.diff
I have committed the relookup() part
On 2010-03-11, Alexander Best wrote:
> in sys/kern/vfs_syscalls.c:kern_rmdirat() there's still local code to check
> for "." and "/" after applying your patch. isn't this all being done by
> calling namei() now?
Looking at it quickly I think that the "." case is handled by lookup()
since r199137.
Jaakko Heinonen schrieb am 2010-03-11:
> On 2010-03-10, Alexander Best wrote:
> > could this panic have been triggered by the patch?
> It doesn't look like it's caused by the patch.
> > panic() at panic+0x15f
> > _mtx_lock_flags() at _mtx_lock_flags+0xc5
> > fdesc_allocvp() at fdesc_allocvp+0xbf
On 2010-03-10, Alexander Best wrote:
> could this panic have been triggered by the patch?
It doesn't look like it's caused by the patch.
> panic() at panic+0x15f
> _mtx_lock_flags() at _mtx_lock_flags+0xc5
> fdesc_allocvp() at fdesc_allocvp+0xbf
> fdesc_lookup() at fdesc_lookup+0x15c
>
> this wa
Jaakko Heinonen schrieb am 2010-03-05:
> On 2010-02-28, Jaakko Heinonen wrote:
> > > > http://people.freebsd.org/~jh/patches/lookup-root.diff
> I have updated the patch taking some of bde's comments into account.
> The
> new version also includes updates for namei(9) manual page.
could this pan
On 2010-03-06, Garrett Cooper wrote:
> >
> > http://people.freebsd.org/~jh/patches/lookup-root.2.diff
>
> 1. EBUSY's new definition doesn't look correct for rename(2) given
> POSIX's definition (
> http://www.opengroup.org/onlinepubs/009695399/functions/rename.html ):
>
> [EBUSY]
> [CX
On Thu, Mar 4, 2010 at 9:57 PM, Jaakko Heinonen wrote:
> On 2010-02-28, Jaakko Heinonen wrote:
>> > > http://people.freebsd.org/~jh/patches/lookup-root.diff
>
> I have updated the patch taking some of bde's comments into account. The
> new version also includes updates for namei(9) manual page.
ent of the pathname specified for the RENAME operation is
+.Ql \&. .
+.It Bq Er EEXIST
+The root directory
+.Pq Ql /
+was specified for the CREATE operation.
+.It Bq Er EBUSY
+The root directory
+.Pq Ql /
+was specified for the DELETE operation.
.It Bq Er EROFS
An attempt is made to modi
On Sun, 28 Feb 2010, Garrett Cooper wrote:
On Sun, Feb 28, 2010 at 5:11 PM, Alexander Best wrote:
i have a small test app to check {rm|mk}dir()'s errnos with certain args like
/, ., /proc and non-empty dirs. i'll submit it to this thread as soon as i
also add testcases for syscalls like rename
On Sun, 28 Feb 2010 18:26:05 -0800
Garrett Cooper wrote:
> On Sun, Feb 28, 2010 at 5:11 PM, Alexander Best wrote:
> > i have a small test app to check {rm|mk}dir()'s errnos with certain args
> > like
> > /, ., /proc and non-empty dirs. i'll submit it to this thread as soon as i
> > also add tes
On Sun, Feb 28, 2010 at 5:11 PM, Alexander Best wrote:
> i have a small test app to check {rm|mk}dir()'s errnos with certain args like
> /, ., /proc and non-empty dirs. i'll submit it to this thread as soon as i
> also add testcases for syscalls like rename(), unlink(), etc.
>
> most of the errno
i have a small test app to check {rm|mk}dir()'s errnos with certain args like
/, ., /proc and non-empty dirs. i'll submit it to this thread as soon as i
also add testcases for syscalls like rename(), unlink(), etc.
most of the errno codes returned after applying your patch look correct. i
wonder h
Bruce Evans said that the doesn't like this comment you added in your patchset
/*
* Check for "" which is a way of talking about the root directory.
* We can't provide a parent node for CREATE, DELETE and RENAME
* operations.
*/
and would like to keep "
[Moving discussion to -hackers. This is not directly related to the
original commit anymore.]
On 2010-02-26, Bruce Evans wrote:
> > http://people.freebsd.org/~jh/patches/lookup-root.diff
> This is in relookup(). I think relookup() is only called from rename(),
> so the failing case is unrea
3==
==4703== suppressed: 4,096 bytes in 1 blocks
Any ideas why the standard libraries are leaking like this? Is it
perhaps a bug with valgrind, or maybe FreeBSD automatically cleans up so
they took the cleanup out of their libc?
This particular leak is not at all a cause for concern.
Many pa
d: 0 from 0)
>
> Any ideas why the standard libraries are leaking like this? Is it
> perhaps a bug with valgrind, or maybe FreeBSD automatically cleans up so
> they took the cleanup out of their libc?
>
> FreeBSD 8.0 x86_64
>
From the valgrind FAQ
"suppressed" me
rerun with: -v
==4703== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Any ideas why the standard libraries are leaking like this? Is it
perhaps a bug with valgrind, or maybe FreeBSD automatically cleans up so
they took the cleanup out of their libc?
FreeBSD 8.0 x86_64
Hi,
> On Fri, 13 Nov 2009 00:18:49 -0500
> Garrett Wollman said:
wollman> Index: inet/inet_cidr_pton.c
wollman> ===
wollman> --- inet/inet_cidr_pton.c (revision 199242)
wollman> +++ inet/inet_cidr_pton.c (working c
On Fri, Nov 13, 2009 at 12:18:49AM -0500, Garrett Wollman wrote:
> If you have a moment, please take a look at the following patch. It
> contains some very minor fixes to various parts of libc which were
> found by the clang static analyzer. They fall into a few categories:
> 1)
If you have a moment, please take a look at the following patch. It
contains some very minor fixes to various parts of libc which were
found by the clang static analyzer. They fall into a few categories:
1) Bug fixes in very rare situations (mostly error-handling code that
has probably never
Henrique Almeida wrote:
> Hello,
>
> I've created a new project to build a compliant POSIX 2008 library. The
> goals of the project are to build a cross platform, easy to use library that
> will unify the POSIX implementation on all systems.
>
> Everybody i
Hello,
I've created a new project to build a compliant POSIX 2008 library. The
goals of the project are to build a cross platform, easy to use library that
will unify the POSIX implementation on all systems.
Everybody is welcome, specially "libc" develop
>>
>> Thanks,
>>
>> -Garrett
>>
>> References:
>>
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/124409 (not fully in PR
>>
>> database yet).
>
> Going once, going twice...
Hi Garrett :-)
When I wrote the original commen
On Wed, Apr 02, 2008 at 09:57:46AM -0400, Steven Kreuzer wrote:
> - (void) sprintf(fullname, "%s/%s", directory, name);
> + (void) snprintf(fullname, sizeof(filename), "%s/%s", directory, name);
Has a typo crawled in?
___
On Wed, Apr 02, 2008 at 06:27:25PM +0400, Andrew Pantyukhin wrote:
> On Wed, Apr 02, 2008 at 09:57:46AM -0400, Steven Kreuzer wrote:
> > - (void) sprintf(fullname, "%s/%s", directory, name);
> > + (void) snprintf(fullname, sizeof(filename), "%s/%s", directory, name);
>
On Wed, Apr 02, 2008 at 10:54:08PM +1100, Edwin Groothuis wrote:
> Greetings,
>
> I have make an attempt to upgrade the code in usr.sbin/zic and
> lib/libc/stdtime from tzcode2004 to tzcode2008a. So far so good: I
> have been able to apply most of the patches, it compiles and wh
Greetings,
I have make an attempt to upgrade the code in usr.sbin/zic and
lib/libc/stdtime from tzcode2004 to tzcode2008a. So far so good: I
have been able to apply most of the patches, it compiles and when
I rebooted the machine it came back and all applications started
up... Note that this is a
Upgrade:
1) Added IPv6 Support (need to be tested)
Cheers
Raffaele
Hi,
i added a native (client) Socks V4/V5 support inside FreeBSD libc
library. The work is based of my project (see
http://csocks.altervista.org) CSOCKS.
You can get it here:
http://csocks.altervista.org/download
Xin LI wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Raffaele De Lorenzo wrote:
Hi,
i added a native (client) Socks V4/V5 support inside FreeBSD libc
library. The work is based of my project (see
http://csocks.altervista.org) CSOCKS.
You can get it here:
http
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Raffaele De Lorenzo wrote:
> Hi,
> i added a native (client) Socks V4/V5 support inside FreeBSD libc
> library. The work is based of my project (see
> http://csocks.altervista.org) CSOCKS.
> You can get it here:
>
> http://
Hi,
i added a native (client) Socks V4/V5 support inside FreeBSD libc
library. The work is based of my project (see
http://csocks.altervista.org) CSOCKS.
You can get it here:
http://csocks.altervista.org/download/FreeBSD_libc.tar.gz
CHANGES:
I changed the file:
/usr/src/lib/libc
On Tue, 30 Jan 2007 18:00:46 +0900
[EMAIL PROTECTED] wrote:
> Hi,
>
> It seems that some symbols in libc is resolved by libc entities
> which is linked with RTLD to implement it.
>
> % nm -D ld-elf.so.1
> ...
> 000158ec T mmap
> c4fc W mprotect
> c4dc W
Hi,
It seems that some symbols in libc is resolved by libc entities
which is linked with RTLD to implement it.
% nm -D ld-elf.so.1
...
000158ec T mmap
c4fc W mprotect
c4dc W munmap
...
And running Flash9 with Symbol Versioning-aware Linux Plugin Wrapper
shows that mmap cannot be
memory management mechanism is required,
just like those of GNU libc and your new code.
The essence of this problem is that memory management of operating system
can affect working efficiency of CPU hardware greatly.
Actually, not only my friend's program can cause the problem, but also
many
李鑫 (LI Xin) wrote:
在 2006-08-15二的 02:38 +0300，Vladimir Kushnir写道：
On -CURENT amd64 (Athlon64 3000+, 512k L2 cache):
With jemalloc (without MY_MALLOS):
~/fdtd> /usr/bin/time ./fdtd.FreeBSD 500 500 1000
...
116.34 real 113.69 user 0.00 sys
With MY_MALLOC:
~/fdtd> /usr/bin/time
astonished by the real repeatable performance difference on
AMD Athlon XP 2500+ (1.8GHz, 512KB L2 Cache).
After hacking, I found that the problem is nested in malloc(3) of
FreeBSD libc.
Download the testing program: http://ftp.intron.ac/tmp/fdtd.tar.bz2
You may try to compile the program WITHOUT the
2500+ (1.8GHz, 512KB L2 Cache).
After hacking, I found that the problem is nested in malloc(3) of
FreeBSD libc.
Download the testing program: http://ftp.intron.ac/tmp/fdtd.tar.bz2
You may try to compile the program WITHOUT the macro "MY_MALLOC"
defined (in Makefile) to use malloc(3) p
在 2006-08-15二的 02:38 +0300，Vladimir Kushnir写道：
> On -CURENT amd64 (Athlon64 3000+, 512k L2 cache):
>
> With jemalloc (without MY_MALLOS):
> ~/fdtd> /usr/bin/time ./fdtd.FreeBSD 500 500 1000
> ...
> 116.34 real 113.69 user 0.00 sys
>
> With MY_MALLOC:
> ~/fdtd> /usr/bin/time ./fd
repeatable performance difference on
AMD Athlon XP 2500+ (1.8GHz, 512KB L2 Cache).
After hacking, I found that the problem is nested in malloc(3) of
FreeBSD libc.
Download the testing program: http://ftp.intron.ac/tmp/fdtd.tar.bz2
You may try to compile the program WITHOUT the macro "MY_MALLOC&quo
500+ (1.8GHz, 512KB L2 Cache).
>
> After hacking, I found that the problem is nested in malloc(3) of
> FreeBSD libc.
>
> Download the testing program: http://ftp.intron.ac/tmp/fdtd.tar.bz2
>
> You may try to compile the program WITHOUT the macro "MY_MALLOC"
> defi
nested in malloc(3) of
FreeBSD libc.
Download the testing program: http://ftp.intron.ac/tmp/fdtd.tar.bz2
You may try to compile the program WITHOUT the macro "MY_MALLOC"
defined (in Makefile) to use malloc(3) provided by FreeBSD 6.1.
Then, time the running of the binary (on Athlon XP 2500
tion to avoid linking itself against libssp. But
> this also prevents it from being linked against libgcc. Is it
> something harmful or not (in other words should I manually add -lgcc to
> LDFLAGS) ?
The problem with linking -lssp is that you normally want to aovid the
circular dependency w
> Make sure you patch the right place and _not_ the shared part. Does the
> attached patch work for you?
Yes, this worked, thank you ! This implies that libssp must be linked
with -nodefaultlibs option to avoid linking itself against libssp. But
this also prevents it from being linked against li
is email ?
>
> What you have been smoking? Dynamic libraries surely can depend on other
> objects :-) Just link libc with -lssp, given that libssp should be
> self-contained or any other library you want to have propolice in
> against ssp. Static libraries are not an issue either, si
hieve this. This is the purpose of this email ?
What you have been smoking? Dynamic libraries surely can depend on other
objects :-) Just link libc with -lssp, given that libssp should be
self-contained or any other library you want to have propolice in
against ssp. Static libraries are not an is
FreeBSD only provides a static libgcc, this will lead to have
> those compiled into all binaries, which is not something acceptable, IMO.
>
> Numerous patches porting ProPolice to newer versions of FreeBSD store
> these symbols in libc, so they are dynamically linked. That's what
e, IMO.
Numerous patches porting ProPolice to newer versions of FreeBSD store
these symbols in libc, so they are dynamically linked. That's what I
did too and it worked quite well.
However, Victor Balada Diaz tested the patch for me and reported that
it breaks Opera compiled for RELENG_4 becaus
In the last episode (Mar 03), Ashwin Chandra said:
> if we broke libc, and we cannot do anything at the prompt
> /libexec/ld-elf.so.1: Shared object "libc.so.5" not found..
>
> what is the quick fix for this?
Use the statically-linked binaries in /rescue/* to mount a remote
On Thu, 3 Mar 2005 12:02:50 -0800, Ashwin Chandra <[EMAIL PROTECTED]> wrote:
Hey guys,
if we broke libc, and we cannot do anything at the prompt
/libexec/ld-elf.so.1: Shared object "libc.so.5" not found..
what is the quick fix for this?
libmap.conf(5), but a real solution is to rec
Hey guys,
if we broke libc, and we cannot do anything at the prompt
/libexec/ld-elf.so.1: Shared object "libc.so.5" not found..
what is the quick fix for this?
also what is the correct way of adding names to system calls in libc so instead
of doing a syscall(445), we can actually
3).
Why not build the LinuxThreads port with the system's compiler? It's
not C++ code, so you can link it to code compiled with any compiler
(just like libc, which is built with gcc 2.95 as well). Just because
your application may require gcc 3.4 doesn't mean that all supporting
l
Hello all,
I'm forced to implement kernel threads in application not via LinuxThreads
library (because it doesn't compile on FreeBSD 4.10 with gcc-3.4.4, too
much errors while processing /usr/src code), but using rfork_thread(3).
And the main question I currently stuck on is which libc
Hi,
I am trying to compile a program that uses "initstate_r" from random(3) in
libc.
However this function only seems to exist in the linux version of libc.
Compare `man 3 random` on a linux box [1] which has "initstate_r" and
"initstate", whereas `man 3 random`
ays failed when php3 and php4 were
both enabled.
I spent long hours reading through commit logs since 4.6.2 and I found a
solution. It turns out that backing out the commits below and replacing
certain ld-elf and libc source files with the appropriate old versions
effectively solves php3+php4
t; http://www.onlamp.com/pub/a/bsd/2002/10/10/irix.html
>
> At the end of the article Emmanuel Dreyfus mentions:
>
> "One other interesting thing to note is that since
> that code was written, Jason Thorpe implemented signal
> trampolines provided by libc for NetBSD native
:
"One other interesting thing to note is that since
that code was written, Jason Thorpe implemented signal
trampolines provided by libc for NetBSD native
processes, thus adopting the same scheme IRIX used.
The libc provided signal trampoline was adopted in
NetBSD because it removes the ne
ut
EFence.
First I checked, that the return of the call to malloc() is
0x0, as it should be. This was the case, and this case is
also handled in ircd's code. The process is not aborted, though.
When I continued in the debugger, the process dies soon
with the strange error in isatty(). Again
1 - 100 of 279 matches
Mail list logo
