i2c tools build failure with gcc 4.6

DISCUSSION Guenter Roeck 2 participants 10 messages Dec 20, 2012 – Dec 21, 2012 7 messages not in the archive I2C subsystem host drivers

lore

Share & tools

lore

Guenter Roeck

author

2012-12-20 01:07 UTC #0 lore raw

Seen with latest i2c-tools from svn repository.

gcc 4.6:

gcc-4.6 -Llib -li2c -o tools/i2cdetect tools/i2cdetect.o tools/i2cbusses.o tools/i2cdetect.o: In function `main':
i2cdetect.c:(.text.startup+0x557): undefined reference to i2c_smbus_write_quick' i2cdetect.c:(.text.startup+0x5e9): undefined reference to i2c_smbus_read_byte'
collect2: ld returned 1 exit status
make: *** [tools/i2cdetect] Error 1

gcc-4.4:
gcc-4.4 -Llib -li2c -o tools/i2cdetect tools/i2cdetect.o tools/i2cbusses.o

[ no error ]

Any idea ?

Guenter

A message that is not in the archive (sent off-list or not yet received): [email protected]

Jean Delvare

2012-12-20 09:45 UTC #2 lore raw

Hi Guenter,

Quoted 1 line · Guenter Roeck

Seen with latest i2c-tools from svn repository.

With the subversion repository having gone on vacation, "latest" doesn't mean much :(

Quoted 9 lines

gcc 4.6:
gcc-4.6 -Llib -li2c -o tools/i2cdetect tools/i2cdetect.o tools/i2cbusses.o tools/i2cdetect.o: In function `main':
i2cdetect.c:(.text.startup+0x557): undefined reference to i2c_smbus_write_quick' i2cdetect.c:(.text.startup+0x5e9): undefined reference to i2c_smbus_read_byte'
collect2: ld returned 1 exit status
make: *** [tools/i2cdetect] Error 1

Quoted 6 lines

gcc-4.4:
gcc-4.4 -Llib -li2c -o tools/i2cdetect tools/i2cdetect.o tools/i2cbusses.o
[ no error ]
Any idea ?

I'm using gcc 4.6.2 (from openSUSE 12.1) and "the latest i2c-tools" (that would be from October 25th if I can trust the CHANGES timestamp) builds just fine for me. OTOH this is a linking problem, not building problem, so the version of "ld" may be more relevant. Are you using the same version of "ld" in both cases?

The error messages suggest that gcc (and subsequently ld) doesn't find the symbols exported by libi2c. I can't figure out any reason why it would be so. Can you show us the output of "nm lib/libi2c.so.0.1.0"? This is what I get here:

0000000000201e30 a _DYNAMIC
0000000000201fe8 a _GLOBAL_OFFSET_TABLE_
w _Jv_RegisterClasses
0000000000201e10 d __CTOR_END__
0000000000201e08 d __CTOR_LIST__
0000000000201e20 d __DTOR_END__
0000000000201e18 d __DTOR_LIST__
0000000000000f10 r __FRAME_END__
0000000000201e28 d __JCR_END__
0000000000201e28 d __JCR_LIST__
0000000000202028 a __bss_start

                 w __cxa_finalize@@GLIBC_2.2.5
0000000000000c90 t __do_global_ctors_aux
0000000000000850 t __do_global_dtors_aux
0000000000202020 d __dso_handle
                 U __errno_location@@GLIBC_2.2.5
                 w __gmon_start__

0000000000202028 a _edata
0000000000202038 a _end
0000000000000cc8 t _fini
00000000000007c8 t _init
0000000000000cd8 t _real_fini
0000000000000830 t call_gmon_start
0000000000202028 b completed.5890
0000000000202030 b dtor_idx.5892
00000000000008d0 t frame_dummy
0000000000000900 T i2c_smbus_access
0000000000000c00 T i2c_smbus_block_process_call
0000000000000a40 T i2c_smbus_process_call
0000000000000a70 T i2c_smbus_read_block_data
0000000000000950 T i2c_smbus_read_byte
00000000000009a0 T i2c_smbus_read_byte_data
0000000000000b30 T i2c_smbus_read_i2c_block_data
00000000000009f0 T i2c_smbus_read_word_data
0000000000000ad0 T i2c_smbus_write_block_data
0000000000000980 T i2c_smbus_write_byte
00000000000009d0 T i2c_smbus_write_byte_data
0000000000000ba0 T i2c_smbus_write_i2c_block_data
0000000000000940 T i2c_smbus_write_quick
0000000000000a20 T i2c_smbus_write_word_data

                 U ioctl@@GLIBC_2.2.5

