Re: Where are Reg* implemented?

Re: Where are Reg* implemented?

[Wei Ku]

 My impression ( an what I always do ) is to put the options before the
files to be compiled or linked as following:

g++ -o outfilename -O -L libpath -l lib file.c file.o ...

Sincerely,
Wei Ku

***************************************
Department of Physics and Astronomy
The University of Tennessee
1408 Circle Drive
Knoxville, Tennessee 37996-1200
weiku@utkux.utcc.utk.edu
---------------------------------------
Solid State Division
Oak Ridge National Laboratory
P.O.Box 2008
Oak Ridge, TN 37831-6032
Phone: (423) 574-5795
Fax: (423) 574-4143
weiku@solid.ssd.ornl.gov
***************************************

-----Original Message-----
From: Justin Hopkins <hop@elwood.pionet.net>
To: gnu-win32@cygnus.com <gnu-win32@cygnus.com>
Date: Thursday, July 31, 1997 10:27 PM
Subject: Re: Where are Reg* implemented?



>At 01:08 AM 7/31/97 +0100, you wrote:
>>I copied this testprogram from the M$ manuals, which uses
>>the RegOpenKeyExA, RegQueryValueExA, RegQueryInfoKeyA and
>>RegCloseKey functions. They are defined in windows.h, and
>>a quick "strings -f *.a | grep Reg" finds the symbols in
>>libadvapi32.a
>>
>>gcc -ladvapi32    pdh.c   -o pdh
>
>
>Try using this command-line>
>  gcc -o pdh.exe pdh.c -ladvapi32
>
>I may be wrong, but I think gcc/g++ expect your libraries
>to be at the end of the command line invocation.
>
>Justin Hopkins
>
>-
>For help on using this list (especially unsubscribing), send a message to
>"gnu-win32-request@cygnus.com" with one line of text: "help".
>

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Where are Reg* implemented?

[Jason Zions]

> My impression ( an what I always do ) is to put the options before the
> files to be compiled or linked as following:
> 
> g++ -o outfilename -O -L libpath -l lib file.c file.o ...

Usually won't work. *Most* options need to go up front; -O, -L, etc.

Library options (-l) *must* be specified in the *correct order* so that
resolution can be controlled. By listing a library, -lfoo, before any .o
files have been loaded, you're trying to resolve entrypoints from the
library before the loader has seen any unresolved names.

First list the .o files, then the libraries you want the loader to use
to resolve entrypoints, in the order you want it to try. If two
libraries both have a particular entrypoint, the first one the loader
sees (once it sees the unresolved name from another file) is the one it
loads, and it silently ignores the latter one (because the name has
already been resolved).

This is basic stuff, folks. Read a Unix system's "ld" man page.

Jason

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Where are Reg* implemented?

[Ku Wei]

Good point Jason about the ld man page. However, we are discuessing gcc 
or g++, not ld.

It is clear that we need to put the main() entry ( in one of the .c or 
.cxx files) as the first of the source file list ( including .o and .c). 
However, the libraries are not 'source files' to g++. Instead, they are 
assigned as 'options' by '-l'. Therefore, it is really the compiler's 
responsibility to add these options to correct position in parameter list 
passed to 'ld' later.

For example, for IBM AIX C compiler, you are only allowed to put 
parameters "before" the source file list: xlC [options] files
On the other hand, g++ allows two different syntex: g++ [option|filenam] ...

Anyway, why use same name in your own code as the name in libraries to 
confuse the linker ?

Sincerely,
Wei Ku

***************************************
Department of Physics and Astronomy
The University of Tennessee
1408 Circle Drive
Knoxville, Tennessee 37996-1200
weiku@utkux.utcc.utk.edu
---------------------------------------
Solid State Division
Oak Ridge National Laboratory
P.O.Box 2008
Oak Ridge, TN 37831-6032
Phone: (423) 574-5795
Fax: (423) 574-4143
weiku@solid.ssd.ornl.gov
***************************************

On Fri, 1 Aug 1997, Jason Zions wrote:

