linking problem

linking problem

[Guenther Sohler]

Hallo Group,

I downloaded the qt-2.3 library for windows. these have visual studio 6.0
library format., and i want to link
the libraries to my object files to generate an exe file.
These libraries are found by the linker, they are accepted - the format is
recognized, but it does not resolve the linking errors. There are still the
unresolved references from my application to qt functions.

Does anybody of you has a clue, whats going on ?

Guenther Sohler

NewLogic Technologies AG 
Millennium Park 6
A-6890 Lustenau
                                           Phone: +43-5577-62000-507
E-Mail: guenther.sohler@newlogic.com       Fax:   +43-5577-62000-988


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: linking problem

[Pavel Tsekov]

You won't be able to do this (at least ATM). MSVC and gcc use different
ways to describe the C++ symbols.


Guenther Sohler wrote:

> Hallo Group,
> 
> I downloaded the qt-2.3 library for windows. these have visual studio 6.0
> library format., and i want to link
> the libraries to my object files to generate an exe file.
> These libraries are found by the linker, they are accepted - the format is
> recognized, but it does not resolve the linking errors. There are still the
> unresolved references from my application to qt functions.
> 
> Does anybody of you has a clue, whats going on ?



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Linking problem

[Larry Hall]

At 02:14 AM 11/26/2004, you wrote:
>Dear All,
>
>  I use RegisterDeviceNotification Win32 API in my
>program. While compiling under cygwin, linker reports
>that cannot find _RegisterDeviceNotification symbol.
>And I searched and found that
>RegisterDeviceNotification's text is contained in
>libuser32.a, but its symbol is appended @12, what's
>this?
>  Please help me, thanks!


Welcome to Windows.  This is not a Cygwin specific issue so you should 
consult further with a Windows list forum if you have further questions
on this issue.  For now, I'll point you to a couple of links on the MSDN
that should help you get a better understanding of what's going on:

<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_core_adjusting_naming_conventions.asp>

<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_core_adjusting_naming_conventions.asp>

If all else fails and you just need to get something working without any
understanding, you can try adding the 'ld' flag '--enable-stdcall-fixup'.
But really, you should read the above so you understand what you're missing
and what you need first.


--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746                     


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Linking problem

[向阳 韩]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312, Size: 967 bytes --]

Dear All,

  I use RegisterDeviceNotification Win32 API in my
program. While compiling under cygwin, linker reports
that cannot find _RegisterDeviceNotification symbol.
And I searched and found that
RegisterDeviceNotification's text is contained in
libuser32.a, but its symbol is appended @12, what's
this?
  Please help me, thanks!

BR,
Speer Han

_________________________________________________________
Do You Yahoo!?
150ÍòÇúMP3·è¿ñËÑ£¬´øÄú´³ÈëÒôÀÖµîÌÃ
http://music.yisou.com/
ÃÀÅ®Ã÷ÐÇÓ¦Óо¡ÓУ¬ËѱéÃÀͼ¡¢ÑÞͼºÍ¿áͼ
http://image.yisou.com
1G¾ÍÊÇ1000Õ×£¬ÑÅ»¢µçÓÊ×ÔÖúÀ©ÈÝ£¡
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Linking Problem

[Heribert Dahms]

Hi Krishna,

I know nothing about the Ada parameter passing convention,
but your problem doesn't look cygwin specific to me.
Ada obviously expects passing a pointer to your structure (by reference),
while you are passing the structure (of three 4-byte fields) directly (by
value).

Bye, Heribert (heribert_dahms@icon-gmbh.de)

> -----Original Message-----
> From:	Krishna, Buska (IE10) [SMTP:Krishna.Buska@honeywell.com]
> Sent:	Friday, August 24, 2001 06:54
> To:	cygwin@cygwin.com
> Subject:	Linking Problem
> Importance:	High
> 
> Hi all
> 
> 	I got a strange problem. I am having a  .a file which exports a
> function with 2 arguments, one is a record with three fields and the other
> one is a void *.  We have formed the archive file using cygwin. The
> exported
> function is exporting at 16 value. That is, in the export symbols I could
> see  function@16. As I know if there are two parameters in the exported
> function, it should be exported @8 only. When I am trying to import the
> same
> function using a C program it is importing this function @16 only. But if,
> I import the same function in Ada program (I am using GNAT3.13p compiler.)
> by using pragma Import it is importing @8. So its giving linking problem. 
> What could be the problem? The source code in the archive  file is written
> in C. 
> 
> Thanks in advance.
> 
> Krishna
> 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Linking Problem

[Krishna, Buska (IE10)]

Hi all

	I got a strange problem. I am having a  .a file which exports a
