See a mirrored directory like http://apache.xfree.com.ar/apr/binaries/ for
the stuff that users normally see.
I'm planning to wipe these out.
--
Born in Roswell... married an alien...
http://emptyhammock.com/
+1
On Sun, Nov 17, 2013 at 7:47 PM, Jeff Trawick traw...@gmail.com wrote:
See a mirrored directory like http://apache.xfree.com.ar/apr/binaries/ for
the stuff that users normally see.
I'm planning to wipe these out.
--
Born in Roswell... married an alien...
http://emptyhammock.com
FYI; all packages which are replaced (e.g. 1.0, 1.1, as well as 0.9.12
where we have 0.9.13 available, etc) have been purged, they still reside
as always forever at http://archive.apache.org/dist/apr/.
Also the rpms/ppc/ got a much needed purge (only 1.0.0 builds existed
there.) If any committer
Hi,
Building APR gives a really strange binary sizes on Solaris.
$ gcc --version
gcc (GCC) 3.3.2
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
Mladen Turk wrote:
Hi,
Building APR gives a really strange binary sizes on Solaris.
$ gcc --version
gcc (GCC) 3.3.2
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or
On Wed, Oct 18, 2006 at 12:48:41PM +0200, Mladen Turk wrote:
Building APR gives a really strange binary sizes on Solaris.
...
produces the libapr-1.so.0.2.7 sized 3094060 bytes.
Debugging info, needs stripping (strip -x on Solaris IIRC).
joe
Davi Arnaut wrote:
Debugging symbols ? other library linked statically (expat ?) ?
It's APR ./configure make make install
Have you tried to strip ?
No. Like said it's default build for APR.
If the strip is needed (what ever that might be,
so please share some light) then it should be
Joe Orton wrote:
On Wed, Oct 18, 2006 at 12:48:41PM +0200, Mladen Turk wrote:
Building APR gives a really strange binary sizes on Solaris.
...
produces the libapr-1.so.0.2.7 sized 3094060 bytes.
Debugging info, needs stripping (strip -x on Solaris IIRC).
Can this be done within the APR
Davi Arnaut wrote:
Could you please strip it and see what happens ? It won't hurt.
I don't have a strip on the box.
Where can I find that? Is that something custom, or it comes
in by default?
Regards,
Mladen.
* Joe Orton
| In any case, it should be turned off by default thought.
|
| Most of the people who care about this are those who are redistributing
| binaries, which is a tiny minority of all those who build from source.
| For everyone else, it doesn't really matter, and getting useful
|
Davi Arnaut wrote:
Could you please strip it and see what happens ? It won't hurt.
OK.
/usr/ccs/bin/strip -x libapr-1.so.0.2.7 resizes the .so
to the much 'normal' size of 170616 bytes from default 3M.
Can the reason for that be a -g compile switch?
If so, do you have any idea how to
Mladen Turk wrote:
Davi Arnaut wrote:
Could you please strip it and see what happens ? It won't hurt.
OK.
/usr/ccs/bin/strip -x libapr-1.so.0.2.7 resizes the .so
to the much 'normal' size of 170616 bytes from default 3M.
Nice.
Can the reason for that be a -g compile switch?
If
On 10/18/06, Mladen Turk [EMAIL PROTECTED] wrote:
Can the reason for that be a -g compile switch?
If so, do you have any idea how to suppress it during
the build ?
CFLAGS=-O2 ./configure ...
If you don't specify any CFLAGS, autoconf defaults to -g -O2. -- justin
On 10/18/06, Joe Orton [EMAIL PROTECTED] wrote:
In any case, it should be turned off by default thought.
Most of the people who care about this are those who are redistributing
binaries, which is a tiny minority of all those who build from source.
For everyone else, it doesn't really matter,
Justin Erenkrantz wrote:
+1. We should stick with debug symbols by default.
So in general this relates to the windows .pdb files
embedded in the binary, correct? If so, then fine.
Those who are
doing binary releases can figure out how to run strip themselves...
The problem is that this
William A. Rowe, Jr. wrote:
At 04:14 AM 3/5/2002, you wrote:
To build APR is not that difficult. On the Windows platform you either
need MSVC or cygwin.
Please be advised;
the cygwin build is NOT a win32 platform build - it uses the cygwin emulation
layer, with all it's beauty and blemishes :)
Here's a better proposal: make a DLL available for download from
apr.apache.org.
That way there's no problem with people that don't want to buy MSVC
or compile using cygwin.
- Jason
--- William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
At 04:14 AM 3/5/2002, you wrote:
To build APR is not that
Hey all
Seems like the NSPR team make binaries available and prefer the
binaries to be used if you're just a user of the API. I saw no
binaries for APR on the site. Since I don't have MSVC++, is there any
interest in providing binaries for APR on the site?
Thanks
- Jason
Hi
To build APR is not that difficult. On the Windows platform you either
need MSVC or cygwin.
Since you already stated that you do not have MSVC you will need to install
cygwin. When you do that please make sure that you do a couple of
additional things:
1) Set the directories and paths
Since you are using Open Source tools might I also suggest that you use the
following IDE
http://www.bloodshed.net/devcpp.html
Christian Gross
At 01:05 05/03/2002 -0800, Jason Filby wrote:
Hey all
Seems like the NSPR team make binaries available and prefer the
binaries to be used if you're just
At 04:14 AM 3/5/2002, you wrote:
To build APR is not that difficult. On the Windows platform you either
need MSVC or cygwin.
Please be advised;
the cygwin build is NOT a win32 platform build - it uses the cygwin emulation
layer, with all it's beauty and blemishes :)
We would -certainly-
21 matches
Mail list logo
