Linker problem

Linker problem

[Rudy Gingles]

Hi all, I'm compiling an OS kernel I'm working on, and I've started to get a
weird error while linking. Basically, I'm getting 'Undefined references' to
many of the functions in my code. I've narrowed it down to the undefined
references coming from all my assembler files (.S), but as I defined all the
functions as .global, I don't see why the error occurs. I'm compiling into
elf32-i386 format, and running the linker from the same directory as all of
the source/object files. I'm at a total loss as to why it can't find those
functions. And to add to it, the link works (for the most part) when
compiled under djgpp (DOS gcc port) rather than under Linux. Why the
difference? Maybe something isn't setup right, or a path not specified? And
help or hints or anything would be appreciated, I'm at a total loss here.
Thanks!!

Command line:

ld -T kernel.lds -o out.elf entry.o (...more files...) init.o -lc -lgcc

LD script used (kernel.lds):

/* ------------------------------------------ */
OUTPUT_FORMAT("elf32-i386")
OUTPUT_ARCH(i386)
ENTRY(_start)

SEARCH_DIR("/usr/lib")

SECTIONS
{
    . = 0x100000;
    .text :
    {
        _btext = .;
        *(.text)
        _etext = .;
    }
    .data ALIGN(0x1000) :
    {
        _bdata = .;
        *(.data)
        _edata = .;
    }
    .bss ALIGN(0x1000) :
    {
        _bbss = .;
        *(.bss)
        *(COMMON)
        _ebss = .;
    }
    .note.sig ALIGN(0x1000) :
    {
        _bsig = .;
        *(.note.sig)
        _esig = .;
    }
}
/* ------------------------------------------ */

--
Rudy Gingles



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.292 / Virus Database: 157 - Release Date: 10/26/2001

RE: Linker Problem

[Ravishankar S]

Hi,

The problem could be because you are trying to compile and link every
file, instead of compiling every file and link all the object files at
the end.

Regards,
Rvaishankar

-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
Behalf Of joe_squid@sbcglobal.net
Sent: Sunday, September 17, 2006 2:39 AM
To: gcc-help@gcc.gnu.org
Subject: Linker Problem


I am having a problem with the linker. When the linker reaches this bit
of
code:
 
    anAccount[arrayPosition].setAccountNumber(acctNum);
 
It displays the following message:
 
  [Linker error] undefined reference to `Account::setAccountNumber(int)'

 
This bit of code appears in a function I have placed in the main.cpp
file. I have several other similar lines of code in other such
functions, and all are giving me the same error. All of these such
functions are called by main(), and all are prototyped and implemented
within the main.cpp file. 
I thought that maybe anAccount was out of scope, but that does not seem
to be the case. I had to declare it as a global variable, since
declaring it directly in main resulted in it not being visible to my
other functions. However, declaring it this way does not result in the
linker error, although I believe that these errors appear before the
linker is reached, so I do not know if the linker errors would still
exist if I could devise another way of declaring anAccount so that it
would stay in scope. Any help you could provide would be greatly
appreciated.
 
 
 
Thanks,
Joe Hayes

__________ NOD32 1.1454 (20060321) Information __________

This message was checked by NOD32 antivirus system. http://www.eset.com

Linker Problem

[joe_squid]

I am having a problem with the linker. When the linker reaches this bit of
code:
 
    anAccount[arrayPosition].setAccountNumber(acctNum);
 
It displays the following message:
 
  [Linker error] undefined reference to `Account::setAccountNumber(int)' 
 
This bit of code appears in a function I have placed in the main.cpp file. I
have several other similar lines of code in other such functions, and all
are giving me the same error. All of these such functions are called by
main(), and all are prototyped and implemented within the main.cpp file. 
I thought that maybe anAccount was out of scope, but that does not seem to
be the case. I had to declare it as a global variable, since declaring it
directly in main resulted in it not being visible to my other functions.
However, declaring it this way does not result in the linker error, although
I believe that these errors appear before the linker is reached, so I do not
know if the linker errors would still exist if I could devise another way of
declaring anAccount so that it would stay in scope. Any help you could
provide would be greatly appreciated.
 
 
 
Thanks,
Joe Hayes

Re: linker problem

[Perry Smith]

