C Program Linking - newbie question

[LSunanda]

Hi,

I have a library libladr.a. I have another set of C files. I am trying
to link this library to my program. In teh file unification.c, I have
#include ./ladr/unify.h
But I am getting error "parse error...255"

I think this is because there are some macros (but with different
defnitions) in the library and my program files with the same name.

Is it possible for me to link a library with the same macros as my
program files? If so, could somebody please guide me with the process.

Or do I have to find all the macros that are common and replace with a
different name in one of the two? If so, how do I find which ones are
shared. There are quite a lot of files in that library.

Any help is highly appreciated.

My makefile is given below:

CC = cc -g

smaran: main.o hash.o set_def.o rec_trs2.o util2.o tree.o init.o prep.o
help.o nll_ac_match.o needsgraph.o lhsheight.o unify.o
$(CC) -o smaran hash.o init.o main.o rec_trs2.o set_def.o tree.o
util2.o prep.o help.o nll_ac_match.o needsgraph.o lhsheight.o unify.o
../ladr/libladr.a
main.o: main.c tree.h global.h extern.h pcomm.h
$(CC) -c main.c
hash.o: hash.c tree.h error.h extern.h
$(CC) -c hash.c
set_def.o: set_def.c tree.h extern.h
$(CC) -c set_def.c
rec_trs2.o: rec_trs2.c tree.h extern.h
$(CC) -c rec_trs2.c
util2.o: util2.c tree.h extern.h
$(CC) -c util2.c
tree.o: tree.c tree.h extern.h
$(CC) -c tree.c
init.o: init.c tree.h extern.h
$(CC) -c init.c
prep.o: prep.c prep.h extern.h
$(CC) -c prep.c
help.o: help.c extern.h
$(CC) -c help.c
nll_ac_match.o: nll_ac_match.c tree.h extern.h
$(CC) -c nll_ac_match.c
needsgraph.o: needsgraph.c tree.h error.h extern.h
$(CC) -c needsgraph.c
lhsheight.o: lhsheight.c tree.h error.h extern.h
$(CC) -c lhsheight.c
unification.o: unification.c tree.h error.h extern.h
$(CC) -c unification.c
clean:
rm *.o smaran


Thanks,
Sunanda.

 

[Barry Schwarz]

Hi,

I have a library libladr.a. I have another set of C files. I am trying
to link this library to my program. In teh file unification.c, I have
#include ./ladr/unify.h
But I am getting error "parse error...255"

You need to ask this question in a newsgroup that discusses your
system. Linking has nothing to do with the language.

I think this is because there are some macros (but with different
defnitions) in the library and my program files with the same name.

The linker never sees any macros. The text substitution is performed
during preprocessing of the source while linking occurs after the
compiler has converted the source to object.

Is it possible for me to link a library with the same macros as my
program files? If so, could somebody please guide me with the process.

Or do I have to find all the macros that are common and replace with a
different name in one of the two? If so, how do I find which ones are
shared. There are quite a lot of files in that library.

Any help is highly appreciated.

My makefile is given below:

We don't do makefiles here either.


Remove del for email

 

[J. J. Farrell]

I have a library libladr.a. I have another set of C files. I am trying
to link this library to my program. In teh file unification.c, I have
#include ./ladr/unify.h
But I am getting error "parse error...255"

I think this is because there are some macros (but with different
defnitions) in the library and my program files with the same name.

If what you say above is true, then it's much more likely to be because
you are missing the quotation marks around the header name. It should
be

#include "./ladr/unify.h"

or, much much better would be

#include "unify.h"

with appropriate use of your compiler's command syntax to tell it where
to find the file.

Is it possible for me to link a library with the same macros as my
program files? If so, could somebody please guide me with the process.

Get the sources to the library, change the macros throughout, and build
it. Probably not a good idea. You might get away with just changing
them in the library headers you include, but that's a maintenance
nightmare.

Or do I have to find all the macros that are common and replace with a
different name in one of the two? If so, how do I find which ones are
shared. There are quite a lot of files in that library.

That's probably better, depending on the situation. Look in the library
documentation, or in the header and any other headers it includes. If
it's sanely written, there'll be some consistent prefix to all macros
which you can easily avoid.

 

[LSunanda]

Thank you Barry, I am sorry I didn't know that this question is not for
this group. At least you could have pointed me to the right group.
Thanks anyways.
Sunanda.

 

[LSunanda]

Hi Farrell,

I do have quotation marks in my include statement. I missed it when
typing the message.

I will try to change all the macros and see if it works. I was just
wondering if there might be some way of compiling or linking which
would help me avoid it.

Thanks for your reply, really appreciate it.

Sunanda.

 

[Barry Schwarz]

Thank you Barry, I am sorry I didn't know that this question is not for
this group. At least you could have pointed me to the right group.
Thanks anyways.
Sunanda.

Since you did not identify what system you are running on or what
compiler you are using, any attempt to do so on my part would have
been an inappropriate unjustifiable guess.


Remove del for email

 

[Walter Roberson]

In teh file unification.c, I have
#include ./ladr/unify.h
But I am getting error "parse error...255"

My makefile is given below:

CC = cc -g

$(CC) -o smaran hash.o init.o main.o rec_trs2.o set_def.o tree.o
util2.o prep.o help.o nll_ac_match.o needsgraph.o lhsheight.o unify.o
./ladr/libladr.a

Chances are high that you are not compiling in strict ISO C mode.
There are very few compilers that default to pure C: most of them
default to allowing at least some extensions (such as POSIX).

However, in the newsgroup comp.lang.c we lack the resources to deal
with all those extensions, especially when we aren't told what system
is being used or which compiler is being used.

My suspicion is that if you were to find the compiler switches that
disabled the extensions, that you would get noticably different
results... and -those- might plausibly be on topic here. [But
probably not.]