Re: Unable to link

2009-08-13 Thread Javier Sedano
Hi, cygwiners,

2009/8/12 Dave Korn dave.korn.cyg...@googlemail.com:
 Javier Sedano wrote:

 /home/jsedano/prj/uc3m/ao/Labs_J/LibAO/testBypass.c:26: undefined
 reference to `_testBP_1'
 /home/jsedano/prj/uc3m/ao/Labs_J/LibAO/testBypass.c:26: undefined
 reference to `___aoAsBypassCall'

 jsed...@ender:~/prj/uc3m/ao/Labs_J/LibAO nm libao-g.a | grep _testBP_1
 jsed...@ender:~/prj/uc3m/ao/Labs_J/LibAO nm libao-g.a | grep testBP_1
 0166 T testBP_1

  You're trying to use a library binary that was originally compiled on Linux,
 aren't you?  That can't work, sorry; you need to recompile the library from
 source on Cygwin.


  On a first though I was about to say no... but on second though...
not sure. I've got several .s files (assembly code) that seems to be
hand-written (they have lots of the kind of comments that humans use
to do, so does not seem to be compiled). See trace below.

  So let's see if I understand the problem: when I define (and
implement) a function f1(), gcc on Linux will use the name f1 for the
function, but gcc on cygwin will use _f1. So if my .s has been created
with Linux on mind, the developer used f1, and cygwin can not find it.
Right so far?

  So any other idea? Any modifier to gcc not to use the leading _?



jsed...@ender:~/prj/uc3m/ao/Labs_J/LibAO grep -r testBP_1 .
./bypassCall.s: .global testBP_1, testBP_2, testBP_3, testBP_4,
testBP_5, testBP_6
./bypassCall.s:testBP_1:
./testBypass.c:void testBP_1();
./testBypass.c:returned = __aoAsBypassCall(testBP_1, // Function to call
jsed...@ender:~/prj/uc3m/ao/Labs_J/LibAO grep -B5 -A5 testBP_1 bypassCall.s
toTransfer:
.int 0

.text
.globl __aoAsBypassDiagnostics, __aoAsBypassCall
.global testBP_1, testBP_2, testBP_3, testBP_4, testBP_5, testBP_6

# Function to catch the invocation of certain function and
# perform some checks in the way parameters and result is
# manipulated. Also this method allows to transfer the result
# from an arbitrary register in to %eax to facilitate the
--


# --
# Does nothing
# --
testBP_1:
ret

# --
# Returns 31 in ebx
# --
jsed...@ender:~/prj/uc3m/ao/Labs_J/LibAO



-- 
--
Javier Sedano
javier.sed...@gmail.com

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



Re: Unable to link

2009-08-13 Thread Dave Korn
Javier Sedano wrote:

   On a first though I was about to say no... but on second though...
 not sure. I've got several .s files (assembly code) that seems to be
 hand-written (they have lots of the kind of comments that humans use
 to do, so does not seem to be compiled). See trace below.

  There ya go.  They're hand-written according to Linux conventions.

   So let's see if I understand the problem: when I define (and
 implement) a function f1(), gcc on Linux will use the name f1 for the
 function, but gcc on cygwin will use _f1. So if my .s has been created
 with Linux on mind, the developer used f1, and cygwin can not find it.
 Right so far?

  Yep, spot on.

   So any other idea? Any modifier to gcc not to use the leading _?

  Well.  You could hack your .S file and add leading underscores.  Or you
could write a .h header file that declares prototypes of all the functions,
and uses GCC's 'asm (name)' extension to specify the assembler names as the
non-underscored versions.

  Or, you could try the -fno-leading-underscore switch, but then that would
break your code in a whole world of other ways because it wouldn't be able to
link against any of the standard cygwin functions!

  However, you have larger problems than that.  This assembly code is
hand-written for linux.  Now, ...

 # --
 # Does nothing
 # --
 testBP_1:
 ret

... something as simple as that will assemble and work just fine on Cygwin.
But anything much more complex is liable to run into problems.  For example,
on Linux you use the int 80 instruction to perform a syscall; on Cygwin, you
just call a subroutine like any other.  The compatibility between Cygwin and
Linux exists at the C source-code level (and above), but under the hood, in
assembly world, it's very different.  That's why you need to recompile stuff
on Cygwin; the actual machine code that's generated is very different.

  You will almost certainly need to write a windows-specific version of the .S
files to make this work.  How complex or tricky that is I can't guess as it
depends entirely on the complexity of the .S files you need to translate.
Sorry not to have better news for you.

cheers,
  DaveK



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



Re: Unable to link

2009-08-13 Thread Javier Sedano

Hi,

Dave Korn escribió:


... something as simple as that will assemble and work just fine on Cygwin.
But anything much more complex is liable to run into problems.  For example,
on Linux you use the int 80 instruction to perform a syscall; on Cygwin, you
just call a subroutine like any other.  The compatibility between Cygwin and
Linux exists at the C source-code level (and above), but under the hood, in
assembly world, it's very different.  That's why you need to recompile stuff
on Cygwin; the actual machine code that's generated is very different.



:-(
I suspected that once I read your first email and found the .s files.
	I do not know in detail what it does, but the whole lib deals with 
memory allocation, processes,... so I bet it is not just a matter of 
changing the name.



  You will almost certainly need to write a windows-specific version of the .S
files to make this work.  How complex or tricky that is I can't guess as it
depends entirely on the complexity of the .S files you need to translate.
Sorry not to have better news for you.



	No problem. It is part of an exercice for grade students (are they 
reading this ML? Hello!), whose reference environment is Linux, so I 
need Linux anyway (since it is where they will be evaluated). So it is 
not worth the value to spend more time porting it. This code is a kind 
of support library, so I was trying to compile it under cygwin and was 
curious about why it did not compile, but we will not waste more time 
(your time, in particular) on it.

Thank you very much for the kindly help.

Regards,

--
--
Javier Sedano
javier.sed...@gmail.com

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



Re: Unable to link

2009-08-12 Thread Dave Korn
Javier Sedano wrote:

 /home/jsedano/prj/uc3m/ao/Labs_J/LibAO/testBypass.c:26: undefined
 reference to `_testBP_1'
 /home/jsedano/prj/uc3m/ao/Labs_J/LibAO/testBypass.c:26: undefined
 reference to `___aoAsBypassCall'

 jsed...@ender:~/prj/uc3m/ao/Labs_J/LibAO nm libao-g.a | grep _testBP_1
 jsed...@ender:~/prj/uc3m/ao/Labs_J/LibAO nm libao-g.a | grep testBP_1
 0166 T testBP_1

  You're trying to use a library binary that was originally compiled on Linux,
aren't you?  That can't work, sorry; you need to recompile the library from
source on Cygwin.

cheers,
  DaveK

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



Re: Unable to link with libgd

2008-05-28 Thread Christopher Faylor
On Wed, May 28, 2008 at 06:33:02PM -0700, Mark Smith wrote:
I am trying to use libgd, but the linking step fails.
Can anyone help with this? I installed the libgd
development package using the cygwin installer.

Here is where I try to build the circletexttest that
comes with the libgd source (beware of wrapped lines).


gcc -g -O2 -I/usr/include/freetype2
-I/usr/X11R6/include -L/usr/lib
-L/usr/X11R6/lib -lgd circletexttest.c -o
circletexttest

Put the -lgd after the circletexttest.c.

cgf

--
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/