Plus, if the system is old, the sequence of object files inside a  
library is important.  Older systems made one pass through the object  
files inside a library.  That is why there is ranlib.  It may be that  
no common systems still have this characteristic.

On Apr 25, 2006, at 9:09 AM, John Love-Jensen wrote:

> Hi Javier,
>
> I don't think that is a linker problem.  I think the linker is  
> working as
> advertised.
>
> Keep in mind that the linker works like this:
>
> 1. Open next file in the list, in command line order.
>
> 2. .o file?  Take in all the symbols, wholesale.  Goto 1.
>
> 3. .a file?  For any current outstanding missing symbols, resolve  
> them by
> the available symbols in the .a file.  Take those .o files from  
> the .a that
> match the unresolved symbols (and remove those unresolved symbols  
> from the
> list).  Goto 1.
>
> 4. .so file?  For any current outstanding missing symbols, resolve  
> them by
> the available symbols in the .so file.  Remove those unresolved  
> symbols from
> the list, and tag the executable with the load-time dependency on  
> that .so.
> Goto 1.
>
> You'll notice that the resolution of symbols is a single pass,  
> first come
> first serve basis.
>
> So the order of your .a and .so files is of critical importance, if  
> they
> have dependencies on one another.
>
> HTH,
> --Eljay
>
>

Re: linker problem

[John Love-Jensen]

Hi Javier,

I don't think that is a linker problem.  I think the linker is working as
advertised.

Keep in mind that the linker works like this:

1. Open next file in the list, in command line order.

2. .o file?  Take in all the symbols, wholesale.  Goto 1.

3. .a file?  For any current outstanding missing symbols, resolve them by
the available symbols in the .a file.  Take those .o files from the .a that
match the unresolved symbols (and remove those unresolved symbols from the
list).  Goto 1.

4. .so file?  For any current outstanding missing symbols, resolve them by
the available symbols in the .so file.  Remove those unresolved symbols from
the list, and tag the executable with the load-time dependency on that .so.
Goto 1.

You'll notice that the resolution of symbols is a single pass, first come
first serve basis.

So the order of your .a and .so files is of critical importance, if they
have dependencies on one another.

HTH,
--Eljay 

linker problem

[Javier Cuevas]

Hi all,

I'm developing an application that uses a modular design in C++. The modular
design allows to the developers to add functionality to the main application
just adding libraries. 

The library concept it's very similar to the plugins concept. Each library
is a separate project that creates a static library "libXXX.a" that includes
all ".o" modules for the library. There is a main project that call a well
know function in each library to initialize it. During the initialization
the library creates all the functionality that it provides. Mainly that's
the application design.

So, I'm having strange link behaviors when a class is defined in a library
and it is used in another library. 

If we define a class A in classA.cpp file that creates the classA.o compiled
module that belongs to libA.a library...

...and...

...we define a class B t in classB.cpp file that creates the classB.o
compiled module that belongs to libB.a library. 
We define a function InitLibraryB( void ) that creates an instance of classB
within initlibrary.cpp that creates initlibrary.o that belongs to libB.a
library.

Then we have a main.cpp file that contains the main function that
indirectely creates an instace of class B calling the "IniLibraryB"
function.

Then If I try to link the application using

"g++ -o main main.cpp libA.a libB.a" then the linker finds a problem looking
for the class A method implementations.

But if instead of using "g++ -o main main.cpp libA.a libB.a" I use " g++ -o
main main.cpp libA.a libB.a classA.o" the linker successfully links the
application. 

Another way to get the application linked is to simulate the use the class A
in the main module(1) or using class A inside the libA.a library.(2) 

- Example for (1): If I create in main.cpp an if clause that never enters
but the condition is written in a way that the compiler can't optimize it
then "g++ -o main main.cpp libA.a libB.a" links the application. 

int main( int argn, char **argc )
{
  if( argn==-123 ) // We have never enter in the if statement
  {
    class B;  // That creates the instance
    B.Init(); // we use the class in order to avoid the compiler "var not 
              //use" message.
  }

  InitLibraryA( void );
  InitLibraryB( void );       

  return 0;
}

- Example for (2): If within the libA.a exists a function InitLibraryA that
creates a class A and this function is called from the main function from
main.cpp then "g++ -o main main.cpp libA.a libB.a" links the application. 

I'm using the first workaround but I would like to understand what's wrong
and to solve the problem in a better way.

