Palagpat Coding

Fun with JavaScript, game theory, and the occasional outbreak of seriousness

Saturday, May 22, 2010

Solved: Cannot find -lgcc_s on Cygwin 4.3.4

For the past week or so, I've been trying to build the Giza++ language modeling tools on my Windows machines, and have been having quite a bit of trouble. Permissions errors on Windows 7, weird "missing separator" error messages that were completely unhelpful (it means your text editor has replaced all tabs with spaces), and so on. Compile and build errors that have kept me up late into the night on several occasions lately, but which I was ultimately able to untangle with a little applied Google-Fu.

Despite my best efforts, though, I was stymied by this error:

g++  -Wall -W -Wno-deprecated -O3 -DNDEBUG -DWORDINDEX_WITH_4_BYTE -DBINARY_SEARCH_FOR_TTABLE optimized/Parameter.o optimized/myassert.o optimized/Perplexity.o optimized/model1.o optimized/model2.o optimized/model3.o optimized/getSentence.o optimized/TTables.o optimized/ATables.o optimized/AlignTables.o optimized/main.o optimized/NTables.o optimized/model2to3.o optimized/collCounts.o optimized/alignment.o optimized/vocab.o optimized/MoveSwapMatrix.o optimized/transpair_model3.o optimized/transpair_model5.o optimized/transpair_model4.o optimized/utility.o optimized/parse.o optimized/reports.o optimized/model3_viterbi.o optimized/model3_viterbi_with_tricks.o optimized/Dictionary.o optimized/model345-peg.o optimized/hmm.o optimized/HMMTables.o optimized/ForwardBackward.o -static -o GIZA++

/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lgcc_s
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status
make: *** [GIZA++] Error 1

My initial web searches didn't illuminate much: the "-lgcc_s" bit in the error report pointed to a problem with Libgcc, but that library is part of GCC, and Cygwin installs it just fine when you tell it to — I should know, I've (re)installed Cygwin on two different machines 3 times in the past few days! So, what could the problem possibly be...? Tonight, I finally found the answer, with a nudge in the right direction from this blog:

'-static' option makes gcc to avoid the use of shared libraries. '-static' is supposed to make gcc use -lgcc_s and '-dynamic' to make gcc use -lgcc. Actually, Cygwin and gcc 4.3.4 are not coming with 'libgcc_s.a'. Something's wrong, but I'm not sure here. Anyway, in order to compile, it is necessary to change '-static' to something. For instance, if '-static' was removed, it would be okay!

This reminded me of something I read in the "Getting Started" guide to Moses, the statistical machine translation system I'm trying to use as part of my Computational Linguistics MA thesis:

OS X doesn't support static linking (here's more info), so we need to tweak two Makefiles. GIZA++-v2/Makefile:

15c15
< LDFLAGS = -static
---
> LDFLAGS = 

mkcls-v2/Makefile is OK

Aside from the questionable logic here ("we need to tweak two Makefiles", but then the second one "is OK"? Hmm, if you say so...), this clicked into place alongside what the first blog said. If OS X doesn't support static linking, I'm willing to bet that Cygwin on Windows doesn't either. I edited the Makefile — taking care to preserve the tabs on save this time — and made the suggested change to the LDFLAGS assignment line. This time, when I ran make, it worked! Problem solved, finally.

Now, I can go to bed. :)

Labels: , ,

8 Comments:

  • At 11:20 AM , Blogger Elijah Betancourt said...

    /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libcygwin.a(libcmain.o):

    had a similar issue and found that associating the main to the file linked them correctly...

    gcj --main=HelloWorldApp HelloWorldApp.java

    this worked!

     
  • At 1:25 PM , Blogger Buyog said...

    @Elijah: Good to know, thanks for the tip.

     
  • At 7:59 AM , Blogger Umit Karabiyik said...

    Thanks Buyog.
    Worked perfectly!!!

     
  • At 3:20 PM , Blogger Buyog (Ryan) said...

    Glad I could help, Umit.

     
  • At 11:12 PM , Blogger Sham said...

    Thanks for the tip, but after editing the makefile, when i re-run the script, it downloads the giza-pp package again and rewrites the one present on the pc thereby deleting the edited makefile. How may i go about preventing this?

     
  • At 6:17 AM , Blogger Buyog (Ryan) said...

    @Sham: I seem to remember having that problem, too. I don't have the code to reference at the moment, but I presume you'd need to look at the script and make sure it is properly detecting the presence of the package, so it doesn't invoke the (re)download. Guessing off the top of my head, maybe it's an issue with the script not having permission to read the install path you're using?

     
  • At 11:58 AM , Blogger Arjun Jain said...

    Thanks man, helps a lot.

     
  • At 2:54 PM , Blogger Buyog (Ryan) said...

    Glad to hear it.

     

Post a Comment

Subscribe to Post Comments [Atom]

<< Home