This could also be a Makefile dependency issue... I can't remember what, if anything, guarantees that the library is built before the tools which use it.

Signature · 1 line

Jean Delvare

A message that is not in the archive (sent off-list or not yet received): [email protected]

Guenter Roeck

author

2012-12-20 14:20 UTC #4 lore raw

Quoted 8 lines · Jean Delvare

Hi Guenter,
Quoted 1 line · Guenter Roeck
Seen with latest i2c-tools from svn repository.
With the subversion repository having gone on vacation, "latest" doesn't mean much :(

Oh, right, "the latest one I have", which is svn revision 6075. Is that the latest ?

Quoted 67 lines

Quoted 9 lines
gcc 4.6:
gcc-4.6 -Llib -li2c -o tools/i2cdetect tools/i2cdetect.o tools/i2cbusses.o tools/i2cdetect.o: In function `main':
i2cdetect.c:(.text.startup+0x557): undefined reference to i2c_smbus_write_quick' i2cdetect.c:(.text.startup+0x5e9): undefined reference to i2c_smbus_read_byte'
collect2: ld returned 1 exit status
make: *** [tools/i2cdetect] Error 1
Quoted 6 lines
gcc-4.4:
gcc-4.4 -Llib -li2c -o tools/i2cdetect tools/i2cdetect.o tools/i2cbusses.o
[ no error ]
Any idea ?
I'm using gcc 4.6.2 (from openSUSE 12.1) and "the latest i2c-tools" (that would be from October 25th if I can trust the CHANGES timestamp) builds just fine for me. OTOH this is a linking problem, not building problem, so the version of "ld" may be more relevant. Are you using the same version of "ld" in both cases?
The error messages suggest that gcc (and subsequently ld) doesn't find the symbols exported by libi2c. I can't figure out any reason why it would be so. Can you show us the output of "nm lib/libi2c.so.0.1.0"? This is what I get here:
0000000000201e30 a _DYNAMIC
0000000000201fe8 a _GLOBAL_OFFSET_TABLE_
w _Jv_RegisterClasses
0000000000201e10 d __CTOR_END__
0000000000201e08 d __CTOR_LIST__
0000000000201e20 d __DTOR_END__
0000000000201e18 d __DTOR_LIST__
0000000000000f10 r __FRAME_END__
0000000000201e28 d __JCR_END__
0000000000201e28 d __JCR_LIST__
0000000000202028 a __bss_start
                 w __cxa_finalize@@GLIBC_2.2.5
0000000000000c90 t __do_global_ctors_aux
0000000000000850 t __do_global_dtors_aux
0000000000202020 d __dso_handle
                 U __errno_location@@GLIBC_2.2.5
                 w __gmon_start__
0000000000202028 a _edata
0000000000202038 a _end
0000000000000cc8 t _fini
00000000000007c8 t _init
0000000000000cd8 t _real_fini
0000000000000830 t call_gmon_start
0000000000202028 b completed.5890
0000000000202030 b dtor_idx.5892
00000000000008d0 t frame_dummy
0000000000000900 T i2c_smbus_access
0000000000000c00 T i2c_smbus_block_process_call
0000000000000a40 T i2c_smbus_process_call
0000000000000a70 T i2c_smbus_read_block_data
0000000000000950 T i2c_smbus_read_byte
00000000000009a0 T i2c_smbus_read_byte_data
0000000000000b30 T i2c_smbus_read_i2c_block_data
00000000000009f0 T i2c_smbus_read_word_data
0000000000000ad0 T i2c_smbus_write_block_data
0000000000000980 T i2c_smbus_write_byte
00000000000009d0 T i2c_smbus_write_byte_data
0000000000000ba0 T i2c_smbus_write_i2c_block_data
0000000000000940 T i2c_smbus_write_quick
0000000000000a20 T i2c_smbus_write_word_data

Quoted 2 lines

                 U ioctl@@GLIBC_2.2.5

Hmm - I seem to be having the same.

Quoted 4 lines

This could also be a Makefile dependency issue... I can't remember what, if anything, guarantees that the library is built before the tools which use it.

Repeating the command doesn't help, though.

Maybe I am missing some commits ?

Guenter

A message that is not in the archive (sent off-list or not yet received): [email protected]

Jean Delvare

2012-12-20 14:37 UTC #6 lore raw

Quoted 11 lines · Guenter Roeck

Quoted 8 lines · Jean Delvare
Hi Guenter,
Quoted 1 line · Guenter Roeck
Seen with latest i2c-tools from svn repository.
With the subversion repository having gone on vacation, "latest" doesn't mean much :(
Oh, right, "the latest one I have", which is svn revision 6075. Is that the latest ?

"svn status -u" says 6091 but I think this includes the changes to other trees (lm-sensors.) I have i2c-tools/CHANGES at revision 6083.

Quoted 8 lines

Quoted 4 lines
(...)
This could also be a Makefile dependency issue... I can't remember what, if anything, guarantees that the library is built before the tools which use it.
Repeating the command doesn't help, though.
Maybe I am missing some commits ?

The error you get doesn't ring any bell and nothing in CHANGES seems relevant.

If it helps, I have made my current SVN snapshot available at:
http://khali.linux-fr.org/devel/misc/i2c-tools-SVN.tar.gz

Signature · 1 line

Jean Delvare

A message that is not in the archive (sent off-list or not yet received): [email protected]

Guenter Roeck

author

2012-12-20 14:44 UTC #8 lore raw

Quoted 23 lines · Jean Delvare

Quoted 11 lines · Guenter Roeck
Quoted 8 lines · Jean Delvare
Hi Guenter,
Quoted 1 line · Guenter Roeck
Seen with latest i2c-tools from svn repository.
With the subversion repository having gone on vacation, "latest" doesn't mean much :(
Oh, right, "the latest one I have", which is svn revision 6075. Is that the latest ?
"svn status -u" says 6091 but I think this includes the changes to other trees (lm-sensors.) I have i2c-tools/CHANGES at revision 6083.
Quoted 7 lines
Quoted 4 lines
(...)
This could also be a Makefile dependency issue... I can't remember what, if anything, guarantees that the library is built before the tools which use it.
Repeating the command doesn't help, though.

Quoted 8 lines

Quoted 1 line
Maybe I am missing some commits ?
The error you get doesn't ring any bell and nothing in CHANGES seems relevant.
If it helps, I have made my current SVN snapshot available at:
http://khali.linux-fr.org/devel/misc/i2c-tools-SVN.tar.gz

I copied it, but get the same result.

My gcc is from Ubuntu. There is some mention of the problem on the web, on pastebin, so others seem to have the same problem.

Guenter

Jean Delvare

2012-12-20 14:53 UTC #9 lore raw

In reply to a message not in the archive

Quoted 7 lines · Jean Delvare

Quoted 6 lines · Guenter Roeck
Quoted 5 lines · Jean Delvare
Hi Guenter,
Quoted 1 line · Guenter Roeck
Seen with latest i2c-tools from svn repository.

Quoted 8 lines

Quoted 5 lines
Quoted 3 lines
With the subversion repository having gone on vacation, "latest" doesn't mean much :(
Oh, right, "the latest one I have", which is svn revision 6075. Is that the latest ?
"svn status -u" says 6091 but I think this includes the changes to other trees (lm-sensors.) I have i2c-tools/CHANGES at revision 6083.

The SVN repository should be back now, thanks to Axel Thimm.

Signature · 1 line

Jean Delvare

A message that is not in the archive (sent off-list or not yet received): [email protected]

Guenter Roeck

author

2012-12-20 16:31 UTC #11 lore raw

Quoted 11 lines · Jean Delvare

Quoted 10 lines · Jean Delvare
Quoted 9 lines · Guenter Roeck
Quoted 8 lines · Jean Delvare
Hi Guenter,
Quoted 1 line · Guenter Roeck
Seen with latest i2c-tools from svn repository.
With the subversion repository having gone on vacation, "latest" doesn't mean much :(

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
Oh, right, "the latest one I have", which is svn revision 6075. Is that the latest ?
"svn status -u" says 6091 but I think this includes the changes to other trees (lm-sensors.) I have i2c-tools/CHANGES at revision 6083.
The SVN repository should be back now, thanks to Axel Thimm.

It is, thanks. No improvement, though; I still get the same error. Trying to find out what is happening.

Guenter

Guenter Roeck

author

2012-12-20 16:39 UTC #12 lore raw

In reply to a message not in the archive

Quoted 11 lines · Jean Delvare

Quoted 10 lines · Jean Delvare
Quoted 9 lines · Guenter Roeck
Quoted 8 lines · Jean Delvare
Hi Guenter,
Quoted 1 line · Guenter Roeck
Seen with latest i2c-tools from svn repository.
With the subversion repository having gone on vacation, "latest" doesn't mean much :(

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
Oh, right, "the latest one I have", which is svn revision 6075. Is that the latest ?
"svn status -u" says 6091 but I think this includes the changes to other trees (lm-sensors.) I have i2c-tools/CHANGES at revision 6083.
The SVN repository should be back now, thanks to Axel Thimm.

I found the problem. -li2c must be specified after the .o files.

Patch:

tools/Module.mk +4 -4

index 1979248..bfd3250 100644
@@ -21,16 +21,16 @@ TOOLS_TARGETS	:= i2cdetect i2cdump i2cset i2cget
 #
 
 $(TOOLS_DIR)/i2cdetect: $(TOOLS_DIR)/i2cdetect.o $(TOOLS_DIR)/i2cbusses.o
-	$(CC) $(LDFLAGS) $(TOOLS_LDFLAGS) -o $@ $^
+	$(CC) $(LDFLAGS) -o $@ $^ $(TOOLS_LDFLAGS)
 
 $(TOOLS_DIR)/i2cdump: $(TOOLS_DIR)/i2cdump.o $(TOOLS_DIR)/i2cbusses.o $(TOOLS_DIR)/util.o
-	$(CC) $(LDFLAGS) $(TOOLS_LDFLAGS) -o $@ $^
+	$(CC) $(LDFLAGS) -o $@ $^  $(TOOLS_LDFLAGS)
 
 $(TOOLS_DIR)/i2cset: $(TOOLS_DIR)/i2cset.o $(TOOLS_DIR)/i2cbusses.o $(TOOLS_DIR)/util.o
-	$(CC) $(LDFLAGS) $(TOOLS_LDFLAGS) -o $@ $^
+	$(CC) $(LDFLAGS) -o $@ $^ $(TOOLS_LDFLAGS)
 
 $(TOOLS_DIR)/i2cget: $(TOOLS_DIR)/i2cget.o $(TOOLS_DIR)/i2cbusses.o $(TOOLS_DIR)/util.o
-	$(CC) $(LDFLAGS) $(TOOLS_LDFLAGS) -o $@ $^
+	$(CC) $(LDFLAGS) -o $@ $^ $(TOOLS_LDFLAGS)
 
 #
 # Objects

A message that is not in the archive (sent off-list or not yet received): [email protected]

Jean Delvare

2012-12-21 08:45 UTC #14 lore raw

Hi Guenter,

Quoted 19 lines · Guenter Roeck

I found the problem. -li2c must be specified after the .o files.

Patch:

tools/Module.mk +2 -2

index 1979248..bfd3250 100644
@@ -21,16 +21,16 @@ TOOLS_TARGETS	:= i2cdetect i2cdump i2cset i2cget
 #
 
 $(TOOLS_DIR)/i2cdetect: $(TOOLS_DIR)/i2cdetect.o $(TOOLS_DIR)/i2cbusses.o
-	$(CC) $(LDFLAGS) $(TOOLS_LDFLAGS) -o $@ $^
+	$(CC) $(LDFLAGS) -o $@ $^ $(TOOLS_LDFLAGS)
 
 $(TOOLS_DIR)/i2cdump: $(TOOLS_DIR)/i2cdump.o $(TOOLS_DIR)/i2cbusses.o $(TOOLS_DIR)/util.o
-	$(CC) $(LDFLAGS) $(TOOLS_LDFLAGS) -o $@ $^
+	$(CC) $(LDFLAGS) -o $@ $^  $(TOOLS_LDFLAGS)

tools/Module.mk TOOLS_TARGETS := i2cdetect i2cdump i2cset i2cget · line 36

Quoted 10 lines

tools/Module.mk +2 -2

 $(TOOLS_DIR)/i2cset: $(TOOLS_DIR)/i2cset.o $(TOOLS_DIR)/i2cbusses.o $(TOOLS_DIR)/util.o
-	$(CC) $(LDFLAGS) $(TOOLS_LDFLAGS) -o $@ $^
+	$(CC) $(LDFLAGS) -o $@ $^ $(TOOLS_LDFLAGS)
 
 $(TOOLS_DIR)/i2cget: $(TOOLS_DIR)/i2cget.o $(TOOLS_DIR)/i2cbusses.o $(TOOLS_DIR)/util.o
-	$(CC) $(LDFLAGS) $(TOOLS_LDFLAGS) -o $@ $^
+	$(CC) $(LDFLAGS) -o $@ $^ $(TOOLS_LDFLAGS)
 
 #
 # Objects

Hmm, OK. The gcc manual page is somewhat confusing on this topic but as I understand it, when processing a library, it only considers symbols which were already referenced but not defined, and discards the rest. So object files must indeed come first on the command line.

Why it has always worked for me the other way around is a mystery.

You have write permissions to the repository, so please just commit this fix, thanks.

Signature · 1 line

Jean Delvare

A message that is not in the archive (sent off-list or not yet received): [email protected]

Guenter Roeck

author

2012-12-21 16:45 UTC #16 lore raw

Quoted 38 lines · Jean Delvare

Hi Guenter,
Quoted 19 lines · Guenter Roeck
I found the problem. -li2c must be specified after the .o files.
Patch:
tools/Module.mk +2 -2
index 1979248..bfd3250 100644
@@ -21,16 +21,16 @@ TOOLS_TARGETS	:= i2cdetect i2cdump i2cset i2cget
 #
 
 $(TOOLS_DIR)/i2cdetect: $(TOOLS_DIR)/i2cdetect.o $(TOOLS_DIR)/i2cbusses.o
-	$(CC) $(LDFLAGS) $(TOOLS_LDFLAGS) -o $@ $^
+	$(CC) $(LDFLAGS) -o $@ $^ $(TOOLS_LDFLAGS)
 
 $(TOOLS_DIR)/i2cdump: $(TOOLS_DIR)/i2cdump.o $(TOOLS_DIR)/i2cbusses.o $(TOOLS_DIR)/util.o
-	$(CC) $(LDFLAGS) $(TOOLS_LDFLAGS) -o $@ $^
+	$(CC) $(LDFLAGS) -o $@ $^  $(TOOLS_LDFLAGS)
 
tools/Module.mk TOOLS_TARGETS := i2cdetect i2cdump i2cset i2cget · line 36
Quoted 10 lines
tools/Module.mk +2 -2
 $(TOOLS_DIR)/i2cset: $(TOOLS_DIR)/i2cset.o $(TOOLS_DIR)/i2cbusses.o $(TOOLS_DIR)/util.o
-	$(CC) $(LDFLAGS) $(TOOLS_LDFLAGS) -o $@ $^
+	$(CC) $(LDFLAGS) -o $@ $^ $(TOOLS_LDFLAGS)
 
 $(TOOLS_DIR)/i2cget: $(TOOLS_DIR)/i2cget.o $(TOOLS_DIR)/i2cbusses.o $(TOOLS_DIR)/util.o
-	$(CC) $(LDFLAGS) $(TOOLS_LDFLAGS) -o $@ $^
+	$(CC) $(LDFLAGS) -o $@ $^ $(TOOLS_LDFLAGS)
 
 #
 # Objects
Hmm, OK. The gcc manual page is somewhat confusing on this topic but as I understand it, when processing a library, it only considers symbols which were already referenced but not defined, and discards the rest. So object files must indeed come first on the command line.

Quoted 2 lines

Why it has always worked for me the other way around is a mystery.

Something must have changed, since it works for me with an older version of gcc (4.4).

Quoted 3 lines

You have write permissions to the repository, so please just commit this fix, thanks.

Done.

Guenter