Compilation error 1811

52 views
Skip to first unread message

Marc

unread,
Aug 8, 2021, 7:36:02 PM8/8/21
to jBASE
Help!!?

After cataloging a revised program I get a error message that first, tells me that the program was catalogued successfully, then fails to rebuild the library saying that an object file can't be found.  Sure enough, it is in an old backup file but not in the current Lib\objdir directory.

1) what the heck happened?
2) can I copy the old file to the correct directory and recompile or do I risk completely messing things up?

All help will be appreciated as I'm unable to process a large inventory file without the updated program....

Jim Idle

unread,
Aug 8, 2021, 9:36:20 PM8/8/21
to jBASE
It is a little tough to answer your question - you did not provide very much information. So I will have to guess at a few things:

1) You say Lib/objdir, so I have to guess you mean Windows? But what version?
2) I think error 1811 is likely a linker error - but you did not show us the actual error.
3) What version of Windows, if it is Windows?
4) What version of the compiler?
5) What version of jBASE?
6) What did you restore? An entire backup? Part of the system? Was the backup compiled using the same version of Windows and the compiler? 
7) What kind of backup?
8) Which object code does it say is missing? You should be able to work out the source code that is not compiled from that.

But, in general you can recompile everything and recatalog everything, so long as you have the source code. If you have changed compilers or systems since that backup, it is generally a good idea to recompile and recatalog. And not when the system is live of course. Maybe clear out all the old objects beforehand, though in theory that should not be required.

If you have good backups, then you can try anything as you can always go back to the backup. But I would start by clearing out the object code you restored and doing a BASIC and CATALOG on all the files - that should clear everything up.

Have you considered moving to Linux? The difference is quite big these days. You can also run it on AWS Linux in the cloud - there is no really good reason not to these days.

Jim


--
--
IMPORTANT: T24/Globus posts are no longer accepted on this forum.
 
To post, send email to jB...@googlegroups.com
To unsubscribe, send email to jBASE-un...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/jBASE?hl=en

---
You received this message because you are subscribed to the Google Groups "jBASE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jbase+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jbase/e32ef0cf-dd4b-476d-9fc4-dc13fe6ea949n%40googlegroups.com.

Marc

unread,
Aug 9, 2021, 10:17:23 PM8/9/21
to jBASE
Sorry to be short on the info I posted...I was hoping the error message would be enough to suggest a fix.
I have been running jBase 5.2 on a Windows Server 2008 Foundation R2 for a number of years without incident.  I frequently modify and recompile programs with no issues...until yesterday!
I haven't restored anything yet, not wanting to make the situation worse.  I have daily Windows backups to work from if necessary.

As you suggested, I recompiled and recataloged all 472 programs in that  .bp file.  All of them recompiled and cataloged successfully but 52 failed, I assume at the link stage with the following error message.
Source file CASH.ENTRY165 compiled successfully

CASH.ENTRY165
Object CASH.ENTRY165 cataloged successfully
link @C:\Windows\TEMP\jbuild2 >C:\Windows\TEMP\jbuild3 failed , command returned
 a code of 1181
LINK : warning LNK4044: unrecognized option '/DWIN32'; ignored
LINK : warning LNK4044: unrecognized option '/MD'; ignored
LINK : warning LNK4044: unrecognized option '/W3'; ignored
LINK : warning LNK4044: unrecognized option '/GR'; ignored
LINK : warning LNK4044: unrecognized option '/EHa'; ignored
LINK : warning LNK4044: unrecognized option '/GF'; ignored
LINK : warning LNK4044: unrecognized option '/F5000000'; ignored
LINK : warning LNK4044: unrecognized option '/D_LARGEFILE_SOURCE'; ignored
LINK : warning LNK4044: unrecognized option '/D_LARGEFILE64_SOURCE'; ignored
LINK : warning LNK4044: unrecognized option '/D_FILE_OFFSET_BITS=64'; ignored
LINK : fatal error LNK1181: cannot open input file 'C:\USERS\DEV\LIB\objdir\FTCM
DLN.obj'
jcompile.exe: C:\Windows\TEMP\jbuild2 deleted
jcompile.exe: C:\Windows\TEMP\jbuild3 deleted
jcompile.exe: Returned an error code of 8
** Unable to rebuild library C:\USERS\DEV\LIB\lib1.dll **

