Apache cross compile on arm - apache

When I run "./configure --host=arm-linux --prefix=/sdcard/apr-util --with-apr=/sdcard/apache/apr --with-mysql=/sdcard/mysql".
It appears "the --with-apr parameter is incorrect. It must specify an install prefix, a build directory, or an apr-config file."
How can I solve this problem?Thanks.

You want to use --with-included-apr and put it in srclib/apr and srclib/apr-util beneath the httpd source package.

Related

How to connect Dlib to a package ? Error “Could not find the required component ‘libdlib’ “

I want to add this package to my workspace(http://wiki.ros.org/ipa_room_segmentation), so I downloaded it and put it into Myworkspace/src. Then I compiled my workspace, an error occurred like this:
Could not find a package configuration file provided by "libdlib" with any of the following names:
libdlibConfig.cmake
libdlib-config.cmake
Add the installation prefix of "libdlib" to CMAKE_PREFIX_PATH or set
"libdlib_DIR" to a directory containing one of the above files. If
"libdlib" provides a separate development package or SDK, be sure it has
been installed.
Then I have tried some others answers, install the dlib followed this page:https://www.learnopencv.com/install-dlib-on-ubuntu/
But error still there.
It that I need to connect something about the dlib to my src/CMakelist.txt?
Nice! I’ve found a method to crack this nut. All u have to do is using this line:
sudo apt-get install ros-kinetic-libdlib
PS: if u use another version of ROS, replace the “kinetic”.
This method can solve many problems Which begin with “could not find ...”,u just need to put the missing one after :
sudo apt-get install ros-kinetic-

How to install a FindXXX.cmake to a correct location?

I am developing a library which uses CMake to control it. It would be good to provide a "FindXXX.cmake" which locates the library and header files. This file would enable the users to use the command "find_package(XXX)" to find my library.
However, I don't know how to install my lib's "FindXXX.cmake" to an correct location. I failed to find a CMake's build-in mechanism to install a "FindXXX.cmake". In addition, CMake's variable "CMAKE_MODULE_PATH" is a list of directories, so I cannot install according to that vairable because I cannot decide which specific directory to use.
If the copy of CMake is installed to a standard location(i.e. use no prefix etc) then this can be done by placing the file in /usr/share/cmake/Modules/ directory.
If you are going to supply a bundle probably you can add some commands to check if the cmake is available. if yes you can check for cmake --system-information|grep _INCLUDED_SYSTEM_INFO_FILE value from that to get modules directory.
Otherwise there's no way you can do that.
A workaround can be done i.e. if there is a binary in your bundle then you can add a command line option for placing this file.

Where does autoconf's AC_CHECK_HEADERS verify the header files?

I am having trouble with compiling one of the open source libraries (libopekele OpenID lib).
The problem is I don't have sudo access on the system where I need to compile this.
Ran the configure. It complained of missing htmltidy lib.
Installed the htmltidy at a non-standard path /home/geekgod (as I dont have access to the /usr and /usr/local).
Now the problem is how do I make the configure script of libopekele to pick the the headers from /home/geekgod/include.
Poking into the configure.ac script of libopkele, it is using AC_CHECK_HEADERS to search for tidy.h or tidy/tidy.h.
I am pretty sure it is looking for these at standard location (/usr/include).
How do I add /home/geekgod to the standard include dir?
try this:
./configure CPPFLAGS=-I/home/geekgod/include --prefix=... --etc

Why does the building from Binary files do not require Root access?

When I am in my dept's server, I cannot use commands such as "apt-get install nethack". I have to build the nethack from Binary files to get it working, at least so I have been told. I cannot understand the reason. Why do I need to build things from binaries? Why is the use of the commands, such as "apt-get", forbidden? Why do I not need Root access to build from binaries?
apt-get is a system-level command that installs packages for all users.
If you download and compile, you are only creating local "copies" of the binaries, not system-wide. If you tried to complete the install process with make install this would most likely fail because you do not have sufficient privileges to install the program for all users' access (same reason you can't run apt-get install)
When you compile a program from source, you can give it the '--prefix=~/'. This causes it to install relative to your own home directory (so binary programs typically end up in '~/bin', man pages in '~/man' etc). This poses no problems because you already have permission to write here.
Apt-get on the other hand installs the packages in the global filesystem ('/bin/', '/usr/bin/', etc), which can impact other users and so, quite rightly, require administrative access.
If you want to install some program you can use the command
apt-get source app-name
This will work even if you are not root since it only fetch the source code to the app-name and put it in the current directory, which is easier than having to track down the source and there is a better chance to get it work, since you download the version that should work on your system.
Alternatively you should bug your sysadmin to install the programs you need, since it is his job (and if you need them, chances are that the rest of your team does too).
Because apt-get will install a program system wide.
The locations to which apt-get writes installed files (/bin, /usr/bin, ...) are restricted to root access. I imagine that when you build from source you're not executing the install step of the bulid. You're going to need to set a prefix for the installation such that the packages end up somewhere you can write. This thread talks a bit about setting prefixes for apt-get and you'll probably want to set your prefix to something like
~/software/
and then add the resulting bin directories to your PATH.