function with 2 arguments, one is a record with three fields and the other
one is a void *.  We have formed the archive file using cygwin. The exported
function is exporting at 16 value. That is, in the export symbols I could
see  function@16. As I know if there are two parameters in the exported
function, it should be exported @8 only. When I am trying to import the same
function using a C program it is importing this function @16 only. But if,
I import the same function in Ada program (I am using GNAT3.13p compiler.)
by using pragma Import it is importing @8. So its giving linking problem. 
What could be the problem? The source code in the archive  file is written
in C. 

Thanks in advance.

Krishna


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Linking problem

[Earnie Boyd]

--- Reuben Thomas <rrt1001@cam.ac.uk> wrote:
> > Here's the deal, you're addressing uninitialized pointers.  The addresses
> > you're addressing are changed by the mear moving of objects so that in one
> case
> > your addressing memory outside of the allocated memory for the process and
> in
> > the other case your addressing memory within the allocated memory for the
> > process.  You may even find that executing the "program that works" may
> give
> > SIGSEGV if started by gdb or even strace.  Often a program that SIGSEGV's
> will
> > not do so when started with gdb or strace.
> 
> Is this really true? The executable isn't even getting as far as
> MainCRTStartup before crashing...
> 

Please, also CC the list, I can't know everything and if I'm wrong someone
we'll correct me.  AFAI've experienced, it is true, YMMV.  As for not getting
to MainCRTStartup, the references must be in one of the DLL's that's loaded
before MainCRTStartup is executed.

Cheers,

=====
Earnie Boyd
mailto:earnie_boyd@yahoo.com

---         < http://earniesystems.safeshopper.com >         ---
--- Cygwin: POSIX on Windows < http://gw32.freeyellow.com/ > ---
---   Minimalist GNU for Windows < http://www.mingw.org/ >   ---

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Linking problem

[Earnie Boyd]

--- Reuben Thomas <rrt1001@cam.ac.uk> wrote:
> 
> The first binary (exc3.exe) doesn't work, and crashes with the infamous
> 
> Application Error
> The application failed to initialize properly (0xc0000005). Click on OK to
> terminate the application
> 
> message in a Windows pop-up message box.
> 
> The second version (except.exe) runs correctly, producing "hi".
> 
> If I run exc3.exe in gdb (gdb --nw exc3.exe, then run) I get three SIGSEGVs,
> before the error "Program exited with code 0200", then the rather bizarre
> "You can't do that without a process to debug."
> 
> The only difference between the two sets of libraries used is the order in
> which the directories holding them were created. If I create a third set of
> directories in the same order as those used to link except.exe, and copy the
> import libraries into them, everything works.
> 

Here's the deal, you're addressing uninitialized pointers.  The addresses
you're addressing are changed by the mear moving of objects so that in one case
your addressing memory outside of the allocated memory for the process and in
the other case your addressing memory within the allocated memory for the
process.  You may even find that executing the "program that works" may give
SIGSEGV if started by gdb or even strace.  Often a program that SIGSEGV's will
not do so when started with gdb or strace.

Cheers,

=====
Earnie Boyd
mailto:earnie_boyd@yahoo.com

---         < http://earniesystems.safeshopper.com >         ---
--- Cygwin: POSIX on Windows < http://gw32.freeyellow.com/ > ---
---   Minimalist GNU for Windows < http://www.mingw.org/ >   ---

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Linking problem

[Reuben Thomas]

On Thu, 23 Nov 2000, Reuben Thomas wrote:

[snip]
> The first binary (exc3.exe) doesn't work, and crashes with the infamous
> 
> Application Error
> The application failed to initialize properly (0xc0000005). Click on OK to
> terminate the application
[snip]
> Surely the order in which the directories holding the import libraries were
> created shouldn't affect the binaries created by the linker?!

Some more digging reveals that (AFAICS) the output of ld -verbose for the
two binaries is identical. What is not identical is the order of the DLLs
written in to the executables. I've looked at the source for ld and the bfd
library, but I'm rather overwhelmed by it. Can anyone tell me where the
names of the DLLs are being written into the executable?

(Hmm...perhaps I should take this to the binutils list...)

-- 
http://sc3d.org/rrt/ | violence, n.  bravery for cowards


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Linking problem

[Reuben Thomas]

I have a bunch of DLLs which I'm linking executables against (as it happens,
the libraries for the Glasgow Haskell Compiler (www.haskell.org/ghc/), of
which I'm a developer).

My problem is as follows: I have a hello-worldy sort of program. I have two
identical copies of the (Haskell) import libraries I want to link against,
in different directory structures. The strange thing is that though the
libraries are identical, and though the collect2 command-lines issued to
link the binaries are identical (up to directory names; the order is the
same), the resulting binaries have different cygcheck outputs:

[11:18:53 tests]$ cygcheck exc3.exe
Found: .\exc3.exe
.\exc3.exe
  C:\WINNT\System32\KERNEL32.dll
    C:\WINNT\System32\NTDLL.DLL
  C:\WINNT\System32\crtdll.dll
  C:\ghc\ghc-4.08.1\bin\HSlang.dll
    C:\ghc\ghc-4.08.1\bin\HSstd_cbits.dll
      C:\ghc\ghc-4.08.1\bin\HSrts.dll
        C:\ghc\ghc-4.08.1\bin\HSstd.dll
          C:\ghc\ghc-4.08.1\bin\gmp.dll
      C:\WINNT\System32\WSOCK32.DLL
        C:\WINNT\System32\WS2_32.DLL
          C:\WINNT\System32\MSVCRT.DLL
          C:\WINNT\System32\ADVAPI32.DLL
            C:\WINNT\System32\RPCRT4.DLL
          C:\WINNT\System32\WS2HELP.DLL
    C:\ghc\ghc-4.08.1\bin\HSlang_cbits.dll

Use -h to see help about each section
[11:58:27 tests]$ cygcheck except.exe
Found: .\except.exe
.\except.exe
  C:\ghc\ghc-4.08.1\bin\HSstd.dll
    C:\ghc\ghc-4.08.1\bin\gmp.dll
      C:\WINNT\System32\crtdll.dll
        C:\WINNT\System32\KERNEL32.dll
          C:\WINNT\System32\NTDLL.DLL
    C:\ghc\ghc-4.08.1\bin\HSrts.dll
    C:\ghc\ghc-4.08.1\bin\HSstd_cbits.dll
      C:\WINNT\System32\WSOCK32.DLL
        C:\WINNT\System32\WS2_32.DLL
          C:\WINNT\System32\MSVCRT.DLL
          C:\WINNT\System32\ADVAPI32.DLL
            C:\WINNT\System32\RPCRT4.DLL
          C:\WINNT\System32\WS2HELP.DLL
  C:\ghc\ghc-4.08.1\bin\HSlang.dll
    C:\ghc\ghc-4.08.1\bin\HSlang_cbits.dll

Use -h to see help about each section

(The DLLs starting with HS are the Haskell libraries.)

The first binary (exc3.exe) doesn't work, and crashes with the infamous

Application Error
The application failed to initialize properly (0xc0000005). Click on OK to
terminate the application

message in a Windows pop-up message box.

The second version (except.exe) runs correctly, producing "hi".

If I run exc3.exe in gdb (gdb --nw exc3.exe, then run) I get three SIGSEGVs,
before the error "Program exited with code 0200", then the rather bizarre
"You can't do that without a process to debug."

The only difference between the two sets of libraries used is the order in
which the directories holding them were created. If I create a third set of
directories in the same order as those used to link except.exe, and copy the
import libraries into them, everything works.

As far as I can discover, the error I'm getting means that the DLLs aren't
initialising properly. The Haskell library DLLs don't provide DllMain, so
they use the default Cygwin version.

Surely the order in which the directories holding the import libraries were
created shouldn't affect the binaries created by the linker?!

I'm using Cygwin 1.1.5 on Win2K SP1; the output of cygcheck -s follows:

Cygnus Win95/NT Configuration Diagnostics
Current System Time: Thu Nov 23 12:14:53 2000

WinNT Ver 5.0 build 2195 

Path:	/usr/bin
	/usr/local/bin
	/WINNT/system32
	/WINNT
	/WINNT/system32/WBEM
	/usr/bin
	/usr/local/bin
	/ghc/ghc-4.08.1/bin
	/happy/happy-1.8/bin
	/Program Files/Microsoft Visual Studio/Common/Tools/WinNT
	/Program Files/Microsoft Visual Studio/Common/MSDev98/Bin
	/Program Files/Microsoft Visual Studio/Common/Tools
	/Program Files/Microsoft Visual Studio/VC98/bin
	/texmf/miktex/bin
	/gstools/gs5.03
	/gstools/gsview
	/jade

SysDir: C:\WINNT\System32
WinDir: C:\WINNT

PWD = `/TEMP/tests'
CYGWIN32 = `tty'
MAKE_MODE = `unix'
HOME = `/Winnt/Profiles/v-reubth'

