Solved "Missing" files stop building NVIDIA drivers

fscorrea

fscorrea

I was trying to build NVIDIA 440.82 drivers when met with weird problems. At the very start, it didn't find stdarg.h. # setenv CPATH /usr/include:/usr/lib/include solved but this behavior put me on guard --- it was far too early and silly. Also, make stopped for not finding it, but would anyhow create a soft link and refuse to re-run until manually removing the link. Then stdarg.h was found (in now set CPATH) and the link remade. Of course, it got another problem this time regarding a vnode.h trying to include a supposedly missing vnode_if.h. The file should be created while building, using another source file and an awk script.

It's pretty much useless to devour make(1) with hopes of improving this situation, since it does not look an error that simple, the likes of being easily caught and fixed by changing a ":=" that had to be "=" or vice-versa so not to skip perhaps conditionally calling awk for example. No, NVIDIA probably just shipped the same GNU Make style and syntax regardless of the manual warnings about their being not quite the same, period. Too much time would be spent just trying to figure out their logic of building and the makefiles themselves, with the hopes of find the bug just digging a little deep. Moreover, I pretty much doubt that is the last error I'll met. I'm rather looking for a rather pragmatic workaround, e.g. manually run every awk lines skipped in advance so make can find and include what its asked for.

For me to do this, I'd like to know more or less the reason for this setup. If the rationale is not having vnode_if.h among others I need to know so to delete them after building. If, however, it's just a initial setup and would end up done sooner or later --- permanently --- then I can run the scripts manually and leave as be forever after.

Perhaps it sounds far-fetched a "workaround" but it's also the quickest by far without relying upon sheer luck of the matter being simpler than it looks. I'm well-aware vnode_if.h itself includes another file with the same problem and others shall appear as I go further.

Simply put, /usr/src/sys/sys/vnode_if.h does not exist but /usr/src/sys/kern/vnode_if.src do. awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -h would create vnode_if.h and the same kind of error will probably keep happening, all of them fixed by the same "awk -f foo.awk foo.src -opt" pattern.

Can I do it and leave as be or there's a reason for them not to be there and should remain that way?

P.S.: While researching, I saw SirDice telling another user to update his source tree while having issues alike. Is svn the only way of doing it? I'm not quite knowledgeable of the tool and so. Anyway, I keep modifying source file and recompiling e.g. kbdcontrol so it'll work properly and load a custom keymap on vt(4). Subversion would never flag me as "up-to-date" regardless of the actual circunstances then. The other way I can think of would be manually checking revision updates so to decide when to fetch another copy of the tree.
 
make(1) was stopping at the same place. I used -d with just some flags yet the output had nearly 10 thousand lines. Many pattern, however, repeated: it was adding to a list of targets. Checking the Makefile down the tree to the directory where it stopped. Along the path I noticed quite some global (/usr/share/mk/bsd.*.mk) includes. The one at the directory where the error stopped however had at its last line .include <bsd.kmod.mk>. The awk scripts were being run from inside it, but it was the only one seemingly ignored. Every other system globals were being included. Some of them added a new target with the same filename with two underlines appended at the beginning and the end, as in e.g. __bsd.init.mk__.

I concluded the problem was with dependencies, possibly with their order. Bearing that in mind, I tweaked some of them to no avail just to, suddenly, untie the gordian knot: running $ make then $ sudo make install. Solved.

I figured this could rearrange dependencies and provide newly built files. Technically, as I think I, now, learned of, install is a sort of predefined target and splits into other parts (e.g. beforeinstall, realinstall, afterinstall). One takes make install would be followed by a couple of cp(1) to the system directories. It's not, however, how it actually happens. It sets a chain of dependencies and try some compiling that, usually, would had taken place before.

As the error reported a missing header and debug info (I managed to get) pointed towards compilation trouble, I failed to notice the trivial issue that make install would not logically precede actual compiling steps. As for these, doc/README just plainly told to # make install while running Linux ABI and the modules would be built (not really), the .conf files "automagically" changed so to load them at boot, and put the libs where they belong for both FreeBSD libs and those in /compat/linux/.

NVIDIA-FreeBSD-x86_64-440.82/doc/README
Code: 
______________________________________________________________________________

Chapter 3. Installing the NVIDIA Driver
______________________________________________________________________________

This installation procedure will likely be simplified further in the future,
but for the moment you will need to download the NVIDIA FreeBSD Graphics
Driver archives from the NVIDIA website, extract them to a temporary location
of your choice, and run the following from the root of the extracted directory
hierarchy:

    % make install

This will compile the NVIDIA FreeBSD kernel module, install it, and kldload
it. It will also remove any conflicting OpenGL libraries, and install the
NVIDIA OpenGL libraries. The '/dev/nvidia' device files will be created
(unless the system is using devfs), and your '/boot/loader.conf' file will be
updated to automatically load the NVIDIA kernel module on boot, as well as the
Linux ABI compatibility module should you not have it compiled into your
kernel.

______________________________________________________________________________

It's so simple that's nearly stupid. At least made me learn a bit more about BSD Make.
 
You must log in or register to reply here.
Back
Top