Can you compile Apache HTTP Server and redeploy its binaries to a different location?

As part of our product release we ship Apache HTTP Server binaries that we have compiled on our (UNIX) development machine.
We tell our clients to install the binaries (on their UNIX servers) under the same directory structure that we compiled it under. For some clients this is not appropriate, e.g. where there are restrictions on where they can install software on their servers and they don't want to compile Apache themselves.
Is there a way of compiling Apache HTTP Server so its installation location(s) can be specified dynamically using environment variables ?
I spent a few days trying to sort this out and couldn't find a way to do it. It led me to believe that the Apache binaries were hard coding some directory paths at compilation preventing the portability we require.
Has anyone managed to do this ?
I think the way to do(get around) this problem is to develop a "./configure && make" script that your client uses to install, specify and compile the binaries. That would offcourse require that the client has all the source-code installed on his server or you can make it available on an NFS share.
If you are compiling Apache2 for a particular location but want your clients to be able to install it somewhere else (and I'm assuming they have the same architecture and OS as your build machine) then you can do it but the apachectl script will need some after-market hacking.
I just tested these steps:
Unpacked the Apache2 source (this should work with Apache 1.3 as well though) and ran ./configure --prefix=/opt/apache2
Ran make then sudo make install to install on the build machine.
Switch to the install directory (/opt/apache2) and tar and gzip up the binaries and config files. I used cd /opt/apache2; sudo tar cf - apache2 | gzip -c > ~/apache2.tar.gz
Move the tar file to the target machine. I decided to install in /opt/mynewdir/dan/apache2 to test. So basically, your clients can't use rpm or anything like that -- unless you know how to make that relocatable (I don't :-) ).
Anyway, your client's conf/httpd.conf file will be full of hard-coded absolute paths -- they can just change these to whatever they need. The apachectl script also has hard coded paths. It's just a shell script so you can hack it or give them a sed script to convert the old paths from your build machine to the new path on your clients.
I skipped all that hackery and just ran ./bin/httpd -f /opt/mynewdir/dan/conf/httpd.conf :-)
Hope that helps. Let us know any error messages you get if it's not working for you.
I think the way to do(get around) this problem is to develop a "./configure && make" script that your client uses to install, specify and compile the binaries. That would offcourse require that the client has all the source-code installed on his server or you can make it available on an NFS share.
Not to mention a complete build toolchain. These days, GCC doesn't come default with most major distributions. Wouldn't it be sane to force the client to install it to /opt/my_apache2/ or something like that?
#Hissohathair
I suggest 1 change to #Hissohathair's answer.
6). ./bin/httpd -d <server path> (although it can be overridden in the config file)
In apacheclt there is a variable for HTTPD where you could override to use it.