Fix Makefile to compile on Nate's machine

[neldredge]

Makefile changes I had to do to get it to compile

[dkogan]

Thanks for checking it out :)

Before accepting, I'd like to make sure each is necessary. Here's your diff:

diff --git a/Makefile b/Makefile index b74858d..ec40425 100644 --- a/Makefile +++ b/Makefile @@ -1,11 +1,12 @@ CPPFLAGS += -MMD +CPPFLAGS += -pthread

I'm not explicitly using pthreads. Some of the dependencies do, but I don't think this means I should be asking for pthreads myself. Can you tell me what breaks for you without this?

renderer libraries

-LDLIBS += -lGL -lGLEW -lglut +LDLIBS += -lGL -lGLEW -lglut -lX11 -pthread -lm

Once again, I don't use X11 and pthread directly, so I shouldn't have to ask for it. (The -lm is true though, I was getting it for free through the dependencies, even though I should really ask for it myself). Here (Debian/unstable) I get -lX11 through -lglut and through -lfltk

dima@shorty:~/projects/horizon$ objdump -p /usr/lib/x86_64-linux-gnu/libglut.so | grep X11 NEEDED libX11.so.6

dima@shorty:~/projects/horizon$ objdump -p /usr/lib/x86_64-linux-gnu/libfltk.so.1.3 | grep X11 NEEDED libX11.so.6

So my libglut and libfltk know they need X11 and thus ask for it. Your libraries should be doing the same.... Can you see if they do?

Also I'm not using pkg-config for the GL stuff; maybe I should. Do you get -lX11 from any of these?

dima@shorty:~$ pkg-config --libs glew -lGLEW

dima@shorty:~$ pkg-config --libs glu -lGLU -lGL

I just tried the build on Ubuntu 12.04, and it seems to work as is.

+# Magic to get Make to use g++ instead of cc to link +LINK.o = $(LINK.cc)

Hmmm. This shouldn't be needed either because render_terrain: render_terrain.o, and the first dep of render_terrain.o is render_terrain.cc. You're sure it's attempting to link with cc without this?

Thanks again.

[dkogan]

So I just did an APT update, and I now see all the issues. Will update Makefile. Thanks.

[neldredge]

On Sun, 23 Jun 2013, Dima Kogan wrote:

So I just did an APT update, and I now see all the issues. Will update Makefile. Thanks.

Ah. I just got done writing a long reply regarding this, which I'll go ahead and send anyway...

Nate Eldredge nate@thatsmathematics.com

[neldredge]

On Sun, 23 Jun 2013, Dima Kogan wrote:

Thanks for checking it out :)

Before accepting, I'd like to make sure each is necessary. Here's your diff:

Sure. Note I'm on Ubuntu 13.04 here.

It looks like my gcc/ld apparently doesn't use the NEEDED tags in shared libraries to pull in dependencies. After some digging, this is controlled by ld's --copy-dt-needed-entries option, and apparently as of Ubuntu 13.04 it defaults to off. If I add

LDFLAGS += -Wl,--copy-dt-needed-entries

then everything compiles with no further changes.

According to

http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/ld/NEWS?rev=1.131.2.1&content-type=text/plain&cvsroot=src&only_with_tag=binutils-binutils-2_23_1

the default used to be on, but it was changed in GNU binutils 2.22. There is some rationale at

https://fedoraproject.org/wiki/UnderstandingDSOLinkChange

On my Ubuntu 12.04 box it apparently still defaults to on (I tested) , despite the fact that `ld -v' reports binutils 2.22. Maybe there is an Ubuntu-specific patch. It's strange that your Debian/unstable also seems to have the old behavior, unless you somehow have an outdated binutils. Anyway, you could test the new behavior with

LDFLAGS += -Wl,--no-copy-dt-needed-entries

and you should see the same failures that I do.

+# Magic to get Make to use g++ instead of cc to link +LINK.o = $(LINK.cc)

Hmmm. This shouldn't be needed either because render_terrain: render_terrain.o, and the first dep of render_terrain.o is render_terrain.cc. You're sure it's attempting to link with cc without this?

Yes:

cc render_terrain.o render_terrain_show.o points_of_interest.o fltk_annotated_image.o dem_downloader.o orb_renderviewlayer.o Fl_Scroll_Draggable.o florb/orb_gpxlayer.o florb/orb_layer.o florb/orb_mapctrl.o florb/orb_osmlayer.o florb/orb_semaphore.o florb/orb_settings.o florb/orb_thread.o florb/orb_tilecache.o florb/orb_tileserver.o florb/orb_viewport.o florb/Fl/Fl_PNG_Memory_Image.o -lGL -lGLEW -lglut -lopencv_imgproc -lopencv_highgui -lopencv_core -L/usr/lib/x86_64-linux-gnu -Wl,-Bsymbolic-functions -lfltk_images -lfltk -L/usr/lib/x86_64-linux-gnu -lcurl -lpng12 -ltinyxml -lzip -lz -lboost_filesystem -lboost_system -lboost_thread -o render_terrain

Are you sure yours doesn't? When I turn on --copy-dt-needed-entries it works even with cc. I presume some other library causes libstdc++ to be pulled in.

I'm not sure that make is actually able to detect that it needs to use g++ from tracing the dependencies like you suggest. Take a look at http://lists.gnu.org/archive/html/help-make/2012-01/msg00058.html and the reply http://lists.gnu.org/archive/html/help-make/2012-01/msg00059.html which suggest it just sees .o and uses $(LINK.o) which is $(CC) by default.

Nate Eldredge nate@thatsmathematics.com

[dkogan]

This discussion is moot at this point, but why not continue it anyway :)

neldredge notifications@github.com writes:

On Sun, 23 Jun 2013, Dima Kogan wrote:

It looks like my gcc/ld apparently doesn't use the NEEDED tags in shared libraries to pull in dependencies. After some digging, this is controlled by ld's --copy-dt-needed-entries option, and apparently as of Ubuntu 13.04 it defaults to off. If I add

LDFLAGS += -Wl,--copy-dt-needed-entries

then everything compiles with no further changes.

According to

http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/ld/NEWS?rev=1.131.2.1&content-type=text/plain&cvsroot=src&only_with_tag=binutils-binutils-2_23_1

the default used to be on, but it was changed in GNU binutils 2.22. There is some rationale at

https://fedoraproject.org/wiki/UnderstandingDSOLinkChange

On my Ubuntu 12.04 box it apparently still defaults to on (I tested) , despite the fact that `ld -v' reports binutils 2.22. Maybe there is an Ubuntu-specific patch. It's strange that your Debian/unstable also seems to have the old behavior, unless you somehow have an outdated binutils. Anyway, you could test the new behavior with

