Why not just use apt-get source to get the source package of nginx; wget
the
latest nginx; copy the debian/ directory from the source package into
the
new nginx directory; edit the (dch) changelog, control file, etc;
rebuild
the package (debuild -rfakeroot), and install with dpkg?
That’s what I do, anyway. I recommend similar procedure with any
software
package – you can even use dh_make to create the debian/ directory for
any
particular source directory. Try this guide out: http://david415.wordpress.com/2008/09/10/customdebianopensshpackagebuild/which
tells you how to make the debian package for latest openssl from
scratch - what I mentioned above is how to do it from the existing
package,
which is what you want in this case because it has all the init.d files
and
such for you!
There should be plenty of information around the net on building custom
debian packages, if you have trouble finding it, try checking out
debian-mentors (they have mailing list and IRC).
Why not just use apt-get source to get the source package of nginx; wget the
latest nginx; copy the debian/ directory from the source package into the
new nginx directory; edit the (dch) changelog, control file, etc; rebuild
the package (debuild -rfakeroot), and install with dpkg?
I actually just do this. the .deb installs but issues warnings but it
does work well enough. but I do want to learn how to properly roll a
.deb someday
ensure that there is only one -O in CFLAGS and that it is -O2
When we use --with-cc-opt= to specify any alternative -On C compiler
optimization, there seems to be a bug (or is it a designed feature?) in
nginx’s ./configure that leads to the following line in the created
objs/Makefile file:
Why not just use apt-get source to get the source package of nginx; wget
the latest nginx; copy the debian/ directory from the source package
Come on, with a new nginx 0.7.4x coming out every day?
I don’t know what list you’re on that I’m not but I’d love to see the
daily
nginx release list ;).
The reported procedure is a faster and gets the job done rather well.
Neither procedure is any faster than the other (both can be scripted
down to
one invocation and the configure/build process will take the same amount
of
time!), but the original method appears to get the job done rather
well -
if you don’t care about possibly breaking your debian installation.
Personally, I like things to be easy to inspect/add/remove/update with
the
tools that are built into the distrobution. This is not to say your
method
is “wrong” or even that it will break anything; I merely offer another
way
to do things more in-line with the way other things are done in the
distrobution.
$ dpkg -l | grep nginx
ii nginx 0.7.44-1 small, but very
powerful
and efficient web server
On Mon, Mar 23, 2009 at 09:56:45PM +0000, Mark A. wrote:
CFLAGS = -O -pipe -O -W -Wall -Wpointer-arith -Wno-unused-parameter
to clean the other instances of -O.
From man cc:
" -O2 Optimize even more.
(…)
As compared to -O, this option increases both compilation time and the
performance of the generated code."
As I understand gcc uses the lastest -O option, therefore -O -O2 is the
same
as -O2. Also you may disable optimizations using -O -O0. As to -O2
itself,
I believe you would not see any significant changes in nginx with -O2
if compared with just -O. However, -O0 vs -O change is dramatically.
If you build something by hand, use program tuned specially for this:
make,
even with the single target. make has one excellent feature: it always
tests
a program exit code and stops execution if the program has failed.
as -O2. Also you may disable optimizations using -O -O0. As to -O2 itself,
I believe you would not see any significant changes in nginx with -O2
if compared with just -O. However, -O0 vs -O change is dramatically.
If you build something by hand, use program tuned specially for this: make,
even with the single target. make has one excellent feature: it always tests
a program exit code and stops execution if the program has failed.
You mean make a “make nginx” instead of ./build-nginx ?
If you build something by hand, use program tuned specially for this: make,
even with the single target. make has one excellent feature: it always tests
a program exit code and stops execution if the program has failed.
You mean make a “make nginx” instead of ./build-nginx ?
As I understand gcc uses the lastest -O option, therefore -O -O2 is the same
as -O2.
As far as I know in several Linux systems it is.
But nginx should not rely on that to cope with a less than optimal
./configure that is generating too much flags. I wonder, is it doing the
same with other flags?
Also you may disable optimizations using -O -O0. As to -O2 itself,
I believe you would not see any significant changes in nginx with -O2
if compared with just -O. However, -O0 vs -O change is dramatically.
On Tue, Mar 24, 2009 at 09:02:43AM +0000, Mark A. wrote:
Igor S. wrote:
As I understand gcc uses the lastest -O option, therefore -O -O2 is the
same
as -O2.
As far as I know in several Linux systems it is.
This is gcc’s feature, but not Linux’s one.
But nginx should not rely on that to cope with a less than optimal
./configure that is generating too much flags. I wonder, is it doing the
same with other flags?
But nginx should not rely on that to cope with a less than optimal
./configure that is generating too much flags. I wonder, is it doing the
same with other flags?
I do not understand the question.
Does the nginx ./configure script have a procedure to ensure that the
same flag does not get added (with different values) several times in
the same compiler line?
If not, how does ./configure select the last (and relevant) instance of
each flag entered in a compiler line?
This is not to say your method is “wrong” or even that it will break anything;
I merely offer another way to do things more in-line with the way
other things
are done in the distribution.
