Jay Thierry HAN <HAN@FRECP12.BITNET> (06/23/91)
Hello,
I am trying to use f2c (the Fortran 77 -> C[++] translator) with the
Borland C++ compiler, and seem to have setup problems. After tweaking the
command line switches, I have been able to run f2c and bcc on my Fortran code.
But when I try to link (Turbo Link) the whole, I get stucked with a missing
library 'llibce.lib' message.
So I tried to re-compile the f2c libraries, but with no success. First,
I had trouble setting up the makefile for bcc and Turbo Make. And then, as
I'm not a real C programmer, I couldn't understand what to do with the ungetc
and mktemp functions mentionned in the readme about Turbo C++.
I have a 286 with 1Meg RAM and DOS 3.3 + 4DOS 3.03. I use Borland
utilities: bcc, Turbo make, Turbo link (tlink), and Turbo lib (tlib). I always
used ANSI C, either with f2c and with bcc. I need at least the large model for
my Fortran program. That Fortran code is not big at all, amounting to about
1700 lines in 8 files, and the biggest routine is 250 lines long.
Any help will be greatly appreciated. Thanks.
J. Han.dfenyes@thesis1.med.uth.tmc.edu (David Fenyes) (06/25/91)
[ I tried to reply by mail, but the mail bounced :-( ] Hello, In article <91174.123837HAN@FRECP12.BITNET> you write: > I am trying to use f2c (the Fortran 77 -> C[++] translator) with the >Borland C++ compiler, and seem to have setup problems. After tweaking the >command line switches, I have been able to run f2c and bcc on my Fortran code. I'm curious to know the problems you had (Was it the name table size?) >But when I try to link (Turbo Link) the whole, I get stucked with a missing >library 'llibce.lib' message. Hmm. I compiled the libraries with MSC 5.1, which is all I had available. I didn't think that the libraries should contain any mention of where missing symbols should be sought. I thought this was all resolved at link time by the linker. However, there's no telling what microsoft sticks in its object files. llibce.lib is the MSC 5.1 C library for xxx87 emulation, large model. Here's an experiment-- If you try linking with the small model, do you get an 'slibce.lib missing' error? If so, it's in the library. I'm very surprised at this behavior, since before linking, nothing should be able to predict whether you'll use llibce.lib (emulation), or llibc7.lib (80x87 installed)., etc. I'll look into it at this end also. I should think it entirely reasonable to compile libraries with MSC 5.1 and link with bcc. Good luck, and let me know what transpires :-) David. --- David Fenyes dfenyes@thesis1.med.uth.tmc.edu University of Texas Medical School Houston, Texas
jeffj@mcs213k.cs.umr.edu (Jeff Jenness) (06/27/91)
In article <5147@lib.tmc.edu> dfenyes@thesis1.med.uth.tmc.edu (David Fenyes) writes: >In article <91174.123837HAN@FRECP12.BITNET> you write: >> I am trying to use f2c (the Fortran 77 -> C[++] translator) with the >>Borland C++ compiler, and seem to have setup problems. After tweaking the >>command line switches, I have been able to run f2c and bcc on my Fortran code. > >I'm curious to know the problems you had (Was it the name table size?) > I have compiled the f2c libraries with Borland C++ and been able to run fortran programs that do not use formatted IO. I have not examined the problem in any great depth but feel it can be resolved by adjusting the code in the libraries. What concerns me is that the f2c translator is giving me an error on the following program: program test logical bool integer a data a,bool/1,.TRUE./ open(6,FILE='con') print*, 'BOOL = ',bool print*, 'A = ',a end The translator dies with the following message: Compiler error at line 12 of test.f: malloc(32006) failure! I have found two changes that will cause the translator to accept it: 1) comment out the data statement 2) take the strings out of the print* statements I felt that others using f2c would be interested in this and, seeing that David (the porter) reads this group, David would be kind enough to help out (even provide a fix?). If I am able to fix the library problems (time permitting), I will post. -- Jeff Jenness University of Missouri - Rolla jeffj@cs.umr.edu
a_rubin@dsg4.dse.beckman.com (Arthur Rubin) (06/27/91)
In <5147@lib.tmc.edu> dfenyes@thesis1.med.uth.tmc.edu (David Fenyes) writes: >Hmm. I compiled the libraries with MSC 5.1, which is all I had available. >I didn't think that the libraries should contain any mention of where >missing symbols should be sought. I thought this was all resolved at >link time by the linker. However, there's no telling what microsoft sticks >in its object files. llibce.lib is the MSC 5.1 C library for xxx87 >emulation, large model. >Here's an experiment-- If you try linking with the small model, do you get >an 'slibce.lib missing' error? If so, it's in the library. >I'm very surprised at this behavior, since before linking, nothing should >be able to predict whether you'll use llibce.lib (emulation), or llibc7.lib >(80x87 installed)., etc. I'll look into it at this end also. (1) Emulation modes might differ (it's unlikely, but I think emulation instructions for segment override floating point instructions might differ). I know Borland supports floating point emulation interrupts that MicroSoft doesn't. (Source: Ralph Brown's interrupt list.) (2) You need to compile the libraries with the /Zl option to remove the standard library names. (3) The compiler DOES generate different code, as well as generating different library names, depending on the /FP flag. (I think /FPc and /FPc87 generate identical code.) I'm afraid you either have to supply your own copies of MSC's libraries (probably written in assembler), or be VERY careful in using floating point. As a temporary fix for (2), you could supply empty libraries ?libce.lib so that the link won't fail. (I think one reason the libaries are there explicitly is to prevent you from linking small and large model programs together; they won't work, and this causes the linker to produce an error message.) -- 2165888@mcimail.com 70707.453@compuserve.com arthur@pnet01.cts.com (personal) a_rubin@dsg4.dse.beckman.com (work) My opinions are my own, and do not represent those of my employer.
dfenyes@thesis1.med.uth.tmc.edu (David Fenyes) (06/28/91)
In article <a_rubin.678037026@dn71> a_rubin@dsg4.dse.beckman.com (Arthur Rubin) writes: >(2) You need to compile the libraries with the /Zl option to remove the >standard library names. >As a temporary fix for (2), you could supply empty libraries ?libce.lib so that >the link won't fail. (I think one reason the libaries are there explicitly is >to prevent you from linking small and large model programs together; they won't >work, and this causes the linker to produce an error message.) Thanks for the wisdom :-) Folks--read the above. Meanwhile, I'll recompile the libs. >(3) The compiler DOES generate different code, as well as generating different >library names, depending on the /FP flag. (I think /FPc and /FPc87 generate >identical code.) I'm afraid you either have to supply your own copies of MSC's >libraries (probably written in assembler), or be VERY careful in using floating >point. I used the 'use if detected' option for the libraries. That way, only two were needed & the zip file was not overwhelming. However, maybe providing two sets of libraries, one for 80x87, and one for inline emulation would be more portable. Give me feedback, & I'll do it here & repost, and possibly save the rest of you hours of compilation time :-) David. -- David Fenyes dfenyes@thesis1.med.uth.tmc.edu University of Texas Medical School Houston, Texas
wew@naucse.cse.nau.edu (Bill Wilson) (06/28/91)
Where can I get a copy of f2c that will run or at least compile on a PC. I am using MS Fotran 4.1 & BC++. -- Let sleeping dragons lie........ | The RoleMancer -------------------------------------------------------------------- Bill Wilson (wew@naucse.cse.nau.edu | ucc2wew@nauvm | wilson@nauvax) Northern AZ Univ Flagstaff, AZ 86011