[GRASS-dev] G7: landsat_met.c:103: undefined reference to `chrncpy'

neteler · July 29, 2013, 10:29am

Hi,

I changed my compiler flags to catch more potential errrors and got this one:

[neteler@north i.landsat.toar]$ make
gcc -g -Wall -fno-common -fexceptions -std=gnu99
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector -m64
-mtune=generic
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include
-DPACKAGE=\""grassmods"\"
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include -o
OBJ.x86_64-unknown-linux-gnu/landsat_met.o -c landsat_met.c
In file included from /usr/include/stdio.h:27:0,
from landsat_met.c:1:
/usr/include/features.h:330:4: warning: #warning _FORTIFY_SOURCE
requires compiling with optimization (-O) [-Wcpp]
: && gcc -L/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/lib
-L/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/lib
-Wl,--export-dynamic -L/usr/lib64
-Wl,-rpath-link,/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/lib
-o /home/neteler/grass70/dist.x86_64-unknown-linux-gnu/bin/i.landsat.toar
OBJ.x86_64-unknown-linux-gnu/landsat_set.o
OBJ.x86_64-unknown-linux-gnu/main.o
OBJ.x86_64-unknown-linux-gnu/landsat.o
OBJ.x86_64-unknown-linux-gnu/earth_sun.o
OBJ.x86_64-unknown-linux-gnu/landsat_met.o -lgrass_raster.7.0.svn
-lgrass_gis.7.0.svn -lm
OBJ.x86_64-unknown-linux-gnu/landsat_met.o: In function `lsat_metadata':
/home/neteler/grass70/imagery/i.landsat.toar/landsat_met.c:103:
undefined reference to `chrncpy'
/home/neteler/grass70/imagery/i.landsat.toar/landsat_met.c:112:
undefined reference to `chrncpy'
/home/neteler/grass70/imagery/i.landsat.toar/landsat_met.c:122:
undefined reference to `chrncpy'
collect2: error: ld returned 1 exit status
make: *** [/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/bin/i.landsat.toar]
Error 1

Does anyone know how to fix that? Perhaps related to the use of
-D_FORTIFY_SOURCE=2

Markus

Hamish · July 29, 2013, 11:16am

Hi,

I think it needs additional LDFLAGS too.

here's an example from the debian/unstable build

include /usr/share/hardening-includes/hardening.make
CFLAGS=$(shell dpkg-buildflags --get CFLAGS)
LDFLAGS=$(shell dpkg-buildflags --get LDFLAGS)

# ->
CFLAGS="-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security"
LDFLAGS="-Wl,-z,relro"

# then
CFLAGS+=$(HARDENING_CFLAGS)
LDFLAGS+=$(HARDENING_LDFLAGS)

(I'll echo those out in the morning if you need them)

# TODO: fix these
CFLAGS+=-Wno-error=format-security

...

gcc -I/home/hamish/src/grass/grass-6.4.3/dist.x86_64-pc-linux-gnu/include \
-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat \
-Werror=format-security -fPIE -fstack-protector --param ssp-buffer-size=4 \
-D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security \
-Wall -O -fPIC -DPACKAGE=\""grasslibs"\" -D_FILE_OFFSET_BITS=64 \
-DGDAL_LINK=1 -DGDAL_DYNAMIC=1 -DPACKAGE=\""grasslibs"\" \
-I/usr/include/gdal -I/usr/include/gdal \
-I/home/hamish/src/grass/grass-6.4.3/dist.x86_64-pc-linux-gnu/include \
-o OBJ.x86_64-pc-linux-gnu/adj_cellhd.o -c adj_cellhd.c

Hamish

----- Original Message -----

From: Markus Neteler <neteler@osgeo.org>
To: GRASS developers list <grass-dev@lists.osgeo.org>
Cc:
Sent: Monday, July 29, 2013 10:29 PM
Subject: [GRASS-dev] G7: landsat_met.c:103: undefined reference to `chrncpy'

Hi,

I changed my compiler flags to catch more potential errrors and got this one:

[neteler@north i.landsat.toar]$ make
gcc -g -Wall -fno-common -fexceptions -std=gnu99
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector -m64
-mtune=generic
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include
-DPACKAGE=\""grassmods"\"
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include -o
OBJ.x86_64-unknown-linux-gnu/landsat_met.o -c landsat_met.c
In file included from /usr/include/stdio.h:27:0,
from landsat_met.c:1:
/usr/include/features.h:330:4: warning: #warning _FORTIFY_SOURCE
requires compiling with optimization (-O) [-Wcpp]
: && gcc -L/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/lib
-L/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/lib
-Wl,--export-dynamic -L/usr/lib64
-Wl,-rpath-link,/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/lib
-o /home/neteler/grass70/dist.x86_64-unknown-linux-gnu/bin/i.landsat.toar
OBJ.x86_64-unknown-linux-gnu/landsat_set.o
OBJ.x86_64-unknown-linux-gnu/main.o
OBJ.x86_64-unknown-linux-gnu/landsat.o
OBJ.x86_64-unknown-linux-gnu/earth_sun.o
OBJ.x86_64-unknown-linux-gnu/landsat_met.o -lgrass_raster.7.0.svn
-lgrass_gis.7.0.svn -lm
OBJ.x86_64-unknown-linux-gnu/landsat_met.o: In function `lsat_metadata':
/home/neteler/grass70/imagery/i.landsat.toar/landsat_met.c:103:
undefined reference to `chrncpy'
/home/neteler/grass70/imagery/i.landsat.toar/landsat_met.c:112:
undefined reference to `chrncpy'
/home/neteler/grass70/imagery/i.landsat.toar/landsat_met.c:122:
undefined reference to `chrncpy'
collect2: error: ld returned 1 exit status
make: ***
[/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/bin/i.landsat.toar]
Error 1

