[GRASS-user] Linking error in photo.2image

GRASS GRASS user
,
1

Hi

When running make in /grass6_devel/imagery/i.ortho.photo/photo.2image
I get a linking error as follows:

/usr/bin/ld: OBJ.i686-pc-linux-gnu/mark.o(.text+0x94a): unresolvable
R_386_32 relocation against symbol `line'
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make: *** [/usr/local/src/grass6_devel/dist.i686-pc-linux-gnu/etc/photo.2image]
Error 1

To resolve this I have tried:
1. make distclean, svn up, configure, make
2. a search of the user mailing list archives for "final link failed"
or photo.2image or "unresolvable R_386_32", which returned no hits
3. a post to the ML

My system is as follows:
GRASS 6.4 revision 33285
Ubuntu 7.10
gcc 4.1.3

Since my last successful build I have removed grass 6.3 and some old
gdal libraries (and updated the kernel). Help will be greatly
appreciated.

Thanks

Craig

2

On Sat, Sep 6, 2008 at 1:50 PM, Craig Leat <craig.leat@gmail.com> wrote:

Hi

When running make in /grass6_devel/imagery/i.ortho.photo/photo.2image
I get a linking error as follows:

/usr/bin/ld: OBJ.i686-pc-linux-gnu/mark.o(.text+0x94a): unresolvable
R_386_32 relocation against symbol `line'
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make: *** [/usr/local/src/grass6_devel/dist.i686-pc-linux-gnu/etc/photo.2image]
Error 1

I just found a similar problem in the GDAL list:
http://lists.osgeo.org/pipermail/gdal-dev/2008-September/018278.html

Maybe your problem in induced by the GDAL library?

Markus

3

Craig Leat:

> When running make in /grass6_devel/imagery/i.ortho.photo/photo.2image
> I get a linking error as follows:
>
> /usr/bin/ld: OBJ.i686-pc-linux-gnu/mark.o(.text+0x94a): unresolvable
> R_386_32 relocation against symbol `line'
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: ld returned 1 exit status
> make: *** [/usr/local/src/grass6_devel/dist.i686-pc-linux-gnu/etc/photo.2image]
> Error 1

Markus:

I just found a similar problem in the GDAL list:
http://lists.osgeo.org/pipermail/gdal-dev/2008-September/018278.html

Maybe your problem in induced by the GDAL library?

After SVN update of the grass6 source I now get the same error when
compling photo.2image.

I reverted the only recent change (indent) but still get the error.

Nothing else on the machine has changed much since the last build,
maybe a newer version of GDAL from Debian backports.org?

This is Debian/Etch (stable) on i686.
gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

Hamish

4

Hamish wrote:

Craig Leat:

> When running make in /grass6_devel/imagery/i.ortho.photo/photo.2image
> I get a linking error as follows:
>
> /usr/bin/ld: OBJ.i686-pc-linux-gnu/mark.o(.text+0x94a): unresolvable
> R_386_32 relocation against symbol `line'
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: ld returned 1 exit status
> make: *** [/usr/local/src/grass6_devel/dist.i686-pc-linux-gnu/etc/photo.2image]
> Error 1

Markus:

I just found a similar problem in the GDAL list:
http://lists.osgeo.org/pipermail/gdal-dev/2008-September/018278.html

Maybe your problem in induced by the GDAL library?

After SVN update of the grass6 source I now get the same error when
compling photo.2image.

I reverted the only recent change (indent) but still get the error.

Nothing else on the machine has changed much since the last build,
maybe a newer version of GDAL from Debian backports.org?

This error persists even though I have:
1. Upgraded to gcc 4.3.2 (self compiled)
2. Recompiled gdal 1.5.2 using '-fpic' compiler flag
3. compiled GRASS with each of these flags in turn: -fpic,
-Wl,--warn-unresolved-symbols, -Wl,--unresolved-symbols=ignore-all

GRASS 6.3.1 compiles beautifully and so at least I have a working GRASS.

Craig

Ps I'm on ubuntu 7.10, 32 bit, i686

5

> Craig Leat:
When running make in /grass6_devel/imagery/i.ortho.photo/photo.2image
I get a linking error as follows:

