"Unexpected EOF within #IF, #ifdef or #ifndef" error when rebuilding / relinking SCO OpenServer 5

Hi, I am a new Unix Guru with very little experience but have the task of P2Ving an old HP Proliant ML370 G5 server to VMware ESX 4.1 or ESXi 5.5.

System seems to boots fine but when trying to remove HP software, configure TCP/IP or a driver, I am receiving:

--------

  /var/opt/K/SCO/link/1.1.1Hw/etc/conf/pack.d/kernel/space.c: 918: Unexpected EOF within #if, #ifdef or #ifndef
  
 ERROR: /var/opt/K/SCO/link/1.1.1Hw/etc/conf/pack.d/kernel/space.c will not compile properly
  
 i386Id Driver.a fatal: Can't open file /var/opt/K/SCO/link/1.1.1Hw/etc/conf/pack.d/kernel/space.o for input
  
 ERROR: can not link-edit unix
  
 idbuild: idmkunix had errors
 system build failed

-------

Does anyone know what this means or how I can to troubleshoot this issue?

I can read / write to the folder, open the file and can't see anything unusual at the end of the file - line 918

I have also done a full disk check (fsck) too

Thanks in advance.

The error is pretty clear. Somewhere in your code you have an #if , #ifdef , or #ifndef that does not have a matching #endif .

Show us the output from:

diff /var/opt/K/SCO/link/1.1.1Hw/etc/conf/pack.d/kernel/space.c /prior/version/of/space.c

(where /prior/version/of/space.c is the backup copy you made of that source file before you changed it) so we'll have a better chance of spotting the line you accidentally added or removed that is causing your problem. You did make a backup copy of the files you changed before you started editing them, didn't you?

Thank you Don for your prompt reply, no I have not made any backup copies or duplicates of the source files. As attached is a picture of the file space.c with the date going back to Dec 2007.

Could it be because I am running in Single User Mode ? or unregistered SCO software?

Just tried again running in Init level 2 with the same symptoms.

what does the space.c and space.o files do?

It's quite likely that the HP software is not designed to be removable.
HP supply HBA drivers, NIC drivers and Server Health utilities.
The unregistered software message simply means that the SCO has not been notified of the installation.
Are you still working with the HP machine, or have you moved an image to the ESX ?
Can you do a screen print of the top half print 5. You can find this in /usr/adm/messages.

Thank you JGT for your interest, I am also receiving the same behavior when trying to reconfigure the TCP /IP address for a native network driver (HW AMD PCNet-PCI Adapter)

Does SCO have the smarts to unregister itself once you move the system onto new hardware? I originally clone / P2V this system.

I am having these issues with the virtual machine only, The original physical is still working and in production but the key goal is to move into a virtual machine to reduce the hardware footprint.

Please find screen dump attached, which I think is going to help.

The only problem you may have with licensing is if you have used the same serial number on two machines on the same tcp subnet. If the first machine discovers the second machine, then one of the machines will display a message saying that the serial number is already in use, and shutdown.
Unless you have application software that is protected by having a file exist with its inode number saved in the file, then why not just do a fresh install on the virtual system, and copy the application and data from the production system.
I am assuming from the latest attachment that you are using 5.0.7.
Also, can you start "custom" and display the current installed software.

Thanks JGT, I have kept both machines on an isolated network plus I am unable to get the TCP/IP stack working using the native OS driver on the virtual machine anyway due to this EOF issue with the /etc/conf/pack.d/kernel/space.c file when trying to compile the kernel. In my personal opinion / theory, I think it does have the smarts to detect different hardware and deactivates itself.

The reason for the P2V over migration was because I don't have skills to do it and we are unable to find a resource here in Sydney Australia that can assist with migrating the SCO and installed application across.

what is the space.c and space.o files?

thanks and I appreciate your patience.

It's still summer down there isn't it?
SCO store the configurable source (space.c) and object modules (space.o) files in the /etc/conf directory structure. These files along with the driver files supplied by other vendors are used to create a new kernel. I checked the size of that file on a 507 system that I have, and it has 920 lines.
By migration, did you mean a fresh install of your current OS version, or an upgrade to 6.0.0?