Does anyone know how to fix that? Perhaps related to the use of
-D_FORTIFY_SOURCE=2

Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

neteler · July 29, 2013, 1:45pm

On Mon, Jul 29, 2013 at 1:16 PM, Hamish <hamish_b@yahoo.com> wrote:

Hi,

I think it needs additional LDFLAGS too.

I tried to no avail.

But MarkusM spotted this change which helps:

Index: landsat_met.c

--- landsat_met.c (revision 57320)
+++ landsat_met.c (working copy)
@@ -17,7 +17,7 @@
#define TM5_MET_SIZE 28700 /* .met file size 28686 bytes */

-inline void chrncpy(char *dest, char src, int n)
+static void chrncpy(char *dest, char src, int n)
{
int i;

I will submit that if no objections.

Markus

Glynn_Clements1 · July 30, 2013, 5:10pm

Markus Neteler wrote:

> I think it needs additional LDFLAGS too.

I tried to no avail.

But MarkusM spotted this change which helps:

Index: landsat_met.c

--- landsat_met.c (revision 57320)
+++ landsat_met.c (working copy)
@@ -17,7 +17,7 @@
#define TM5_MET_SIZE 28700 /* .met file size 28686 bytes */

-inline void chrncpy(char *dest, char src, int n)
+static void chrncpy(char *dest, char src, int n)
{
int i;

I will submit that if no objections.

The question is, why does it only happen for this file?

Searching for "\<inline\>" in *.c gives:

raster/r.statistics3/main.c:54:static inline int get_slot(DCELL c)
raster/r.statistics3/main.c:65:static inline double get_quantile(struct basecat *bc, int n)
raster/r.quantile/main.c:42:static inline int get_slot(DCELL c)
raster/r.quantile/main.c:53:static inline double get_quantile(int n)
vector/v.mapcalc/list.c:140:inline LIST *listprep(LIST * head, LIST * elt)
vector/v.mapcalc/list.c:290:inline int listcnt(LIST * head)
vector/v.mapcalc/list.c:536:inline void listforeach(LIST * head, actfunc action)
vector/v.mapcalc/list.c:574:inline LIST *listlast(LIST * head)
vector/v.mapcalc/vector.c:72:static inline int _is_zero(double r);
vector/v.mapcalc/vector.c:410:static inline int _is_zero(double r)
vector/v.generalize/point.c:26:inline void point_subtract(POINT a, POINT b, POINT * res)
vector/v.generalize/point.c:34:inline void point_add(POINT a, POINT b, POINT * res)
vector/v.generalize/point.c:47:inline double point_dist2(POINT a)
vector/v.generalize/point.c:52:inline void point_assign(struct line_pnts *Points, int index, int with_z,
vector/v.generalize/point.c:70:inline void point_scalar(POINT a, double k, POINT * res)
vector/v.generalize/point.c:78:inline void points_copy_last(struct line_pnts *Points, int pos)
vector/v.generalize/point.c:89:inline double point_dist(POINT a, POINT b)
vector/v.generalize/point.c:95:inline double point_dist_square(POINT a, POINT b)
vector/v.generalize/point.c:101:inline double point_angle_between(POINT a, POINT b, POINT c)
vector/v.generalize/point.c:108:inline double point_dist_segment_square(POINT a, POINT b, POINT c, int with_z)
imagery/i.landsat.toar/landsat_met.c:20:inline void chrncpy(char *dest, char src, int n)

So I would expect to see issues with vector/v.mapcalc/list.c and
vector/v.generalize/point.c. However, I note that both of those files
include headers with "extern" declarations for the functions in
question, while landsat_met.c doesn't, so I suspect that is the issue
here.

FWIW, I'd suggest that any functions which actually warrant an
"inline" qualifier (which doesn't include chrncpy()) should actually
be "static inline".

In general, functions should only be declared as "inline" if:
a) they are particularly simple (e.g. no loops), and
b) they are called many times (e.g. once per cell).

Also, there's no point in declaring a function "inline" unless it's
either defined in a header (in which case it must be "static inline")
or used in the same file in which it's defined (thus most of the
functions in v.generalize/point.c shouldn't be "inline").

--
Glynn Clements <glynn@gclements.plus.com>