Opened 20 years ago
Last modified 20 years ago
#435 closed defect (fixed)
Link error
Reported by: | Owned by: | warmerdam | |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | default | Version: | unspecified |
Severity: | normal | Keywords: | |
Cc: |
Description
libgdal.a compile beautifully. Programs linking in GDAL fails to link, complaining of /usr/ccs/bin/ld: Unsatisfied symbols: DDFFieldDefn::Create(const char*,const char*,const char*,DDFFieldDefn::__E00 19,DDFFieldDefn::__E001a,const char*) (code) I tried to replace the prototype in /frmts/iso8211 to get rid of the =NULL default prototyping (not sure my compiler can handle it) I made the matching changes throughout the tree. gmake clean, and then gmake... same problem. Any ideas? It is obvious that other functions fron the DDFFieldDefn class are in the gdal.a library. Why would this one not be? -David Jentz
Change History (7)
comment:2 by , 20 years ago
I have been using the nightly snapshots from the trying to get it to work from the 13th (snapshot) to the 19th(snapshot)...when i decided to report it. Very few mods need to be made to the source to get it to work on hp. I can submit them if neccesary i am using CC and cc Any other info needed?
comment:3 by , 20 years ago
David, you say "Very few mods need to be made to the source to get it to work on hp". Does that mean you got it too work? If so, yes, please add the changes to this report and I will see if they can be applied back. If the problem with DDFFieldDefn still exists let me know and I will investigate. I also need to know if you did a "libtool" build, or if you used "--without-libtool". Thanks,
comment:4 by , 20 years ago
Just moved over to the 20 build tree. The fixes i reffered to are things like encloseing switch cases in {}... really trivial kind of things. I think there are something like 4 files that need mods to get the tree to compile. but these changes do NOT get rid of the link error...they actually let me get TO the link error. I just tried --without-libtool . The link error is exactly the same with or without libtool. I hope that answers everything. -David Jentz
comment:5 by , 20 years ago
David, Looking at DDFFieldDefn::Create() I see it is one of the few places where the "within the class" typedefs for data_struct_code and data_type_code enums are exposed more globally. I suspect moving them out and adjusting the use of the types appropriately might correct the problem. If you verify that this does fix it, then I can apply the change cleanly (giving a more unique name to them in the process). If you can't do the change yourself, let me know and I can try and apply it in the core code base so you can grab a new snapshot. It would also be helpful to know the other patches required so I can apply them.
comment:6 by , 20 years ago
Yes, that fixed the link error. Simply move the declarations for data_type_code and data_struct code out of the class (in the same header file) and then throughout the tree, and all is well. I thought it might have something to do with private v public issues, in the header file. It is possible i am completely off track here, but maybe they both need to be instantiated (line 305) publicly as well? You have the enumerated types declared public, instantiated privately, but then used in a public function prototype. Maybe all 3 things need to be public for this to work? Just my two coppers. Here is a partial log of fixes I do to get the build to work on HPUX 10.20. Stuff not in here is really just fine tuning. /port/GNUMakefile insert %.o: %.c $(CC) -c $(CFLAGS) $*.c -o $*.o %.o: %.cpp $(CXX) -c $(CXXFLAGS) $*.cpp -o $*.o /gcore/GNUMakefile insert %.o: %.c $(CC) -c $(CFLAGS) $(CPPFLAGS) $*.c -o $*.o %.o: %.cpp $(CXX) -c $(CXXFLAGS) $(CPPFLAGS) $*.cpp -o $*.o /frmts/iso8211/ddfsubfielddefn.cpp close switch line 447 insert { line 517 insert } /frmts/iso8211/ddfsubfielddefn.cpp close switch line 574 insert { line 651 insert } /ogr/GNUMakefile insert %.o: %.c $(CC) -c $(CFLAGS) $(CPPFLAGS) $*.c -o $*.o %.o: %.cpp $(CXX) -c $(CXXFLAGS) $(CPPFLAGS) $*.cpp -o $*.o /ogr/ogrgeometry.cpp line 1088 insert { line 1091 insert }
comment:7 by , 20 years ago
David, I have committed changes in CVS for the iso8211.h changes, including making the enum names more unique since I don't like having identifiers like vector in the global name space. I also applied the ddfsubfielddefn.cpp and ogrgeometry.cpp changes you pointed out and I am a bit shocked I didn't run into problems with that code before. I didn't apply the GNUmakefile changes, because I don't see why it should help. I am wondering if you are running an antique version of GNUmake? Thanks for your feedback!
Note:
See TracTickets
for help on using tickets.