Thanks

Javier Cuevas Domingo
e-mail   : javier.cuevas@eupla.unizar.es

Re: Linker problem

[Brian Dessent]

"Jakub Horn (jakuhorn)" wrote:

> efined reference to `_prinf'

You spelled 'printf' wrong.

Linker problem

[Jakub Horn (jakuhorn)]

Hello,

I have installed gcc within cygwin enviornment, and this is output I get
always even if I am trying to compile simples programs. Can anybody
help?  

D:\Documents and Settings\jakuhorn\c>gcc -o hello.exe hello.c
/cygdrive/d/DOCUME~1/jakuhorn/LOCALS~1/Temp/ccTTpoz2.o:hello.c:(.text+0x
32): und
efined reference to `_prinf'
collect2: ld returned 1 exit status


Thanks

Jakub

Linker Problem

[Chandra Sekhar G]

Hi,

   I am sorry, if this is not an appropriate list for my problem.  In
that case can you suggest me, a more suitable list.

   I am using the compiler powerpc-eabi-gcc and the linker
powerpc-eabi-ld.  My host system is a linux machine.  I am using the
RTOS 'eCos' for my application.  Recently I added a few packages of the
eCos to my existing (which is working fine) code.  They are 1. Net
package (a TCP/IP suit) 2. isoinfra (provides iso standard libc and
libm).

When we build the eCos code, it creates two libraries.  One is
libtarget.a and the other is libextras.a.  I am guessing, which objects
should go where is specified in configuration definition language files
of eCos.


When I prepre the executable and run it on the target, I got sigill
exception.  After studying the case I concluded that there is a problem
in memroy allocation to the variables.

The problems I am facing are -

   1.  There are a few static variables (local to the file in which are
they are defined) overlaping with the global variables.  All the local
variables are defined in the newly added code. For example, there are
two variables 'ifnet' and 'net_mem'.  ifnet is a golobal variable and
net_mem is a static variable.  ifnet is a structure of two pointers,
whose length is 8 bytes.  net_mem is an address and its length is 4
bytes.  The address of ifnet is
0x0203652C and the address of net_mem is 0x0236530.  Please note that
these two are overlaping.

  2.  There are overlaps with in the gloabal variables also.  My
observation regarding this is -
        If there are two global variables with same address, then one
variable is getting defined in a file whose object is put in the
library, libtarget.a and the other variable is getting defined in a file

whose object is put in the library libextras.a.  I am not confident of
this observation.

  All the variables I discussed about are comming in the category of
.sbss.

  I did the following experiment -
       I changed all the static variables to global then compiled and
linked.  Then problem 1 disappears.

Please suggest me the places where to look to solve these problems.

Thanks,
chandra

Re: linker problem

[hiufungeric.tse]

 
 I installed a binary version of gcc3.0.1 on an ia64 machine and
 encounter a linker error:

/usr/bin/ld: section .debug_info [0000000000000000 -> 0000000001f173a1] 
overlaps section .hash [0000000000000120 -> 00000000000049ab]
/usr/bin/ld: section .debug_abbrev [0000000000000000 -> 0000000000026601] 
overlaps section .hash [0000000000000120 -> 00000000000049ab]
/usr/bin/ld: section .debug_line [0000000000000000 -> 000000000006e873] 
overlaps section .hash [0000000000000120 -> 00000000000049ab]
/usr/bin/ld:  exit status
make: *** [finally_chunk.so] Error 1

 How to overcome this problem ?

 
thanks
eric

linker problem

[thomas.porschberg]

I installed a binary version of gcc3.0.1 on a HP-UX machine and
encounter a linker error:

/usr/ccs/bin/ld: Unsatisfied symbols:
   __builtin_va_start (code)
collect2: ld returned 1 exit status
*** Error exit code 1

How to overcome this problem ?

-- 
I found some dead inodes in your brain.
Please run humbrfsck manually to repair your head.

Linker problem.

[The G]

I am trying to link a C++ program that uses the stdio.h vsprintf() function.

I can compile and assemble without problems.

When I try to link I get a the following error:
project.cpp:52: undefined reference to `vsprintf'

I have also tried using the following options:
-lc -lgcc -lstdcx
to bring in libraries libc.a libgcc.a libstdcx.a


Any ideas?


--

Glenn