linker errors:

elninio · 07-27-2008, 11:18 AM

my compile command:

Code:

g++ -Wall -O -g img-validate.cpp -I/prog/lib/hdf5-1.8.1/hdf5/include/ -L /prog/lib/hdf5-1.8.1/hdf5/lib -lhdf5_cpp -lhdf5_hl -lhdf5 -lz -lstdc++ -lm -ltiff -o run

my errors:

Code:

/tmp/ccPVQaqt.o: In function `dataset_loader::compute_blob_metric_stats(dataset_buf const&, int, dataset_buf const&, dataset_buf const&, dataset_buf const&, dataset_buf const&, dataset_buf&, dataset_buf&, dataset_buf&)':
/prog/ana/src/h5/input.h:496: undefined reference to `dataset_loader::radon_thresh'
/prog/ana/src/h5/input.h:497: undefined reference to `dataset_loader::sigma'
/prog/ana/src/h5/input.h:501: undefined reference to `dataset_loader::radon_thresh'
/prog/ana/src/h5/input.h:502: undefined reference to `dataset_loader::sigma'
/tmp/ccPVQaqt.o: In function `dataset_loader::compute_sobel_edge_blob_metric_stats(dataset_buf const&, int, bool const*, dataset_buf const&, dataset_buf const&, dataset_buf const&, dataset_buf const&, dataset_buf&, dataset_buf&, dataset_buf&)':
/prog/ana/src/h5/input.h:457: undefined reference to `dataset_loader::sigma'
/prog/ana/src/h5/input.h:458: undefined reference to `dataset_loader::sigma'
/tmp/ccPVQaqt.o: In function `dataset_loader::derive_sobel_edge_blob_summary()':
/prog/ana/src/h5/input.h:393: undefined reference to `dataset_loader::sigma'
/prog/ana/src/h5/input.h:396: undefined reference to `dataset_loader::sigma'
/tmp/ccPVQaqt.o: In function `dataset_loader::derive_radon_blob_summary(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
/prog/ana/src/h5/input.h:317: undefined reference to `dataset_loader::radon_thresh'
/prog/ana/src/h5/input.h:320: undefined reference to `dataset_loader::radon_thresh'
/prog/ana/src/h5/input.h:329: undefined reference to `dataset_loader::sigma'
/prog/ana/src/h5/input.h:332: undefined reference to `dataset_loader::sigma'
collect2: ld returned 1 exit status
make: *** [all] Error 1

I don't need to set LD_LIBARY_PATH do I? All lib paths and libs are provided in the compiling command so I don't think I should.

My img-validate code includes input.h which includes the HDF5 lib stuff.

radom_thresh and sigma are just arrays of numbers from inside my code:

from input.cpp:

Code:

 
const float dataset_loader::sigma[] = {0, 0.5, 1, 2, 4, 6, 8, 12, 16, 20, 24, 28}; // Extra element added to end.

const float dataset_loader::radon_thresh[] = {2, 2.828427e+00, 4, 5.656854e+00, 8, 1.131371e+01, 16, 2.262742e+01, 32, 4.525483e+01, 64, 9.050967e+01, 128, 1.810193e+02, 256, 3.620387e+02, 512, 7.240773e+02, 1024, 1.448155e+03, 2048, 2.896309e+03, 4096, 4096*M_SQRT2}; // ditto.

This code was functioning on my coworker's solaris. So I'm sure its a linking error. We also had the exact same problem before, before I had reformatted my linux partition, and fixed it by fixing the lib paths. Could someone confirm that my compile command is valid? Then I would know that the problem is a missing library and I can go ask him about it.

elninio · 07-27-2008, 12:22 PM

these are the libs in /prog/lib/hdf5-1.8.1/hdf5/lib

Code:

libhdf5.a         libhdf5.so.5@      libhdf5_hl.a      libhdf5_hl.so.0.0.0*
libhdf5.la*       libhdf5.so.5.0.1*  libhdf5_hl.la*
libhdf5.settings  libhdf5_cpp.a*     libhdf5_hl.so@
libhdf5.so@       libhdf5_cpp.la*    libhdf5_hl.so.0@

these are the include files in /prog/lib/hdf5-1.8.1/hdf5/include

Code:

H5ACpublic.h     H5Dpublic.h     H5FcreatProp.h*   H5Ppublic.h
H5AbstractDs.h*  H5DxferProp.h*  H5File.h*         H5PredType.h*
H5Apublic.h      H5EnumType.h*   H5FloatType.h*    H5PropList.h*
H5ArrayType.h*   H5Epubgen.h     H5Fpublic.h       H5Rpublic.h
H5AtomType.h*    H5Epublic.h     H5Gpublic.h       H5Spublic.h
H5Attribute.h*   H5Exception.h*  H5Group.h*        H5StrType.h*
H5Classes.h*     H5FDcore.h      H5IMpublic.h      H5TBpublic.h
H5CommonFG.h*    H5FDdirect.h    H5IdComponent.h*  H5Tpublic.h
H5CompType.h*    H5FDfamily.h    H5Include.h*      H5VarLenType.h*
H5Cpp.h*         H5FDlog.h       H5IntType.h*      H5Zpublic.h
H5Cpp.h.gch*     H5FDmpi.h       H5Ipublic.h       H5api_adpt.h
H5CppDoc.h*      H5FDmpio.h      H5LTpublic.h      H5pubconf.h
H5Cpublic.h      H5FDmpiposix.h  H5Library.h*      H5public.h
H5DSpublic.h     H5FDmulti.h     H5Lpublic.h       H5version.h
H5DataSet.h*     H5FDpublic.h    H5MMpublic.h      hdf5.h
H5DataSpace.h*   H5FDsec2.h      H5Object.h*       hdf5_hl.h
H5DataType.h*    H5FDstdio.h     H5Opublic.h
H5DcreatProp.h*  H5FaccProp.h*   H5PTpublic.h

the only one need is H5Cpp.h , it calls all the other ones, but the point is that the path is correct.

mike_g · 07-27-2008, 12:42 PM

I'm not sure if this would do anything to fix your problem, but have you tried compiling you program first, then linking it afterwards. Perhaps using a makefile? I had a similar sort of problem that seemed to work after I separated the compiling and linking procedures.

**Salem** · 07-27-2008, 12:44 PM

> -lhdf5_cpp -lhdf5_hl -lhdf5
Historically at least, order mattered.
A symbol which would be resolved by library a, but not apparent until library b was linked would appear to be unresolved.

But I thought the Linux version of ld took care of that problem.

elninio · 07-27-2008, 12:53 PM

Quote:

Originally Posted by Salem

> -lhdf5_cpp -lhdf5_hl -lhdf5
Historically at least, order mattered.
A symbol which would be resolved by library a, but not apparent until library b was linked would appear to be unresolved.

But I thought the Linux version of ld took care of that problem.

I don't understand how this works, could you explain it to me or link to me a doc? Do you suggest that I change the order of the libs?

elninio · 07-27-2008, 12:55 PM

Quote:

Originally Posted by mike_g

I'm not sure if this would do anything to fix your problem, but have you tried compiling you program first, then linking it afterwards. Perhaps using a makefile? I had a similar sort of problem that seemed to work after I separated the compiling and linking procedures.

I have using a makefile. Its simply:

Code:

all:
      g++ the command listed above

But, I know thats not what you meant. I don't know how to produce a makefile that compiles and then links...

mike_g · 07-27-2008, 02:18 PM

Be warned: This is the first makefile I have made in my life, so I dont really know what I am doing here, but, this is what mine looks like:

Code:

COMPILER = gcc
CCFLAGS = -Wall -O2 -std=c99

all:
	clear
	${COMPILER} -c main.c ${CCFLAGS}
	${COMPILER} -c shapes.c ${CCFLAGS}
	${COMPILER} -c vector.c ${CCFLAGS}
	${COMPILER} -c screen.c ${CCFLAGS}
	${COMPILER} main.o shapes.o vector.o screen.o -lSDL -lm
	./a.out
clean:
	rm -rf *.o *.dat

It basically compiles all the source files individually first before linking them. I was getting errors compiling and linking in one go, but that might have been because I was doing something wrong. IDK.

robwhit · 07-27-2008, 02:37 PM

mike_g, the point of having a makefile is so that you can do only partial compilation of your program, whatever was changed since last time. To do that, you'll have to have separate rules for each of your source files.

mike_g · 07-27-2008, 02:43 PM

Oh, why would I have to have separate rules?

Edit: there were following sections I hadent added in the post that just compile one source file and link it to the project. Is there a better way to do it?

robwhit · 07-27-2008, 03:11 PM

Code:

COMPILER = gcc
CCFLAGS = -Wall -O2 -std=c99

.PHONY: clean # without this, if there was a file named clean, the clean target would be considered up to date.

all: myprogram

myprogram: main.o shapes.o vector.o screen.o
    ${COMPILER} main.o shapes.o vector.o screen.o -lSDL -lm -o myprogram

main.o: main.c main.h
    ${COMPILER} -c main.c ${CCFLAGS}

shapes.o: shapes.c shapes.h
    ${COMPILER} -c shapes.c ${CCFLAGS}

vector.o: vector.c vector.h
    ${COMPILER} -c vector.c ${CCFLAGS}

screen.o: screen.c screen.h
    ${COMPILER} -c screen.c ${CCFLAGS}

clean:
    rm -rf *.o *.dat

This way, if one of the .o files is already built, it just skips that and compiles the others.

mike_g · 07-27-2008, 03:42 PM

Oh I get it now. Cheers.

elninio · 07-27-2008, 08:25 PM

Fixed it. The file that contained the radon declaration was not in the compiling command. input.cpp. input.cpp includes input.h, but input.h does not include input.cpp.

robwhit · 07-27-2008, 08:52 PM

Header files shouldn't be in the compile line, only in the dependency list.

07-27-2008, 12:42 PM	#3
mike_g Dr Dipshi++ Join Date: Oct 2006 Location: On me hyperplane Posts: 1,219	I'm not sure if this would do anything to fix your problem, but have you tried compiling you program first, then linking it afterwards. Perhaps using a makefile? I had a similar sort of problem that seemed to work after I separated the compiling and linking procedures.
mike_g is offline

07-27-2008, 12:44 PM	#4
Salem and the hat of Jobseeking Join Date: Aug 2001 Location: The edge of the known universe Posts: 21,693	> -lhdf5_cpp -lhdf5_hl -lhdf5 Historically at least, order mattered. A symbol which would be resolved by library a, but not apparent until library b was linked would appear to be unresolved. But I thought the Linux version of ld took care of that problem. __________________ If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
Salem is offline

07-27-2008, 02:18 PM	#7
mike_g Dr Dipshi++ Join Date: Oct 2006 Location: On me hyperplane Posts: 1,219	Be warned: This is the first makefile I have made in my life, so I dont really know what I am doing here, but, this is what mine looks like: Code: COMPILER = gcc CCFLAGS = -Wall -O2 -std=c99 all: clear ${COMPILER} -c main.c ${CCFLAGS} ${COMPILER} -c shapes.c ${CCFLAGS} ${COMPILER} -c vector.c ${CCFLAGS} ${COMPILER} -c screen.c ${CCFLAGS} ${COMPILER} main.o shapes.o vector.o screen.o -lSDL -lm ./a.out clean: rm -rf .o .dat It basically compiles all the source files individually first before linking them. I was getting errors compiling and linking in one go, but that might have been because I was doing something wrong. IDK.
mike_g is offline

07-27-2008, 02:37 PM	#8
robwhit Registered User Join Date: Oct 2001 Posts: 2,110	mike_g, the point of having a makefile is so that you can do only partial compilation of your program, whatever was changed since last time. To do that, you'll have to have separate rules for each of your source files.
robwhit is offline

07-27-2008, 02:43 PM	#9
mike_g Dr Dipshi++ Join Date: Oct 2006 Location: On me hyperplane Posts: 1,219	Oh, why would I have to have separate rules? Edit: there were following sections I hadent added in the post that just compile one source file and link it to the project. Is there a better way to do it? Last edited by mike_g; 07-27-2008 at 02:45 PM.
mike_g is offline

07-27-2008, 03:42 PM	#11
mike_g Dr Dipshi++ Join Date: Oct 2006 Location: On me hyperplane Posts: 1,219	Oh I get it now. Cheers.
mike_g is offline

07-27-2008, 08:25 PM	#12
elninio Registered User Join Date: Jun 2008 Posts: 106	Fixed it. The file that contained the radon declaration was not in the compiling command. input.cpp. input.cpp includes input.h, but input.h does not include input.cpp.
elninio is offline

07-27-2008, 08:52 PM	#13
robwhit Registered User Join Date: Oct 2001 Posts: 2,110	Header files shouldn't be in the compile line, only in the dependency list.
robwhit is offline

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Linker errors	jw232	C++ Programming	3	06-12-2009 12:56 PM
Linker errors in VC++ 2005	C+/-	C++ Programming	0	05-18-2007 07:42 AM
Sneaky little linker errors...	Tozar	C++ Programming	8	10-25-2006 05:40 AM
Linker errors with Visual C++	codegirl	C++ Programming	4	09-11-2003 09:20 AM
MSVis-Studio C++ libraries and linker errors	kellydj	Windows Programming	10	03-12-2002 02:03 PM