APR binaries
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/
Re: APR binaries
+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/ -- Eric Covener cove...@gmail.com
Purged apr/binaries/.../* of stale files
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 wants to generated fresh ppc rpm's you would enjoy small but appreciative fan club. (Unfortunately, with a little help from sctemme I managed to nuke my ppc-linux attempting a new osx back in AC-EU, and haven't had time to rebuild it since.) Bill
Strange size of produced APR binaries on Solaris
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 PURPOSE. $ uname -a SunOS dev12.qa.atl.jboss.com 5.9 Generic_118558-25 sun4u sparc SUNW,Sun-Fire-V210 The APR is 1.2.7, and a simple ./configure --prefix=/foo/bar make make install produces the libapr-1.so.0.2.7 sized 3094060 bytes. Now, is that normal? It is twice the size then any other platform. For example the libcrypto from OpenSSL is usually double the size then APR on any platform (even Solaris 10 x86), but on sparc it's the half the size 1427960 bytes compared with apr. Anyone knows what might be the reason, and why the produced binaries are four times larger then expected? Regards, Mladen.
Re: Strange size of produced APR binaries on Solaris
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 FITNESS FOR A PARTICULAR PURPOSE. $ uname -a SunOS dev12.qa.atl.jboss.com 5.9 Generic_118558-25 sun4u sparc SUNW,Sun-Fire-V210 The APR is 1.2.7, and a simple ./configure --prefix=/foo/bar make make install produces the libapr-1.so.0.2.7 sized 3094060 bytes. Now, is that normal? It is twice the size then any other platform. For example the libcrypto from OpenSSL is usually double the size then APR on any platform (even Solaris 10 x86), but on sparc it's the half the size 1427960 bytes compared with apr. Anyone knows what might be the reason, and why the produced binaries are four times larger then expected? Debugging symbols ? other library linked statically (expat ?) ? Have you tried to strip ? Also you can objdump -h and diff it's output to compare the size of each section with a older normal .so. -- Davi Arnaut
Re: Strange size of produced APR binaries on Solaris
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
Re: Strange size of produced APR binaries on Solaris
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 the part of the make thought. Also you can objdump -h and diff it's output to compare the size of each section with a older normal .so. Don't get it. What is 'older normal .so' I'm trying to build the APR from the sources. Regards, Mladen.
Re: Strange size of produced APR binaries on Solaris
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 build itself, unless something like --enable-maintainer-mode is defined, that IMHO should have debugging turned on? Or is this genuine Solaris? In any case, it should be turned off by default thought. Regards, Mladen.
Re: Strange size of produced APR binaries on Solaris
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.
Re: Strange size of produced APR binaries on Solaris
* 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 | backtraces is far better than burning a bit of disk space. .. and a lot of those distributing binaries are distributing debug symbols as well, so having the unstripped binaries there is good. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Strange size of produced APR binaries on Solaris
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 suppress it during the build ? Regards, Mladen.
Re: Strange size of produced APR binaries on Solaris
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 so, do you have any idea how to suppress it during the build ? Hack configure.in to remove the flag for your platform or use your own CFLAGS. -- Davi Arnaut
Re: Strange size of produced APR binaries on Solaris
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
Re: Strange size of produced APR binaries on Solaris
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, and getting useful backtraces is far better than burning a bit of disk space. +1. We should stick with debug symbols by default. Those who are doing binary releases can figure out how to run strip themselves... -- justin
Re: Strange size of produced APR binaries on Solaris
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 'howto' was hard to find, and requires a manual intervention that could be either explained or defined. I'll try adding a line inside README.dev about that. Regards, Mladen.
Re: APR Binaries
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 :) hmm.. didn't Borland release their C compiler for free a while ago? any idea on if Borland would read MSVC's makefile.win and work ? ..Ian We would -certainly- entertain the mingw32 patches to build the native win32 binaries based on mingw. Admittedly, that may be more difficult with the native APIs we use internally, but I suspect it's doable. I'll be happy to review any mingw build script here, just follow the usual guidelines [diff -u3, prefer cvs diff -u3 against the current tree.] Bill
Re: APR Binaries
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 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- entertain the mingw32 patches to build the native win32 binaries based on mingw. Admittedly, that may be more difficult with the native APIs we use internally, but I suspect it's doable. I'll be happy to review any mingw build script here, just follow the usual guidelines [diff -u3, prefer cvs diff -u3 against the current tree.] Bill __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/
APR Binaries
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 __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/
Re: APR Binaries
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 correctly. Make sure that the UNIX tools get a chance first in the path. 2) Download some additional GNUWIN UNIX tools (cygwin tools sometimes crash) specifically gawk for Win32. Then you can build like any ol'Unix platform (Just tested on my box). Hope that helps Christian 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 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 __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/
Re: APR Binaries
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 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 __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/
Re: APR Binaries
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- entertain the mingw32 patches to build the native win32 binaries based on mingw. Admittedly, that may be more difficult with the native APIs we use internally, but I suspect it's doable. I'll be happy to review any mingw build script here, just follow the usual guidelines [diff -u3, prefer cvs diff -u3 against the current tree.] Bill