> > My impression ( an what I always do ) is to put the options before the
> > files to be compiled or linked as following:
> > 
> > g++ -o outfilename -O -L libpath -l lib file.c file.o ...
> 
> Usually won't work. *Most* options need to go up front; -O, -L, etc.
> 
> Library options (-l) *must* be specified in the *correct order* so that
> resolution can be controlled. By listing a library, -lfoo, before any .o
> files have been loaded, you're trying to resolve entrypoints from the
> library before the loader has seen any unresolved names.
> 
> First list the .o files, then the libraries you want the loader to use
> to resolve entrypoints, in the order you want it to try. If two
> libraries both have a particular entrypoint, the first one the loader
> sees (once it sees the unresolved name from another file) is the one it
> loads, and it silently ignores the latter one (because the name has
> already been resolved).
> 
> This is basic stuff, folks. Read a Unix system's "ld" man page.
> 
> Jason
> 
> 
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Where are Reg* implemented?

[Jason Zions]

> Good point Jason about the ld man page. However, we are discuessing gcc
> or g++, not ld.

A difference that makes no difference; see below.

> It is clear that we need to put the main() entry ( in one of the .c or
> .cxx files) as the first of the source file list ( including .o and .c).
> However, the libraries are not 'source files' to g++. Instead, they are
> assigned as 'options' by '-l'. Therefore, it is really the compiler's
> responsibility to add these options to correct position in parameter list
> passed to 'ld' later.

And how on earth is gcc supposed to guess at this? There are times when
what *must* be passed to the loader is this:

    file1.o file2.o -lmylib file3.o file4.0 -lotherlib

If gcc can't preserve this ordering, it's fundamentally broken.

Jason

P.S. I'd address you informally, as you did me, but I admit to being
stumped as to whether I should call you Ku, Wei, or both (and in which
order - I've seen your address come with your name in both orders...
:-).


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Where are Reg* implemented?

[William Greathouse]

Ku Wei wrote:
> 
> Good point Jason about the ld man page. However, we are discuessing
> gcc
> or g++, not ld.
> 
> It is clear that we need to put the main() entry ( in one of the .c or
> .cxx files) as the first of the source file list ( including .o and
> .c).
> However, the libraries are not 'source files' to g++. Instead, they
> are
> assigned as 'options' by '-l'. Therefore, it is really the compiler's
> responsibility to add these options to correct position in parameter
> list
> passed to 'ld' later.

You said the operative word -- "options".  Libraries (-l) are _not_
options in the normal sense.  They are "special" object modules to
include in the final output.

> 
> For example, for IBM AIX C compiler, you are only allowed to put
> parameters "before" the source file list: xlC [options] files
> On the other hand, g++ allows two different syntex: g++
> [option|filenam] ...

AIX will allow you to put -l at the end (as is typical of most
compiler/linkers) as it is not an option but a shorthand representation
of a special object file to search during linking.

It is also necessary to note that AIX does not implement ld in a
"normal" manner -- it will search all object modules in a circular
fashion, left to right and back to the front, until all references are
resolved (or a complete pass does not resolve a symbol).  Typical
linkers do one pass left to right to resolve references -- each object
is evaluated once for unresolved external references, which must be
resolved by an object to its right on the link line.  In this case it
would not make sense to include the library before the main object, as
no portion of the library would be incorporated in to the output,
because no external references exist when it is scanned.

> Anyway, why use same name in your own code as the name in libraries to
> confuse the linker ?
> 
> Sincerely,
> Wei Ku
> 

Enjoy the debate,
Bill
begin:          vcard
fn:             William Greathouse
n:              Greathouse;William
org:            SMV America Engineering
adr:            8380 Darrow Road;;;Twinsburg;OH;44087;
email;internet: wgreathouse@smva.com
title:          Senior Engineer
tel;work:       (216) 425-1340  x4006
tel;fax:        (216) 405-7684
note:           wgg@netcom.com -- Home Account
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
end:            vcard

Re: Where are Reg* implemented?

[ian]

