I am attempting to make a small change to syslogd on a FreeBSD system. I would like to change the value of MAXLINE in syslogd.c to 4096 and then recompile. I've referenced the steps in this post:
http://bsdpants.blogspot.com/2010/08/truncated-syslog-messages.html .
However, as I'm not that familiar with pulling down, editing, and recompiling source, I'm stuck trying to recompile.
Steps I've taken so far:
#svn checkout svn://svn0.us-east.FreeBSD.org/base/head /usr/src
Edited value of MAXLINE in /usr/src/usr.sbin/syslogd/syslogd.c
#make obj && make depend && make && make install
When I try the 3rd step (make obj && make depend && make && make install) it gives me the following error:
make: "/usr/src/usr.sbin/syslogd/Makefile" line 4: Could not find src.opts.mk
make: "/usr/src/usr.sbin/syslogd/Makefile" line 17: Malformed conditional (${MK_INET6_SUPPORT} != "no")
make: Fatal errors encountered -- cannot continue
make: stopped in /usr/src/usr.sbin/syslogd
Am I missing a step in this process? Any help would be greatly appreciated. Please let me know if I can provide additional information.
Thanks!
That's weird. Can you try "svn up", and then retry the build ("cd /usr/src/usr.sbin/syslogd && make clean all install")? Perhaps you just checked out at an unfortunate moment, when the tree was broken.
Are you by any chance trying to do it on an old FreeBSD system (8.X or 7.X)? The system make(1) on such system might be too old to handle Makefiles from the CURRENT (which you get when checking out "head"). If this is the case you will either have to upgrade, or work on sources which match your system version
(svn checkout of /base/stable/8 or /base/release/X.Y.Z or whatever).
Another possibly relevant point can be found in the entry
for 20140505 from http://svn.freebsd.org/base/head/UPDATING :
/etc/src.conf now affects only builds of the FreeBSD src tree. In the
past, it affected all builds that used the bsd.*.mk files. The old
behavior was a bug, but people may have relied upon it. To get this
behavior back, you can .include /etc/src.conf from /etc/make.conf
(which is still global and isn't changed). This also changes the
behavior of incremental builds inside the tree of individual
directories. Set MAKESYSPATH to ".../share/mk" to do that.
Although this has survived make universe and some upgrade scenarios,
other upgrade scenarios may have broken. At least one form of
temporary breakage was fixed with MAKESYSPATH settings for buildworld
as well... In cases where MAKESYSPATH isn't working with this
setting, you'll need to set it to the full path to your tree.
Related
I'm working on several supercomputers, which have different autotools versions.
When I do make after ./configure, some of them give me an error about wrong version of aclocal.
If I re-configure my configure.ac on one platform, then same thing happens on the other one.
For example, one platform would give me this:
CDPATH="${ZSH_VERSION+.}:" && cd . && aclocal-1.15
/bin/sh: aclocal-1.15: command not found
make: *** [aclocal.m4] Error 127
If I run autoreconf, it would work fine on it. However, if I use that newly generated configure.ac on some other platforms, they will give me the same error with different version number:
CDPATH="${ZSH_VERSION+.}:" && cd . && aclocal-1.13
/bin/sh: aclocal-1.15: command not found
make: *** [aclocal.m4] Error 127
I know I can just run autoreconf -fi every time I go to a different platform, but I heard it isn't a good practice to make end users to do it as it requires them to install autotools.
They have three different versions, and I don't know how to handle this. Is there any ways to automatically run autoreconf when I run ./configure to regenerate configure? Or is there a better approach to solve this problem?
I see two main ways of distributing your source code to the different supercomputers:
tarballs generated by make dist
version controlled source tree
If you are using make dist generated tarballs (case 1) to distribute your source code to the different supercomputers, you can use one single source tree extracted from the tarball for all different supercomputers, as long as you do out of source tree builds in different per-supercomputer directories.
If you are using a version controlled source tree (case 2) for both developing your source code and distributing it to the different supercomputers, you have two options:
keep the make dist generated files inside version control
keep all generated files outside version control
If you keep the make dist generated files inside of version control (case 21), every autoreconf run on a machine different to the one which generated those files will produce a changed set of generated files, and thus changes to the files without actual raw changes. So in this case, you need to define a single system on which you all development work which touches the build system. All other systems can only do development inside the source code. Then you can use one single version controlled source tree on all different supercomputers.
If you keep all generated files outside of version control (case 22), you will need different copies of the version controlled source tree for each different machine to avoid the tool version mismatches.
In the age of distributed version control systems like git, this (case 22) would clearly be my preferred option.
I'm trying to compile a code to run in parallel on a supercomputer. I know that others have compiled this code to run on the same computer, but for some reason I am having trouble even when using the same methodology as them. For now I'm just trying to compile the code to run in serial as that should be easier to troubleshoot.
configure seems to work correctly.
However make install returns the following:
> make install
CDPATH="${ZSH_VERSION+.}:" && cd .. && /bin/sh /home1/username123/code123/config/missing aclocal-1.13 -I ./config -I /home1/username123/code123/build-tools/aclocal -I /usr/local/share/aclocal
aclocal-1.13: error: couldn't open directory '/usr/local/share/aclocal': No such file or directory
Makefile:534: recipe for target '../aclocal.m4' failed
make: *** [../aclocal.m4] Error 1
aclocal is indeed not located at /usr/local/share/aclocal, it is located at /usr/bin/aclocal - but as /usr/bin is in my path, I don't understand why the location is an issue.
As has been made clear in comments on the question, the problem was that the project sources were copied onto the target system in a way that failed to preserve their original timestamps. The Autotools, through make, use file timestamps to determine which files are out of date, and in particular, Autools-generated Makefiles contain rules for rebuilding the build system itself that can be triggered this way.
It is not ordinarily necessary or desirable to rebuild an Autotools project's build system, except in conjunction with actually performing maintenance on it. It is often the case, in fact, that the necessary support for that is not available locally. To avoid the build system thinking that it needs to rebuild itself, it is important to preserve the file timestamps from the distribution archive. For some packages, it also works to pass the --disable-maintainer-mode argument to the configure script, but by no means do all Autotools configure scripts support that.
The archive extraction tools for the typical archive formats in which Autotools-based packages are distributed do, by default, preserve timestamps when unpacking, so the ordinary procedure of
unpack the archive on the target system (e.g. tar xzf foo-1.2.3.tar.gz)
change to the unpacked source directory (e.g. cd foo-1.2.3)
configure; make; make install
normally does the right thing. Substituting something else for (1), however, such as copying the unpacked source tree from somewhere else, may cause the package to think it needs to rebuild the build system. If that works correctly then it's no big deal, but it is not uncommon that it doesn't. That's what happened here, and following the standard procedure described above solved the problem.
I am trying to install ezbounce on an SSH Shell. (Host has OK'ed use of the bouncer)
(I do NOT have sudo, however, my host is lenient and I can get things ran. If possible, I prefer a solution that does NOT require sudo or equivalent.)
I have finished ./configure , and am on the make step.
when I go to make the file, it errors with the following:
https://pastebin.com/YetM6nGN
I found a possible solution to the problem here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219298
The solution seems to be centered on the fact that GCC++/GNU make calls its latest version as opposed to the newer one.
They have an included patch, but I am honestly clueless how this gets applied.
Any help fixing the error via here or directly editing the makefile is greatly appreciated.
My makefile: https://www.dropbox.com/s/u75toiigd4v5wgl/Makefile?dl=0
So I had some help from an external source (Thank you discord communities!)
The patch listed above is for FreeBSD ONLY! (As I was made aware)
For Non-FreeBSD Ports, the fix (if your makefile looks like mine) is to edit line 32 to the following: CXX_OPTIMIZATIONS = -std=gnu++98 -O2
There is some error looking items in console that follows, but the build is successful, so I'm gonna assume they are moot.
It honestly was a confusing little puzzle for your average user, but there ya go :)
I am trying to build Linux for my Raspberry Pi 3.
When I do make, I get the below error.
make[2]: /home/rohit/workplace/rp/buildroot/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabihf-gcc: Command not found
A little background will help. I am following this link . To summarize this is what I ran.
make raspberrypi3_defconfig
make linux-menuconfig
make
From the error I get that the cross gcc is not available at the path as it should be. But I am not sure what I am missing.
The complete log of the make is pasted here. The output/host/usr/bin folder also doesn't contain arm-buildroot-linux-uclibcgnueabihf-gcc, though it does contain arm-buildroot-linux-uclibcgnueabi-gcc. I have pasted the contents of the folder here.
Please help.
i was having this problem and after a make clean the problem was solved. I think the error was because different toolchains used in different builds. The manual says that is one of the cases that you have to do a make clean
First, a little bit of background as to why I'm asking this question: Our product's daily build script (as run under Debian Linux by Jenkins), does roughly this:
Creates and enters a build environment using debootstrap and chroot
Checks out our codebase (including some 3rd party libraries) from SVN
Runs configure and make as necessary to build all of the code
Packages up the results into an install file that can be uploaded to our headless server boxes using our install tool.
This mostly works fine, but every so often (maybe one daily build out of 10), the part of the script that builds one of our third-party libraries will error out with an error like this one:
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash
/root/software/3rdparty/libogg/missing autoconf
/root/software/3rdparty/libogg/missing: line 81: autoconf: command not found
WARNING: 'autoconf' is missing on your system.
You should only need it if you modified 'configure.ac',
or m4 files included by it.
The 'autoconf' program is part of the GNU Autoconf package:
<http://www.gnu.org/software/autoconf/>
It also requires GNU m4 and Perl in order to run:
<http://www.gnu.org/software/m4/>
<http://www.perl.org/>
make: *** [configure] Error 127
As far as I can tell, this happens occasionally because the timestamps of the files in the third-party library are different (e.g. off by a second or two from each other just due to the timing of when they were checked out from the SVN server during that particular build). That causes the configure script to think that it needs to auto-regenerate a file, so then it tries to call 'automake' to do so, and errors out because automake is not installed.
Of course the obvious thing to do here would be to install automake in the build environment, but the build environment is not one that I can easily modify (due to institutional reasons), so I'd like to avoid having to do that if possible. What I'd like to do instead is figure out how to get the configure scripts (which I can modify) to ignore the timestamps and just always do the basic build that they do when the timestamps are equal.
I tried to finesse the problem by manually running 'touch' on some files to force their timestamps to be the same, and that seemed to make the problem occur less often, but it still happens:
./configure --prefix="$PREFIX" --disable-shared --enable-static && \
touch config* aclocal* Makefile* && \
make clean && make install ) || Failure "libogg"
Can anyone familiar with how automake works supply some advice on how I might make the "configure" calls in our daily build work more reliably, without modifying the build environment?
You could try forcing SVN to use commit times on checkout on your Jenkins server. These commit times can also be set in SVN if they don't work out for some reason. You could use touch -d or touch -r instead of just touch to avoid race conditions there.