Link error

[djentz@…]

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

[warmerdam]

David, 

Could you indicate the version of GDAL you are working with, and what
configuration options you were using?  I think it would be best to build
with the nightly snapshot and libtool enabled to work out problems.  

I am doubtful that assigning default NULL values to parameters
would be the source of the problems. 

If you are using an older version of the GDAL, I would imagine
the problem is that magic we used to use to explose libiso8211.a and
incorporate the .o files into ogrsf_frmts_sup.a.  I believe that has
all been removed as part of Alessandro's overhaul for libtool builds
(all since the 1.1.9 release). 

[djentz@…]

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?

[warmerdam]

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,

[djentz@…]

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

[warmerdam]

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.

[djentz@…]

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 }

[warmerdam]

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!