LDFLAGS += -Wl,--no-copy-dt-needed-entries

and you should see the same failures that I do.

I know about that setting (and the binutils change), but the issue was a bit more subtle than that. The NEEDED tag is there because libfltk uses symbols from libX11. The problem was that I apparently WAS using libX11 directly (see the newly-created http://bugs.debian.org/713933 ). So without copying the NEEDED tags at build-time X11 was pulled in to resolve the symbols ONLY for objects that said they needed it (libfltk, libglut). render_horizon didn't say it needed it (because the tag wasn't copied), so its symbol wasn't resolved and an error was happening. Copying the NEEDED tags is too large a hammer for this, I think, so I just added '-lX11', since it's really a bug in the package. I'm still not clear why my apt update made any difference, since the state I was updating FROM was fairly recent also, and that binutils change is years old.

+# Magic to get Make to use g++ instead of cc to link +LINK.o = $(LINK.cc)

Hmmm. This shouldn't be needed either because render_terrain: render_terrain.o, and the first dep of render_terrain.o is render_terrain.cc. You're sure it's attempting to link with cc without this?

Yes:

cc render_terrain.o render_terrain_show.o points_of_interest.o fltk_annotated_image.o dem_downloader.o orb_renderviewlayer.o Fl_Scroll_Draggable.o florb/orb_gpxlayer.o florb/orb_layer.o florb/orb_mapctrl.o florb/orb_osmlayer.o florb/orb_semaphore.o florb/orb_settings.o florb/orb_thread.o florb/orb_tilecache.o florb/orb_tileserver.o florb/orb_viewport.o florb/Fl/Fl_PNG_Memory_Image.o -lGL -lGLEW -lglut -lopencv_imgproc -lopencv_highgui -lopencv_core -L/usr/lib/x86_64-linux-gnu -Wl,-Bsymbolic-functions -lfltk_images -lfltk -L/usr/lib/x86_64-linux-gnu -lcurl -lpng12 -ltinyxml -lzip -lz -lboost_filesystem -lboost_system -lboost_thread -o render_terrain

Are you sure yours doesn't? When I turn on --copy-dt-needed-entries it works even with cc. I presume some other library causes libstdc++ to be pulled in.

I'm not sure that make is actually able to detect that it needs to use g++ from tracing the dependencies like you suggest. Take a look at http://lists.gnu.org/archive/html/help-make/2012-01/msg00058.html and the reply http://lists.gnu.org/archive/html/help-make/2012-01/msg00059.html which suggest it just sees .o and uses $(LINK.o) which is $(CC) by default.

Yep, you're right. It wasn't nearly as complicated as I thought it was. I pushed the fixes.

[neldredge]

On Sun, 23 Jun 2013, Dima Kogan wrote:

I know about that setting (and the binutils change), but the issue was a bit more subtle than that. The NEEDED tag is there because libfltk uses symbols from libX11. The problem was that I apparently WAS using libX11 directly (see the newly-created http://bugs.debian.org/713933 ). So without copying the NEEDED tags at build-time X11 was pulled in to resolve the symbols ONLY for objects that said they needed it (libfltk, libglut). render_horizon didn't say it needed it (because the tag wasn't copied), so its symbol wasn't resolved and an error was happening. Copying the NEEDED tags is too large a hammer for this, I think, so I just added '-lX11', since it's really a bug in the package. I'm still not clear why my apt update made any difference, since the state I was updating FROM was fairly recent also, and that binutils change is years old.

Well, the binutils change was made with 2.22 in November 2011, but I actually tried building stock 2.22 and it does pull in libX11. So evidently there was some other bug that caused --no-copy-dt-needed not to actually take effect in this case. It could be that this bug was fixed quite recently.

Nate Eldredge nate@thatsmathematics.com