/usr/bin/ld:
OBJ.i686-pc-linux-gnu/mark.o(.text+0x94a): unresolvable
R_386_32 relocation against symbol `line'
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make: ***
[/usr/local/src/grass6_devel/dist.i686-pc-linux-gnu/etc/photo.2image]
Error 1

Hamish:

> After SVN update of the grass6 source I now get the same error when
> compling photo.2image.
>
> I reverted the only recent change (indent) but still get the error.

> Nothing else on the machine has changed much since the last build,
> maybe a newer version of GDAL from Debian backports.org?

Craig:

This error persists even though I have:
1. Upgraded to gcc 4.3.2 (self compiled)
2. Recompiled gdal 1.5.2 using '-fpic' compiler flag
3. compiled GRASS with each of these flags in turn: -fpic,
-Wl,--warn-unresolved-symbols, -Wl,--unresolved-symbols=ignore-all

GRASS 6.3.1 compiles beautifully and so at least I have a
working GRASS.

...

Ps I'm on ubuntu 7.10, 32 bit, i686

Getting back to the actual error message, maybe the "line" variable
set in imagery/i.ortho.photo/photo.2image/camera_ref.h is conflicting
between the "line" variable used in marc.c and the one in use_camera.c?

camera_ref.h:
#ifndef GLOBALCAM
# define GLOBALCAM extern
#endif
....
GLOBALCAM int line;

use_camera.c:
#define GLOBALCAM
#include "camera_ref.h"

mark.c:
#include "camera_ref.h"

Hamish

6

Hamish wrote:

Getting back to the actual error message, maybe the "line" variable
set in imagery/i.ortho.photo/photo.2image/camera_ref.h is conflicting
between the "line" variable used in marc.c and the one in use_camera.c?

No. The end result of the preprocessor abuse is that the variable is
defined as "int line" in use_camera.c and declared as "extern int line"
in mark.c. Both files are compiled with exactly the same switches.

If there was a problem with that, you would have the same problem with
all of the other variables declared/defined in camera_ref.h.

It's more likely that some other file also contains a symbol named
"line". But the only one which I can find is the line() function in
lib/driver/Polygon.c, and that isn't exported.

In any case, we can probably eliminate that specific issue by making
"line" a local variable in both _drawcam() (in mark.c) and drawcamnew()
(in use_camera.c). In each case, the variable is actually specific to a
while loop; there's no actual reason for it to be a global variable.

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

7

Glynn Clements wrote:

No. The end result of the preprocessor abuse is that the variable is
defined as "int line" in use_camera.c and declared as "extern int line"
in mark.c. Both files are compiled with exactly the same switches.

If there was a problem with that, you would have the same problem with
all of the other variables declared/defined in camera_ref.h.

It's more likely that some other file also contains a symbol named
"line". But the only one which I can find is the line() function in
lib/driver/Polygon.c, and that isn't exported.

In any case, we can probably eliminate that specific issue by making
"line" a local variable in both _drawcam() (in mark.c) and drawcamnew()
(in use_camera.c). In each case, the variable is actually specific to
a while loop; there's no actual reason for it to be a global variable.

Ok, making 'int line;' local to both mark.c and use_camera.c gets it to
compile again.

One thing though- doing so ensures that line will be used uninitialized
in the if() on L242 of mark.c (because pager==0):
http://trac.osgeo.org/grass/browser/grass/trunk/imagery/i.ortho.photo/photo.2image/mark.c#L224

it would be set to 0 on L239 but for some reason has been commented out
pre-CVS. Move the line=0; to the beginning of the outer while loop?
(next to pager=0)

Does anyone know if the Spearfish Imagery demo dataset includes
i.ortho.photo tutorial camera files for testing?
  http://grass.osgeo.org/download/data6.php

Hamish

8

On Sun, Sep 14, 2008 at 1:42 PM, Hamish <hamish_b@yahoo.com> wrote:

Does anyone know if the Spearfish Imagery demo dataset includes
i.ortho.photo tutorial camera files for testing?
http://grass.osgeo.org/download/data6.php

Here some info for i.ortho.photo and photo gs13:

     Please provide the following information:
+-------------------------------------------------------------+
Camera Name gscam_____________
Camera Identification gs-vqcy___________
Calibrated Focal Length mm. 152.41____________
Point of Symmetry: X-coordinate mm. 0_________________
Point of Symmetry: Y-coordinate mm. 0_________________
Maximum number of fiducial or reseau marks 8_________________
+-------------------------------------------------------------+

( sorry for Latex, tis is borrowed from the second book edition):

In a perfect 23~cm \mply 23~cm (9'' \mply 9'') aerial photo, the
distance of the bright points is 113~mm from the point of symmetry.
The distances depend on the camera type and will be provided by the
camera manufacturer. According to the coordinate system, with its
point of origin being set to the image center, we define the following
values for the \grass{gs13.1} aerial photo (all values are in millimeters).
You may start with the upper left fiducial mark (no.~1), the other
marks are numbered clockwise, until we reach the middle fiducial mark
on the left side (no.~8, compare Fig~\ref{fig:fidmarks}). The
coordinates are entered accordingly:

% 102 a 103 1 2 3
% +---------+ +---------+
% | | | |
% c | + | d 8| | 4
% | | | |
% +---------+ +---------+
% 101 b 104 7 6 5

        Please provide the following information:
+-------------------------------------------------------------+
            Fid# Fid Id Xf Yf

             1 1_____ -106.01___ 106.01____
             2 2_____ 0_________ 106.01____
             3 3_____ 106.01____ 106.01____
             4 4_____ 106.01____ 0_________
             5 5_____ 106.01____ -106.01___
             6 6_____ 0_________ -106.01___
             7 7_____ -106.01___ -106.01___
             8 8_____ -106.01___ 0_________

                           Next: end__
+-------------------------------------------------------------+

Markus

9

Glynn Clements wrote:

It's more likely that some other file also contains a symbol named
"line". But the only one which I can find is the line() function in
lib/driver/Polygon.c, and that isn't exported.

Through a process of going back to the date of my last known successful
full build, updating 1/2 way to the current revision, testing, updating/
reverting to 1/2 way through the remaining failure set, and so on, has
led me to determine that the commit in which the problem is first seen is
r33287 (initial r.external backport).

http://trac.osgeo.org/grass/changeset/33187

unfortunately it's a complicated commit.

WRT line being used uninitialized in mark.c, I wonder if line is global
there (and not reset to 0) so that the function can be reentrant and
continue (line++) from where it last left off? (say a list continuing in
a second column)

Hamish

10

Hamish wrote:

> It's more likely that some other file also contains a symbol named
> "line". But the only one which I can find is the line() function in
> lib/driver/Polygon.c, and that isn't exported.

Through a process of going back to the date of my last known successful
full build, updating 1/2 way to the current revision, testing, updating/
reverting to 1/2 way through the remaining failure set, and so on, has
led me to determine that the commit in which the problem is first seen is
r33287 (initial r.external backport).

http://trac.osgeo.org/grass/changeset/33187

unfortunately it's a complicated commit.

In that case, it's almost certainly due to the fact that GDAL exports
a variable named "line".

You might want to report this to the GDAL developers; most of the
other variables have names which are unlikely to accidentally
conflict, but "line" is likely to be quite a common variable name.

WRT line being used uninitialized in mark.c, I wonder if line is global
there (and not reset to 0) so that the function can be reentrant and
continue (line++) from where it last left off? (say a list continuing in
a second column)

If that's the case, it can be declared "static", which also solves the
lack of initialisation.

Also, bear in mind that i.ortho.photo is "dead" in 7.x. It relies
heavily upon curses, vask, terminal interaction, and mouse input from
the monitor, all of which are unavailable in 7.x. Even if someone
wants to resurrect it, a lot of code will need to be replaced,
including the code in question.

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

11

Glynn:

> > It's more likely that some other file also contains a symbol named
> > "line". But the only one which I can find is the line() function in
> > lib/driver/Polygon.c, and that isn't exported.

Hamish:

> led me to determine that the commit in which the problem is first
> seen is r33287 (initial r.external backport).
> http://trac.osgeo.org/grass/changeset/33187
>
> unfortunately it's a complicated commit.

Glynn:

In that case, it's almost certainly due to the fact that GDAL exports
a variable named "line".

$ nm /usr/lib/libgdal1.5.0.a | grep ' line'
00000000 B line

?

You might want to report this to the GDAL developers; most of the
other variables have names which are unlikely to accidentally
conflict, but "line" is likely to be quite a common variable name.

ok

> WRT line being used uninitialized in mark.c, I wonder if line is
> global there (and not reset to 0) so that the function can be
> reentrant and continue (line++) from where it last left off? (say a
> list continuing in a second column)

If that's the case, it can be declared
"static", which also solves the lack of initialisation.

I'll have to play with the module to understand that better.

Also, bear in mind that i.ortho.photo is "dead" in 7.x.

noted.

Hamish

12

Glynn Clements wrote:

In that case, it's almost certainly due to the fact that GDAL exports
a variable named "line".

You might want to report this to the GDAL developers; most of the
other variables have names which are unlikely to accidentally
conflict, but "line" is likely to be quite a common variable name.

$ grep -r --include="*.h" "int line" ./src/gdal-1.5.2
./frmts/msgn/msg_reader_core.h: void
get_pixel_geo_coordinates(unsigned int line, unsigned int column,
double& longitude, double& latitude); // x and y relative to this
image, not full disc image
./frmts/ceos2/ceos.h:void CalcCeosSARImageFilePosition(CeosSARVolume_t
*volume, int channel, int line, int *record, int *file_offset);
./frmts/wms/wmsdriver.h: virtual CPLErr IRasterIO(GDALRWFlag rw,
int x0, int y0, int sx, int sy, void *buffer, int bsx, int bsy,
GDALDataType bdt, int band_count, int *band_map, int pixel_space, int
line_space, int band_space);
./frmts/wms/wmsdriver.h: virtual CPLErr IRasterIO(GDALRWFlag rw,
int x0, int y0, int sx, int sy, void *buffer, int bsx, int bsy,
GDALDataType bdt, int pixel_space, int line_space);
./ogr/ogrsf_frmts/mitab/mitab.h: * Added
TABFile::TwoPointLineAsPolyline() to allow writing two point lines
./ogr/ogrsf_frmts/ili/iom/iom_p.h: void setXMLLineNumber(int line);
./ogr/ogrsf_frmts/ili/iom/iom_p.h: void setXMLLineNumber(int line);
./ogr/ogrsf_frmts/ili/iom/iom_p.h: static int lineattr;
./ogr/ogrsf_frmts/ili/iom/iom.h:void iom_issueparserr(const char
*message,int kind,int line,int col);

I don't see any global declaration for "line".

Craig

13

Craig Leat wrote:

> In that case, it's almost certainly due to the fact that GDAL exports
> a variable named "line".
>
> You might want to report this to the GDAL developers; most of the
> other variables have names which are unlikely to accidentally
> conflict, but "line" is likely to be quite a common variable name.

$ grep -r --include="*.h" "int line" ./src/gdal-1.5.2

I don't see any global declaration for "line".

It may not be declared in the headers, but it's being exported from
the library (use "nm" or "nm -D" to see a list of symbols exported or
imported by a binary).

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

14

Glynn wrote:

In that case, it's almost certainly due to the fact
that GDAL exports a variable named "line".

fixed in GDAL, http://trac.osgeo.org/gdal/ticket/2571

but we should change photo.2image as the old versions will still be in
circulation for a while.

Hamish

15

Hamish wrote:

Craig Leat:

> When running make in /grass6_devel/imagery/i.ortho.photo/photo.2image
> I get a linking error as follows:
>
> /usr/bin/ld: OBJ.i686-pc-linux-gnu/mark.o(.text+0x94a): unresolvable
> R_386_32 relocation against symbol `line'
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: ld returned 1 exit status
> make: ***
[/usr/local/src/grass6_devel/dist.i686-pc-linux-gnu/etc/photo.2image]
> Error 1

