Opened 7 years ago

Closed 7 years ago

#1757 closed defect (fixed)

LD_SEARCH_FLAGS incorrect for NetBSD

Reported by: brook Owned by: grass-dev@…
Priority: critical Milestone: 7.0.0
Component: Default Version: svn-trunk
Keywords: Cc:
CPU: Unspecified Platform: Other Unix

Description

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.

Attachments (2)

patch-aclocal.m4 (514 bytes) - added by brook 7 years ago.
Patch to aclocal.m4
patch-configure (489 bytes) - added by brook 7 years ago.
Patch to configure

Download all attachments as: .zip

Change History (11)

Changed 7 years ago by brook

Attachment: patch-aclocal.m4 added

Patch to aclocal.m4

Changed 7 years ago by brook

Attachment: patch-configure added

Patch to configure

comment:1 Changed 7 years ago by neteler

Milestone: 6.4.37.0.0
Version: 6.4.2svn-trunk

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.

comment:2 in reply to:  1 ; Changed 7 years ago by 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).

comment:3 in reply to:  2 ; Changed 7 years ago by 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

comment:4 in reply to:  3 ; Changed 7 years ago by 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.

comment:5 in reply to:  4 ; Changed 7 years ago by 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.

comment:6 in reply to:  5 ; Changed 7 years ago by 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).

comment:7 in reply to:  6 Changed 7 years ago by 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

comment:8 Changed 7 years ago by mlennert

Is this still an open ticket ?

comment:9 in reply to:  8 Changed 7 years ago by mmetz

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.