The FTCMDLN file does not exist in my LIB directory, although it does in my old backup file. If there is a way to determine what programs reside within the old file so I could copy it, and/or, how do I create the input file that seems to be missing?

Naturally, the affected files are all daily order processing  ather than year-end accounting programs.  This leaves me dead in the water until you (no pressure intended) can offer some guidance.
Please let me know if you need any additional info. 
Thanks,
Marc

Marc

unread,
Aug 10, 2021, 2:04:23 PM8/10/21
to jBASE
Update:

Moved the programs to another server and recompiled and cataloged.  NO error messages.  Moved the files back to the first machine.  Still get a SUBROUTINE_CALL_FAILURE error when running any program with a CALL function even though no LINK error when cataloging.  Checked JBCOBJECTLIST and entry points to my LIB file.  Checked to be sure LIB file is in PATH.  Out of ideas!!  What next?

Mvreply

unread,
Aug 10, 2021, 2:11:23 PM8/10/21
to jb...@googlegroups.com

Mark,

> What next?

Not only is the platform on which you are running this deprecated, but so is the compiler.

 

If the program will compile and catalog on another system without any errors, that should also be an indication that there is a problem with this particular system.

 

The best solution is to invest in some jBASE Support dollars so that you can upgrade to a new jBASE version on a new or newer Windows platform, running a current C++ compiler version.

 

Mike

Marc

unread,
Aug 10, 2021, 3:25:30 PM8/10/21
to jBASE
Agree completely but what can I do short-term to get running???

For my own edification, why does the code compile and run on another installation, same age hardware and compiler, and not on this one?  What is causing the subroutine call failure?

Thanks again for the assistance.
Marc

Mvreply

unread,
Aug 10, 2021, 4:12:47 PM8/10/21
to jb...@googlegroups.com

Mark,

If you can’t catalog into a shared library, then there are potentially problems with that library or the object folder therein, so you might be best served by blowing away the “bin” and “lib” folder and recompiling everything.

Mark Hogden

unread,
Aug 10, 2021, 4:18:37 PM8/10/21
to jb...@googlegroups.com
It may be a .net framework issue check for which versions are installed on both boxes, and reinstall on the problem box. 
Maybe I’m missing something, but if you have good bin and libs on the second machine why can’t you use copies of them on the problem box. If you can’t blow away the existing bin and lib you can set JBCOBJECTLIST, and PATH etc to look for the imported ones.


On Aug 10, 2021, at 12:25, Marc <mzi...@gmail.com> wrote:



Marc

unread,
Aug 10, 2021, 5:20:57 PM8/10/21
to jBASE
Will check versions!!  Same machines and software but two different businesses
in different locations...just used the other machine to run test.

Jim Idle

unread,
Aug 10, 2021, 11:04:08 PM8/10/21
to jBASE
It's definitely a compiler compatibility issue. I can only guess that one machine was upgraded and the other wasn't. IF using the .net version of the compiler, then upgrading that system is part of the system upgrades (I think - I have not used Windows for years, and not that particular version for a very long time. 

So, while you might be able to copy the bin and lib directories, the runtime system installed on the one machine isn't compatible, so it is linked to libraries that will not be present on the other machine. 

Definitely the best way forward is to upgrade everything - there comes a time where hanging on to what you've paid for many years ago becomes impractical. Ignoring whether jBASE can be put back together on that system, just go and count the system security updates that have been issued in the intervening years. It isn't sensible to keep using it.

So, for now, here is how I would put that back together, given that one system is working:

Look at what is installed version wise on the working system - .Net runtime version especially
Install that version of .Net runtime/development system on the system that stopped working - the thing is though that things like the .Net runtime version are also fundamental to the system - it may not be possible to downgrade without a complicated procedure/
Look at the install/upgrade history on the system that isn't working and see what went wrong - things like this don't just happen - something was changed

Then, honestly, pay a few support $$, get off Windows and on to Amazon Linux on AWS - the advantages are too many to enumerate.



To view this discussion on the web visit https://groups.google.com/d/msgid/jbase/234944FA-765C-4FE4-A3C6-1508507C65DA%40proman.com.

Marc

unread,
Aug 13, 2021, 7:27:02 PM8/13/21
to jBASE
Thank you all for the input and advice.  For now, if I can't solve the compiler "upgrade" issue, I'm going to try restoring from backups until I find one that is error-free.  Once past that a significant software upgrade is my next project!
Reply all
Reply to author
Forward
0 new messages