PuppyThis forum is for the discussion of Puppy Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Installation
------------
./configure
make
make install
Code:
# ./configure
checking for a BSD-compatible install... /usr/bin/ginstall -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for g++... g++
checking for C++ compiler default output file name... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking for pcap_open_live in -lpcap... yes
checking for pthread_mutex_lock in -lpthread... yes
checking for libnet_init_packet in -lnet... no
configure: error: libnet0 (dev) is required for this program
Probably no. First of all, make sure that your distro (Puppy here I guess) does not provide libnet, it's always better to install software from official distro repository than doing it manually. If you're sure that you have to install libnet by hand do this after compiling it:
Code:
sudo make install
It will install a library on your system, now you can try compiling program you tried in your first post.
In practice, I don't recommend using pure 'make install' solution. It will be hard to remove a library installed that way and it will not be shown in the list of installed packages. It would be better to create a system package from it and install it as all other packages.
Libraries are not executables - you cannot run them. They are "shared objects" and are loaded by executables on demand. Now when you installed libnet its .so binary is already on your system - probably in /usr/local/lib/libnet.so. You can now recompiling your original program.
To parallel what average_user and pan64 are saying, the process of "make" followed by "make install" and typically you may do "sudo make install" however I sense that you're root when I see the "#" prompt anyways.
Either case, the "make install" portion should resolve placing the executable into a common system path, maybe /bin, /sbin, /usr/bin, or /usr/sbin, or it may choose to place it in a custom directory of it's own choice. At which point their README or other documentation may inform you to add that executable tree to your path variable.
I think you're understanding that the ./configure step ensures that your environment and machine are properly set up and contain the proper prerequisites to be able to build the project. The make step performs the actual compile and link. And the make install step sets it up for use, and that would be to install a library if it was a library, or to place the executable into the intended destination directory.
Now wait a minute. Sorry I thought you were all set. Why give up if you are very close?
First thing was you needed to get the libnet library compiled and installed. I kind of figured when you said you needed the ddosim that you had completed getting the library, and then got back to ./configure, make, and make install of your original application and been successful.
After completing the libnet compile and install ... firstly, did you get libnet compiled and installed?
And then after that you'd next go back to the original actions to build what you first were building, which likely gives you ddosim. From what I'm seeing, it seems as if you did do that next step.
How about typing "which ddosim"?
Or if you feel there may be additional stuff after that name string, and because you typed "ddosim*", then try typing "ddosim[TAB]" to see if command completion shows you that utility.
Note you can re-do the make install command and then look at the output showing what it does. Likely you'll see the directories which it uses, etc and the files it sets up, as well as any symbolic links. You could also save stdout and stderr to a text file so that it all doesn't steam beyond your terminal window limit.
Now wait a minute. Sorry I thought you were all set. Why give up if you are very close?
First thing was you needed to get the libnet library compiled and installed. I kind of figured when you said you needed the ddosim that you had completed getting the library, and then got back to ./configure, make, and make install of your original application and been successful.
After completing the libnet compile and install ... firstly, did you get libnet compiled and installed?
And then after that you'd next go back to the original actions to build what you first were building, which likely gives you ddosim. From what I'm seeing, it seems as if you did do that next step.
How about typing "which ddosim"?
Or if you feel there may be additional stuff after that name string, and because you typed "ddosim*", then try typing "ddosim[TAB]" to see if command completion shows you that utility.
Note you can re-do the make install command and then look at the output showing what it does. Likely you'll see the directories which it uses, etc and the files it sets up, as well as any symbolic links. You could also save stdout and stderr to a text file so that it all doesn't steam beyond your terminal window limit.
Let's break this into 2 parts.
The libnet library and ddosim which uses libnet.
I had the libnet in a separate directory.
But I moved it to the directory that has the ddosim souce code to make things easier.
libnet and ddosim are two different "products", both of them have a build environment. Copying that directory will not produce a common environment. Therefore your configure, make, make install commands created libnet.a but nothing related to ddosim. You need to configure, make, make install it too.
Has someone already mentioned the difficulty of managing these self-build programs and libraries in the future?
How will you keep track of the changes made to your system upon calling “make install”?
I happen to have written a blog entry a few days ago, on the topic of the “PORG” package-organizer which is just a proposition.
Last edited by Michael Uplawski; 04-16-2016 at 05:47 AM.
Reason: not accidentally
libnet and ddosim are two different "products", both of them have a build environment. Copying that directory will not produce a common environment. Therefore your configure, make, make install commands created libnet.a but nothing related to ddosim. You need to configure, make, make install it too.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