>It is also necessary to note that AIX does not implement ld in a
>"normal" manner -- it will search all object modules in a circular
>fashion, left to right and back to the front, until all references are
>resolved (or a complete pass does not resolve a symbol).  Typical
>linkers do one pass left to right to resolve references -- each object
>is evaluated once for unresolved external references, which must be
>resolved by an object to its right on the link line.  In this case it
>would not make sense to include the library before the main object, as
>no portion of the library would be incorporated in to the output,
>because no external references exist when it is scanned.

Technically, what AIX does is include the entire archive in the link.
It then uses garbage collection--a feature of the AIX linker--to
discard contents of the archive which are not needed.

The real point, as I see it, is that you can't really argue about the
behaviour of the GNU linker based on AIX.  The GNU linker is a
standard Unix linker.  The AIX linker is not.

Ian
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Where are Reg* implemented?

[Rolf Welde Skeie]

Rolf Welde Skeie wrote:
> (BTW: shared libraries can be placed before the target(-o xxx)...)

Wrong again. The SunOS5 linker can have libraries placed before
the target, that's why I tried it per default under GnuWin32...
Topic closed ;-)
-- 
  Rolf Welde Skeie        Senior Design Engineer    =+=
__ mailto:rws@scali.no_____http://www.scali.com___====+====__
  Tel   +47 6384 6700     Scali AS               ====+====
  Fax   +47 6384 4005     Hvamstubben 17         ====+====
  Home  +44 181 946 0650  2013 Skjetten             =+= 
  Mob   +47 9095 4406     NORWAY                  o==V==o
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Where are Reg* implemented?

[Justin Hopkins]

At 01:08 AM 7/31/97 +0100, you wrote:
>I copied this testprogram from the M$ manuals, which uses
>the RegOpenKeyExA, RegQueryValueExA, RegQueryInfoKeyA and
>RegCloseKey functions. They are defined in windows.h, and
>a quick "strings -f *.a | grep Reg" finds the symbols in
>libadvapi32.a
>
>gcc -ladvapi32    pdh.c   -o pdh


Try using this command-line>
  gcc -o pdh.exe pdh.c -ladvapi32

I may be wrong, but I think gcc/g++ expect your libraries
to be at the end of the command line invocation.

Justin Hopkins

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Where are Reg* implemented?

[Rolf Welde Skeie]

I copied this testprogram from the M$ manuals, which uses
the RegOpenKeyExA, RegQueryValueExA, RegQueryInfoKeyA and
RegCloseKey functions. They are defined in windows.h, and
a quick "strings -f *.a | grep Reg" finds the symbols in
libadvapi32.a

gcc -ladvapi32    pdh.c   -o pdh
C:\tmp\cc0012571.o(.text+0x129):pdh.c: undefined reference to
`RegOpenKeyExA@20'
C:\tmp\cc0012571.o(.text+0x14a):pdh.c: undefined reference to
`RegQueryValueExA@24'
C:\tmp\cc0012571.o(.text+0x153):pdh.c: undefined reference to
`RegCloseKey@4'
C:\tmp\cc0012571.o(.text+0x186):pdh.c: undefined reference to
`RegOpenKeyExA@20'
C:\tmp\cc0012571.o(.text+0x1a7):pdh.c: undefined reference to
`RegQueryInfoKeyA@48'
C:\tmp\cc0012571.o(.text+0x1db):pdh.c: undefined reference to
`RegQueryValueExA@24'
C:\tmp\cc0012571.o(.text+0x2d1):pdh.c: undefined reference to
`RegQueryValueExA@24'
make: *** [pdh] Error 1

What am I missing??
-- 
  Rolf Welde Skeie        Senior Design Engineer    =+=
__ mailto:rws@scali.no_____http://www.scali.com___====+====__
  Tel   +47 6384 6700     Scali AS               ====+====
  Fax   +47 6384 4005     Hvamstubben 17         ====+====
  Home  +44 181 946 0650  2013 Skjetten             =+= 
  Mob   +47 9095 4406     NORWAY                  o==V==o

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".