Use `-r' to scan registry

a:  fd           N/A    N/A                    
c:  hd  NTFS    3796Mb  84% CP CS UN PA FC     
d:  hd  NTFS     337Mb  61% CP CS UN PA FC     Local Disk
e:  cd           N/A    N/A                    
f:  fd           N/A    N/A                    

C:\bin  /usr/bin  user    textmode
C:\lib  /usr/lib  user    textmode
\\.\a:  /dev/fd0  user    textmode
C:    /        user    textmode

Found: C:\bin\bash.exe
Found: \bin\bash.exe
Found: C:\bin\cat.exe
Found: \bin\cat.exe
Found: C:\bin\cpp.exe
Found: \bin\cpp.exe
Found: C:\bin\find.exe
Found: \bin\find.exe
Found: C:\bin\gcc.exe
Found: \bin\gcc.exe
Found: C:\bin\gdb.exe
Found: \bin\gdb.exe
Found: C:\bin\ld.exe
Found: \bin\ld.exe
Found: C:\bin\ls.exe
Found: \bin\ls.exe
Found: C:\bin\make.exe
Found: \bin\make.exe
Found: C:\bin\sh.exe
Found: \bin\sh.exe

   18k 2000/10/23 C:\bin\cyggdbm.dll
   83k 2000/06/11 C:\bin\cygitcl30.dll
   35k 2000/06/11 C:\bin\cygitk30.dll
   45k 2000/10/22 C:\bin\cygjbig1.dll
  119k 2000/10/23 C:\bin\cygjpeg6b.dll
  162k 2000/10/23 C:\bin\cygpng2.dll
  402k 2000/06/11 C:\bin\cygtcl80.dll
    5k 2000/06/11 C:\bin\cygtclpip80.dll
   10k 2000/06/11 C:\bin\cygtclreg80.dll
  243k 2000/10/23 C:\bin\cygtiff3.dll
  639k 2000/06/11 C:\bin\cygtk80.dll
   49k 2000/10/23 C:\bin\cygz.dll
  609k 2000/11/11 C:\bin\cygwin1.dll
    Cygwin DLL version info:
        dll major: 1001
        dll minor: 5
        dll epoch: 19
        dll bad signal mask: 19005
        dll old termios: 5
        dll malloc env: 28
        api major: 0
        api minor: 30
        shared data: 3
        dll identifier: cygwin1
        mount registry: 2
        cygnus registry name: Cygnus Solutions
        cygwin registry name: Cygwin
        program options name: Program Options
        cygwin mount registry name: mounts v2
        cygdrive flags: cygdrive flags
        cygdrive prefix: cygdrive prefix
        cygdrive default prefix: 
        build date: Sat Nov 11 01:49:33 EST 2000
        shared id: cygwin1S3

   18k 2000/10/23 \bin\cyggdbm.dll
   83k 2000/06/11 \bin\cygitcl30.dll
   35k 2000/06/11 \bin\cygitk30.dll
   45k 2000/10/22 \bin\cygjbig1.dll
  119k 2000/10/23 \bin\cygjpeg6b.dll
  162k 2000/10/23 \bin\cygpng2.dll
  402k 2000/06/11 \bin\cygtcl80.dll
    5k 2000/06/11 \bin\cygtclpip80.dll
   10k 2000/06/11 \bin\cygtclreg80.dll
  243k 2000/10/23 \bin\cygtiff3.dll
  639k 2000/06/11 \bin\cygtk80.dll
   49k 2000/10/23 \bin\cygz.dll
  609k 2000/11/11 \bin\cygwin1.dll
    Cygwin DLL version info:
        dll major: 1001
        dll minor: 5
        dll epoch: 19
        dll bad signal mask: 19005
        dll old termios: 5
        dll malloc env: 28
        api major: 0
        api minor: 30
        shared data: 3
        dll identifier: cygwin1
        mount registry: 2
        cygnus registry name: Cygnus Solutions
        cygwin registry name: Cygwin
        program options name: Program Options
        cygwin mount registry name: mounts v2
        cygdrive flags: cygdrive flags
        cygdrive prefix: cygdrive prefix
        cygdrive default prefix: 
        build date: Sat Nov 11 01:49:33 EST 2000
        shared id: cygwin1S3


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

linking problem

[Frankie Ramos]

Hi.  I'm a newbie to Cygwin32.  Have the stuff running ok and decided to compile the MAPMAKER/HOMOZ package for gene mapping for a friend.  Most of the source compiles ok, but when the final linking starts I get the following error code:

gcc -ansi -g ./src/hommain.o ./src/fileio.o ./src/pslib.o ./src/generate.o ./src
/compute.o ./src/cmds.o ./src/pedprep.o  lib.o -lm -o homoz
/d/Cygnus/b19/H-i386-cygwin32/i386-cygwin32/bin/ld.exe: lib.o: bad reloc address
 0x94 in section `.text'

If anyone has any hints as to what this means, how  I could fixit or where to go read stuff that will help me with the problem I would be more than interested in knowing.  

I did a search in the mailing list but couldn't find anything that might help.

Thanks in advance.

-----
Free e-mail group hosting at http://www.eGroups.com/
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".