Hi, I've had this same error during make of grass6.4 snapshot_2008_09_20
I have gdal-1.5.2 and Linux version 2.6.21.5-smp (gcc version 4.1.2) on
Slackware 12.0

The error message:
cd
/space/grass-6.3/grass-6.4.svn_src_snapshot_2008_09_20/imagery/i.ortho.photo/photo.2image
make
...
/usr/lib/gcc/i486-slackware-linux/4.1.2/../../../../i486-slackware-linux/bin/ld:
OBJ.i686-pc-linux-gnu/mark.o(.text+0x880): unresolvable R_386_32 relocation
against symbol `line'
/usr/lib/gcc/i486-slackware-linux/4.1.2/../../../../i486-slackware-linux/bin/ld:
final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make: ***
[/space/grass-6.3/grass-6.4.svn_src_snapshot_2008_09_20/dist.i686-pc-linux-gnu/etc/photo.2image]
Error 1

Workaround:
I simply added -fPIC to CFLAGS and CXXFLAGS for ./configure of grass
6.4.svn_src_snapshot_2008_09_20.
Then make is OK with these flags:
CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer -fPIC"
CXXFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer -fPIC"

Don't know yet if this introduces any unexpected problems elsewhere.

Cheers, Peter

--
View this message in context: http://www.nabble.com/Linking-error-in-photo.2image-tp19345829p19637645.html
Sent from the Grass - Users mailing list archive at Nabble.com.

16

When running make in /grass6_devel/imagery/i.ortho.photo/photo.2image
I get a linking error as follows:

/usr/bin/ld: OBJ.i686-pc-linux-gnu/mark.o(.text+0x94a): unresolvable
R_386_32 relocation against symbol `line'

It's on my list, the solution will be to declare "line" as static in
mark.c; I just haven't had the time yet to test it. (ie run through the
i.ortho.photo tutorial to a level where I can notice if I broke anything
with the "fix")

The external side of the problem has already been fixed in GDAL 1.5 SVN.
(they were accidentally exporting something called "line" and the two
conflicted when linked together)

Hamish