I might be wrong, but I think it is complaining about elf.h being a file and not a sym link as it apparently is expecting. Since you have been having so much fun with NetBSD and building stuff, perhaps there are some old files that need to be cleaned up.
In NetBSD‑current, usr/include/elf.h is a symlink to ../sys/elf.h. Modify that and see if it helps. Alternatively you could just remove everything under destination directory and build it from the scratch.
@Neat321 said:
What's the point of using NetBSD instead of FreeBSD?
Back in the 1990s I started using NetBSD because, with some help, I managed to run it on the x86, MIPS, and Power machines I had at that time.
@Crab recently helped me try FreeBSD, which is equally great.
For me it's very fun to try different OSes. My suggestion is that you try NetBSD, OpenBSD, and FreeBSD in addition to Linux, and see which one you like best for your equipment and workflow.
Can you check what's under cd /usr/src/distrib/sets? I am not super familiar with NetBSD, but I don't believe that leading dot is there for no reason making it a relative directory to some other location than root (/). Can you check with find command if there's another elf.h somewhere else under /usr/src?
linveo# cd /usr/include/
linveo# ls -l elf.h
lrwxr-xr-x 1 root wheel 14 Oct 17 01:12 elf.h -> sys/exec_elf.h
linveo#
What's in $DESTDIR is different. It seems now a real file instead of a symlink.
linveo# pwd
/usr/obj/destdir.amd64/usr/include
linveo# ls -l elf.h
-r--r--r-- 1 tom wheel 1723 Dec 14 00:27 elf.h
linveo#
Here is the file pointed to by the symlink:
linveo# pwd
/usr/include/sys
linveo# ls -l elf.h
ls: elf.h: No such file or directory
linveo# ls -l exec_elf.h
-r--r--r-- 1 root wheel 55842 Dec 11 01:14 exec_elf.h
linveo#
Maybe I could replace the present symlink with the present pointed-to file? Then the new file would not be a different type of file but would have different content.
I am missing out on understanding how the difference is detected by pax(1).
The error refers to "line 110:"
pax: line 110: ./usr/include/elf.h: type mismatch: specfile link, tree file
🔎 What the error means
• During installsets, the build system uses pax together with the METALOG spec file to copy files into the DESTDIR.
• The spec file says that ./usr/include/elf.sh should be a symlink (usually pointing to ../sys/elf.h).
• In your actual DESTREE tree, elf.h is a regular file instead of a symlink.
• pax detects this mismatch and aborts with:
pax: line 110: ./usr/include/elf.h: type mismatch: specfile link, tree file
⚙️ Why this happens
• Stale DESTDIR: If you’ve run builds before, leftover files in may not match the current source tree’s expectations.
• Header reorganization: NetBSD’s source tree sometimes changes headers from files to symlinks (or vice versa). If your tree is mid‑upgrade, you can get mismatches.
• Partial rebuild: Running "build.sh install=/" without a clean DESTDIR can leave behind old files.
🛠 How to fix
1. Clean DESTDIR completely
rm -rf ../obj/destdir.amd64
Then rerun your build.sh command. This ensures no stale headers remain.
Rebuild includes explicitly
From /usr/src :
./build.sh -O ../obj -T ../tools -U -D ../obj/destdir.amd64 includes
This regenerates symlinks like usr/include/elf.h.
Check expected state
In NetBSD‑current, usr/include/elf.h is a symlink to ../sys/elf.h. Verify in your source tree:
ls -l /usr/src/include/elf.h
It should show elf.h -> ../sys/elf.h.
✅ Summary
Your build failed because elf.h in DESTDIR is a file, but the spec expects a symlink. The cure is to wipe DESTDIR and rebuild includes so the symlink is created correctly.
🛠 How to fix
1. Clean DESTDIR completely
rm -rf ../obj/destdir.amd64
Then rerun your build.sh command. This ensures no stale headers remain.
It seemed like a good idea to clean DESTDIR.amd64, which is inside /obj. So, I moved /usr/obj to /usr/obj-broken and made a new, empty /usr/obj directory:
linveo# pwd
/usr
linveo# ls -l | grep obj
drwxr-xr-x 23 tom wheel 512 Dec 16 00:11 obj
drwxr-xr-x 23 tom wheel 512 Dec 15 20:02 obj-broken
linveo#
I started a new CVS update and build.sh. We will see what happens. . . .
To begin checking on what Co-pilot said, as the new build proceeds:
@Crab's Co-pilot said: • During installsets, the build system uses pax together with the METALOG spec file to copy files into the DESTDIR.
What is the "line 110" in the error that started all this? It's not line 3827 in METALOG.sanitized. . . .
pax: line 110: ./usr/include/elf.h: type mismatch: specfile link, tree file
@Crab's Co-pilot said: • In your actual DESTREE tree, elf.h is a regular file instead of a symlink.
linveo# cd obj-broken/destdir.amd64/usr/include/
linveo# ls -l elf.h
-r--r--r-- 1 tom wheel 1723 Dec 14 00:27 elf.h
linveo# file elf.h
elf.h: C source, ASCII text
linveo#
Let's see what happens when the new build is done. Thanks!
Hey! The build and installs of NetBSD-current kernel and userland plus reboots completed without apparent issue. Thanks to Linveo for a fast VPS! Thanks to @cmeerw for the NetBSD image that got me started!
Looks like completely cleaning the /usr/obj directory worked okay! Thanks to your Co-pilot for the hint about cleaning!
As time goes on, maybe I can understand more about exactly what happened and how and why. Maybe I need to incorporate more cleaning?
In other news, I have been doing a few OpenBSD builds from source. Maybe I am going to try FreeBSD builds too. . . .
@Neat321 said:
What's the point of using NetBSD instead of FreeBSD?
Back in the 1990s I started using NetBSD because, with some help, I managed to run it on the x86, MIPS, and Power machines I had at that time.
@Crab recently helped me try FreeBSD, which is equally great.
For me it's very fun to try different OSes. My suggestion is that you try NetBSD, OpenBSD, and FreeBSD in addition to Linux, and see which one you like best for your equipment and workflow.
@Not_Oles said:
Looks like completely cleaning the /usr/obj directory worked okay! Thanks to your Co-pilot for the hint about cleaning!
Excellent! I thanked my Co-pilot and got a response:
That’s fantastic news! 🎉. I’m glad the cleanup and header rebuild sorted out the mismatch — those lingering DESTDIR artifacts can be sneaky. It’s always satisfying when a stubborn build error finally gives way to a clean run.
Going back to your original problem, I think it is a good habit to clean your env before doing any recompilation. You never know what type of clutter is left behind and potentially throwing you off just like what happened here now.
About compiling FreeBSD, years ago I used to manage multiple production FreeBSD systems using ports which meant that every single update had to be compiled from the sources including the kernel. Yes it took a while, but it was working great and depending on your software needs could provide much more compact and tighter installation than you'd get with pkg. Definitely give it a try!
Comments
My friend you cannot pass FreeBSD 15!
Someone mention Slackware????
How to understand and fix this error, "type mismatch: specfile link, tree file"?
Thanks for any hints and help!
I hope everyone gets the servers they want!
I might be wrong, but I think it is complaining about elf.h being a file and not a sym link as it apparently is expecting. Since you have been having so much fun with NetBSD and building stuff, perhaps there are some old files that need to be cleaned up.
In NetBSD‑current, usr/include/elf.h is a symlink to ../sys/elf.h. Modify that and see if it helps. Alternatively you could just remove everything under destination directory and build it from the scratch.
Hey, hey, hey @Crab!
FWIW, I haven't changed anything yet.
Hmm . . . October.
Do you think sys/exec_elf.h is now wrong as the target object?
Do you mean that the target should be /usr/include/../sys/elf.h? There doesn't seem to be a /usr/sys directory.
Thank you, as always!
I hope everyone gets the servers they want!
See the path has a dot in front so it is a relative path to your current path at /usr/src and not pointing to /, right?
./usr/include/elf.h
What's the point of using NetBSD instead of FreeBSD?
Yes, but if I am in /usr/src, then ./usr/include/elf.h would refer to /usr/usr/include/elf.h.
But /usr/src has no /usr/src/usr subdirectory. There are /usr/src/usr.bin and /usr/src/usr.sbin.
I am still confused. . . .
I hope everyone gets the servers they want!
Back in the 1990s I started using NetBSD because, with some help, I managed to run it on the x86, MIPS, and Power machines I had at that time.
@Crab
recently helped me try FreeBSD, which is equally great.
For me it's very fun to try different OSes.
My suggestion is that you try NetBSD, OpenBSD, and FreeBSD in addition to Linux, and see which one you like best for your equipment and workflow. 
I hope everyone gets the servers they want!
Can you check what's under cd /usr/src/distrib/sets? I am not super familiar with NetBSD, but I don't believe that leading dot is there for no reason making it a relative directory to some other location than root (/). Can you check with find command if there's another elf.h somewhere else under /usr/src?
I checked the /usr/src/UPDATING file, which says nothing about the issue on the table here.
Previously in this thread I listed what's currently installed:
What's in $DESTDIR is different. It seems now a real file instead of a symlink.
Here is the file pointed to by the symlink:
Maybe I could replace the present symlink with the present pointed-to file? Then the new file would not be a different type of file but would have different content.
I am missing out on understanding how the difference is detected by pax(1).
The error refers to "line 110:"
But line 110 of what?
I hope everyone gets the servers they want!
I hope everyone gets the servers they want!
I hope everyone gets the servers they want!
I gave this to Co-pilot and this is what it says.
Here’s what’s happening in your NetBSD build:
🔎 What the error means
• During installsets, the build system uses pax together with the METALOG spec file to copy files into the DESTDIR.
• The spec file says that ./usr/include/elf.sh should be a symlink (usually pointing to ../sys/elf.h).
• In your actual DESTREE tree, elf.h is a regular file instead of a symlink.
• pax detects this mismatch and aborts with:
⚙️ Why this happens
• Stale DESTDIR: If you’ve run builds before, leftover files in may not match the current source tree’s expectations.
• Header reorganization: NetBSD’s source tree sometimes changes headers from files to symlinks (or vice versa). If your tree is mid‑upgrade, you can get mismatches.
• Partial rebuild: Running "build.sh install=/" without a clean DESTDIR can leave behind old files.
🛠 How to fix
1. Clean DESTDIR completely
From /usr/src :
In NetBSD‑current, usr/include/elf.h is a symlink to ../sys/elf.h. Verify in your source tree:
✅ Summary
Your build failed because elf.h in DESTDIR is a file, but the spec expects a symlink. The cure is to wipe DESTDIR and rebuild includes so the symlink is created correctly.
Co-pilot said
It seemed like a good idea to clean DESTDIR.amd64, which is inside /obj. So, I moved /usr/obj to /usr/obj-broken and made a new, empty /usr/obj directory:
I started a new CVS update and build.sh. We will see what happens. . . .
To begin checking on what Co-pilot said, as the new build proceeds:
What is the "line 110" in the error that started all this? It's not line 3827 in METALOG.sanitized. . . .
pax: line 110: ./usr/include/elf.h: type mismatch: specfile link, tree fileLet's see what happens when the new build is done. Thanks!
Extra thanks to @Crab!
I hope everyone gets the servers they want!
@Crab
Hey! The build and installs of NetBSD-current kernel and userland plus reboots completed without apparent issue. Thanks to Linveo for a fast VPS!
Thanks to @cmeerw for the NetBSD image that got me started! 
Looks like completely cleaning the /usr/obj directory worked okay!
Thanks to your Co-pilot for the hint about cleaning! 
As time goes on, maybe I can understand more about exactly what happened and how and why. Maybe I need to incorporate more cleaning?
In other news, I have been doing a few OpenBSD builds from source. Maybe I am going to try FreeBSD builds too. . . .
Thanks again for helping @Crab!
I hope everyone gets the servers they want!
Thank you for your reply!
Excellent! I thanked my Co-pilot and got a response:
Going back to your original problem, I think it is a good habit to clean your env before doing any recompilation. You never know what type of clutter is left behind and potentially throwing you off just like what happened here now.
About compiling FreeBSD, years ago I used to manage multiple production FreeBSD systems using ports which meant that every single update had to be compiled from the sources including the kernel. Yes it took a while, but it was working great and depending on your software needs could provide much more compact and tighter installation than you'd get with pkg. Definitely give it a try!