LD_SEARCH_FLAGS incorrect for NetBSD

[brook]

The value of LD_SEARCH_FLAGS in include/Make/Platform.make for NetBSD is incorrect. Rather than just -rpath it should be -Wl,-rpath.

The necessary patches against the 6.4.2 release are attached; these have been compile tested. Since they only affect NetBSD systems, there should be no risk applying them and pulling them up to more recent versions.

[brook]

Patch to aclocal.m4

[brook]

Patch to configure

[neteler]

Thanks, fixed for G6.4 and 6.5 in r53323 and r53324.

No idea about GRASS 7's aclocal.m4 which has a different structure.

[glynn]

Replying to neteler:

No idea about GRASS 7's aclocal.m4 which has a different structure.

7.0 doesn't support any BSD systems yet. New platforms need to be added by people who actually have access to (and preferably knowledge of) the platform in question.

The platforms currently supported in 7.0 are:

*-linux-*
*-pc-cygwin
*-pc-mingw32
*-apple-darwin*
*-sun-solaris*

Also, the Solaris section is hearsay (copied verbatim from 6.x).

[mmetz]

Replying to glynn:

7.0 doesn't support any BSD systems yet. New platforms need to be added by people who actually have access to (and preferably knowledge of) the platform in question.

7.0 supports now FreeBSD.

However, I do not get 7.0 compiled on NetBSD 6.0.1, the error is

ld: unrecognized option '-Wl,-rpath,/home/metz/src/grass-7.0.svn/dist.i386-unknown-netbsdelf6.0.1/lib'

ld is GNU ld (NetBSD Binutils nb1) 2.21.1

[glynn]

Replying to mmetz:

Replying to glynn:

7.0 doesn't support any BSD systems yet. New platforms need to be added by people who actually have access to (and preferably knowledge of) the platform in question.

However, I do not get 7.0 compiled on NetBSD 6.0.1, the error is

ld: unrecognized option '-Wl,-rpath,/home/metz/src/grass-7.0.svn/dist.i386-unknown-netbsdelf6.0.1/lib'

Do NetBSD shared libraries support rpath? If not, the linker probably won't accept the switch.

Also, -rpath is bad, as it hard-codes library paths, overriding LD_LIBRARY_PATH (and it will probably result in hard-coding the build directory into the installed binaries). -rpath-link is preferable, as that just sets the path for dependency checking without storing it in the binary.

[mmetz]

Replying to glynn:

Replying to mmetz:

Replying to glynn:

7.0 doesn't support any BSD systems yet. New platforms need to be added by people who actually have access to (and preferably knowledge of) the platform in question.

However, I do not get 7.0 compiled on NetBSD 6.0.1, the error is

ld: unrecognized option '-Wl,-rpath,/home/metz/src/grass-7.0.svn/dist.i386-unknown-netbsdelf6.0.1/lib'

Do NetBSD shared libraries support rpath? If not, the linker probably won't accept the switch.

Yes, NetBSD shared libraries support rpath.

Also, -rpath is bad, as it hard-codes library paths, overriding LD_LIBRARY_PATH (and it will probably result in hard-coding the build directory into the installed binaries). -rpath-link is preferable, as that just sets the path for dependency checking without storing it in the binary.

NetBSD is a bit difficult, I have to check. Some more insights from working with NetBSD:

I think I discovered inconsistencies, if not errors, in the G7 Make system: flags meant for cc are also passed to ld and vice versa, probably because it is assumed that ld = cc. For example, linking flags for cc must have the form

-Wl,-rpath,${LIB_RUNTIME_DIR}

the equivalent to ld, if ld != cc, is

-rpath ${LIB_RUNTIME_DIR}

But Shlib.make does

LDFLAGS += $(SHLIB_LDFLAGS)

even though LDFLAGS are meant for cc and SHLIB_LDFLAGS are meant for ld, at least aclocal.m4 says so. Shlib.make might also need LD_SEARCH_FLAGS.

Grass.make does

LDFLAGS     =  $(LIBPATH) $(LINK_FLAGS) $(LD_SEARCH_FLAGS)

even though LDFLAGS are meant for cc and LD_SEARCH_FLAGS are meant for ld, at least aclocal.m4 says so.

[glynn]

Replying to mmetz:

I think I discovered inconsistencies, if not errors, in the G7 Make system: flags meant for cc are also passed to ld and vice versa, probably because it is assumed that ld = cc.

Programs written in C are linked with $(CC). Programs written in C++ are linked with $(CXX). Shared libraries are linked with $(SHLIB_LD). All three are passed $(LDFLAGS). $(SHLIB_LD) is additionally passed $(SHLIB_LDFLAGS).

In practical terms, this requires that both programs and shared libraries are linked using the compiler front-end. The build system doesn't use $(LD) (which is normally the underlying linker).

The main problem with separating the two is that configure doesn't attempt to maintain any distinction, e.g. it only has one LDFLAGS variable. Simlarly, "pkg-config --libs ..." will generate switches suitable for passing to the compiler (i.e. with the -Wl, prefix).

[mmetz]

Replying to glynn:

Replying to mmetz:

I think I discovered inconsistencies, if not errors, in the G7 Make system: flags meant for cc are also passed to ld and vice versa, probably because it is assumed that ld = cc.

Programs written in C are linked with $(CC). Programs written in C++ are linked with $(CXX). Shared libraries are linked with $(SHLIB_LD). All three are passed $(LDFLAGS). $(SHLIB_LD) is additionally passed $(SHLIB_LDFLAGS).

In this case the documentation in aclocal.m4 needs to be updated, because there flags for building shared libraries are separate from flags for building and linking programs.

In any case, with SHLIB_LD="${CC} -shared" I got G7 compiled and running on NetBSD 6.

Markus M

[mlennert]

Is this still an open ticket ?

[mmetz]

Replying to mlennert:

Is this still an open ticket ?

The configure script has been updated accordingly. G7 compiles and runs fine for me on NetBSD 6. Closing ticket.