[build] Make -- path error

Bug #405957 reported by Radu on 2009-07-28
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Perhaps some of the paths are wrong in the Makefile ?
Also, would it be possible to use autoconf/automake for this -- so that one can relocate the installation and make it portable as well.

bash# make
make -f nbproject/Makefile-Debug.mk SUBPROJECTS= .build-conf
make -f nbproject/Makefile-Debug.mk dist/Debug/GNU-Linux-x86/libgexf.so
mkdir -p build/Debug/GNU-Linux-x86
rm -f build/Debug/GNU-Linux-x86/filereader.o.d
g++ -c -g -Wall -I/usr/include/libxml2 -fPIC -MMD -MP -MF build/Debug/GNU-Linux-x86/filereader.o.d -o build/Debug/GNU-Linux-x86/filereader.o filereader.cpp
abstractiter.h:37: warning: ‘class libgexf::AbstractIter’ has virtual functions but non-virtual destructor
abstractparser.h:40: warning: ‘class libgexf::AbstractParser’ has virtual functions but non-virtual destructor
make[2]: stat: /home/sebastien/NetBeansProjects/libgexf/attvalueiter.cpp: Input/output error
make[2]: *** No rule to make target `/home/sebastien/NetBeansProjects/libgexf/attvalueiter.cpp', needed by `build/Debug/GNU-Linux-x86/_ext/home/sebastien/NetBeansProjects/libgexf/attvalueiter.o'. Stop.
make[1]: *** [.build-conf] Error 2
make: *** [.build-impl] Error 2

Radu (brum76) wrote :

Attached is a patch that fixes the above problem.
However, this goes into something different this time :

g++ -shared -o dist/Debug/GNU-Linux-x86/libgexf.so -fPIC build/Debug/GNU-Linux-x86/filereader.o build/Debug/GNU-Linux-x86/attvalueiter.o build/Debug/GNU-Linux-x86/directedgraph.o build/Debug/GNU-Linux-x86/undirectedgraph.o build/Debug/GNU-Linux-x86/edgeiter.o build/Debug/GNU-Linux-x86/attributeiter.o build/Debug/GNU-Linux-x86/graph.o build/Debug/GNU-Linux-x86/gexfparser.o build/Debug/GNU-Linux-x86/data.o build/Debug/GNU-Linux-x86/conv.o build/Debug/GNU-Linux-x86/gexf.o build/Debug/GNU-Linux-x86/legacyparser.o build/Debug/GNU-Linux-x86/nodeiter.o build/Debug/GNU-Linux-x86/filewriter.o build/Debug/GNU-Linux-x86/metadata.o -lxml2
Undefined symbols:
  "_main", referenced from:
      start in crt1.10.5.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
gmake[2]: *** [dist/Debug/GNU-Linux-x86/libgexf.so] Error 1
gmake[2]: Leaving directory `/Users/radu/Downloads/libgexf-src.0.1.0'
gmake[1]: *** [.build-conf] Error 2
gmake[1]: Leaving directory `/Users/radu/Downloads/libgexf-src.0.1.0'
gmake: *** [.build-impl] Error 2

The system is a MacOX 10.5 with XCode 3.1 installed. I have tried both make and gmake with same results.


Thanks for the bug report. Unfortunately Makefile-Debug.mk is automatically generated by Netbeans IDE and I don't have the control on it, so I can't include your patch to fix it :-(
But for the next release I keep in mind to create a cleaned file.

This is very strange anyway, even if I apply your patch I can't reproduce this bug on Linux. I don't currently have a MacOSX machine for testing (I should have one in a few months). This is very strange because there is no main function in the released sources.

This seems to be a common problem on MacOSX but don't find any right answer:

Perhaps try to use "-dynamiclib" instead of "-shared" on gcc ? (http://forums.codeblocks.org/index.php/topic,9934.0)

Radu (brum76) wrote :

Got it.
I actually wrote some autotools configuration and it compiled on a Mac.
I was wondering if you are interested in moving this project to use autotools instead of the make netbeans provides. If so, I have something that already works; however more structuring of the code ( using 'src' and consequently an 'include' directory) as well as pkg-config configuration is needed.
Either way, this bug can be closed.

Sure I'm interested in your experience with Autotools! Let's share it :)
I'm also looking for a better packaging program for Debian because Netbeans scripts have some bugs that make me fail the Debian policies.

Changed in libgexf:
status: New → In Progress
importance: Undecided → Low
Radu (brum76) wrote :

I have added the archive that contains the changed source -- the dir structure is different but I didn't changed yet the source code. Also at this time, it will install the header files along with the library.

You need to run autogen.sh then configure then make.

There are still things to improve but it does compile.

Let me know what you think

This is great! And will be very useful.

But on Linux we only have libtoolize and not glibtoolize. Is there a way to deal with it?

One little thing to improve is the SONAME: a "libgexf-0.1.0.so.0.0.0" file is created instead of a "libgexf.so.0.1.0", but this is a minor issue I guess.

Changed in libgexf:
status: In Progress → Fix Committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers