2

I have an issue with "make" (Oh, the horror!).

We're trying to migrate some COBOL code from Windows to Linux. The compiler and such are from Micro Focus. Under Windows the code is developed with Micro Focus Net Express. Linux has Micro Focus Server Express as the equivalent. The programs are compiled and linked using "make" scripts.

So much for the background.

The problem is a "make" script that doesn't want to compile and link an executable under Linux. The targets look like this:

# HP INIT-Daten laden
#
datLoad$O:   \
        $(UI)/defretrn.cpy \
        $(UI)/e12sy00s.cpy \
        $(UI)/e12sy005.cpy \
        $(UI)/e12sy006.cpy \
        $(UI)/e12sy010.cpy \
        $(UI)/e12sy013.cpy \
        $(UI)/e12sy050.cpy \
        $(UI)/e12db001.cpy \
        $(UI)/e12db050.cpy \
        $(UI)/evlg.cpy \
        $(UI)/deffehl.cpy \
        datLoad.xcbl $(FRC)
#       @echo "dollar-O is \"$O\" in $@"


datLoad$X:  $(LIBDSQL) datLoad$O \
        $(LP)/evlg$O $(LP)/alock$O
    $(LCOB) -o $(@:$X=) -e $(@:$X=) $(LCOBFLAGS) \
        -d e12db001 -d e12db003 -d e12db012 \
        -d e12sy005 -d e12sy006 -d e12sy009 \
        -d e12sy010 -d e12sy012 -d e12sy013 \
        -d e12sy050 \
        -I EvLgSetCategory $(LP)/evlg$O \
        -I ALckSetDebug $(LP)/alock$O \
        $(LIBEXEEXT) "$(LIBXSQL)"
    if [ -f $B/$@ -a ! -w $B/$@ ] ; then rm -f $B/$@ ; fi
    cp $@ $B

To put this into context, $0=".o" (i.e. an object file extension). $(LCOB) is the link command. $X=".exe" (an executable ... just forget about the extension, we'll fix that in due course). All the other stuff relates to paths ==> not relevant to the issue at hand and, yes, they've all been checked and verified.

Ultimately, I am trying to get "make" to resolve a target called "datLoad.o".

Included is a second "make" script containing the following:

COBFLAGS    = -cx # create object file
GNTFLAGS    =   -ug # create .gnt file
SOFLAGS     =   -z # create 
LCOB        = cob
...
.cbl$O:
    $(CCOB) $(COBFLAGS) $*.cbl, $*$O, NUL, NUL
    if [ -f $(LP)/$*$O -a ! -w $(LP)/$*$O ] ; then rm -f $(LP)/$*$O ; fi
    cp $*$O $(LP)

The relevant part is the target which resolves to ".cbl.o:". Yes, that's the shorthand version and I don't really like it but I did not write this script. I'm assured that it really means *.o:*.cbl and other similar constructs in the script do work correctly.

With a simple "make" I get a link error:

> In function `cbi_entry_point': (.data+0x384): undefined reference to
> `datLoad' /tmp/cobwZipkt/%cob0.o: In function `main': (.text+0x28):
> undefined reference to `datLoad' make: *** [datLoad.exe] Error 1

That means datLoad.o was not created. If I do create it explicitly with:

 cob -cx datload

Then "make" still gives the same error as above. Weird! However, what I really cannot understand is the response I get from "make datLoad.o" when the target does not exist:

make: Nothing to be done for `datLoad.o'.

I assumed (heaven help me) that the target "datLoad.o" would try to create the required target file if that file does not already exist. Am I going mad?

Sorry if this seems a bit obscure, I'm not sure how to phrase it better. If anybody has an idea what might be going on, I'd be really grateful...

Bill Woodger
  • 12,968
  • 4
  • 38
  • 47
Achim Schmitz
  • 498
  • 1
  • 7
  • 18
  • Have you contacted Micro Focus support? www.microfocus.com – Bill Woodger Oct 25 '13 at 10:56
  • 4
    Since you're using suffix rule format, I assume you've used `.SUFFIXES: .cbl .o` to ensure `.cbl` is a known suffix. I suggest you run `make -p` and examine the output to verify that the rules you expect are there, that the `$O` variable is being set early enough so it has the right value, etc. Also you can run `make -d` and examine the output to understand what steps make is taking to determine whether the target is out of date or not. – MadScientist Oct 25 '13 at 11:52
  • @Bill Woodger: The problem was not a Micro Focus one. I gave that info merely as a bit of background. – Achim Schmitz Oct 25 '13 at 12:16
  • The idea was that Micro Focus would have already had customers who had taken that route, and probably have a check-list of things to look out for. You got lucky here anyway. – Bill Woodger Oct 25 '13 at 23:16

1 Answers1

0

Thank you Mad Scientist. Your tip was correct.

The included .mk contained a .SUFFIXES rule. The problem was that the $O was not being used consistently. $O was originally set to ".obj" for Windows. Under Linux it's ".o". However, the .SUFFIXES rule had the ".obj" hard coded into it, so of course the ".o" targets were not being recognised. I replaced the hard coded suffix with the $O variable and it now works.

Achim

Achim Schmitz
  • 498
  • 1
  • 7
  • 18