This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Building the GNU cgicc library...

It is a common courtesy to keep public discussions on the list, that way if someone else encounters this same problem, they might know what to do.

Bakken, Luke wrote:
This may (or may not) be your problem, but your library is being built as a static archive eventhough you requested a shared library.

I'm just curious how you noticed that in the output - is it the that you noticed?

Please see my message again, I put ^^^^^^^^ underneath the output message which tipped me off.

Edit the makefile in that library's source directory and look for the line which contains the "-version-info 5:0:0" string. Append "-no-undefined" after that string to get something like "-version-info 5:0:0 -no-undefined". Then make clean and rebuild.

Yeah, I tried this (read it in a mail list archive somewhere) by doing:

$ CXXFLAGS='-Wl,--no-undefined' ./configure

The ld --help command specifies '--no-undefined'.

Well, you see it is more complex than just passing a linker flag. -no-undefined is a libtool flag and it should only be passed at linktime. So try LDFLAGS="-no-undefined" and see what happens, but why didn't you try exactly what I told you in the first place?

/bin/bash ../libtool --mode=link g++ -Wall -W -pedantic
-Wl,--no-undefined -o -rpath /usr/lib -version-info 5:0:0
CgiEnvironment.lo Cgi
Input.lo CgiUtils.lo Cgicc.lo FormEntry.lo FormFile.lo HTMLAttribute.lo
HTMLAttributeList.lo HTMLDoctype.lo HTMLElement.lo HTMLElementList.lo
entHeader.lo HTTPCookie.lo HTTPHTMLHeader.lo HTTPHeader.lo
HTTPPlainHeader.lo HTTPRedirectHeader.lo HTTPResponseHeader.lo
HTTPStatusHeader.lo MStreama
libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin
shared libraries
ar cru .libs/libcgicc.a CgiEnvironment.o CgiInput.o CgiUtils.o Cgicc.o
FormEntry.o FormFile.o HTMLAttribute.o HTMLAttributeList.o HTMLDoctype.o
lement.o HTMLElementList.o HTTPContentHeader.o HTTPCookie.o
HTTPHTMLHeader.o HTTPHeader.o HTTPPlainHeader.o HTTPRedirectHeader.o
HTTPStatusHeader.o MStreamable.o
ranlib .libs/libcgicc.a
(cd .libs && rm -f && ln -s ../
make[2]: Leaving directory `/home/lukeb/cgicc-3.2.2/cgicc'
make[1]: Leaving directory `/home/lukeb/cgicc-3.2.2/cgicc'
Making all in doc
make[1]: Entering directory `/home/lukeb/cgicc-3.2.2/doc'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/lukeb/cgicc-3.2.2/doc'
Making all in support
make[1]: Entering directory `/home/lukeb/cgicc-3.2.2/support'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/lukeb/cgicc-3.2.2/support'
Making all in demo
make[1]: Entering directory `/home/lukeb/cgicc-3.2.2/demo'
if g++ -DHAVE_CONFIG_H -I. -I. -I../cgicc -I.. -I.. -Wall -W
-pedantic -Wl,--no-undefined -MT test.o -MD -MP -MF ".deps/test.Tpo" \
-c -o test.o `test -f 'test.cpp' || echo './'`test.cpp; \
then mv -f ".deps/test.Tpo" ".deps/test.Po"; \
else rm -f ".deps/test.Tpo"; exit 1; \
g++: --no-undefined: linker input file unused because linking not done
/bin/bash ../libtool --mode=link g++ -Wall -W -pedantic
-Wl,--no-undefined -o test.cgi.exe test.o ../cgicc/
mkdir .libs
g++ -Wall -W -pedantic -Wl,--no-undefined -o test.cgi.exe test.o
test.o(.ctors+0x0):test.cpp: undefined reference to `__GLOBAL__I_main'
test.o(.dtors+0x0):test.cpp: undefined reference to `__GLOBAL__D_main'
undefined reference to `__GLOBAL__I__ZN5cgicc11HTMLElementC2ERKS0_'
undefined reference to `__GLOBAL__D__ZN5cgicc11HTMLElementC2ERKS0_'
pp: undefined reference to `__GLOBAL__I__ZN5cgicc14HTTPHTMLHeaderC2Ev'
pp: undefined reference to `__GLOBAL__D__ZN5cgicc14HTTPHTMLHeaderC2Ev'
ader.cpp: undefined reference to
ader.cpp: undefined reference to
collect2: ld returned 1 exit status
make[1]: *** [test.cgi.exe] Error 1
make[1]: Leaving directory `/home/lukeb/cgicc-3.2.2/demo'
make: *** [all-recursive] Error 1

If it still complains about undefined symbols, you will need to figure out what external libraries it is trying to use and add them to the following line:

I grepped the source files for the text matching the
functions/methods/etc that were in the ld error messages, and they are
all within this library. I don't think it's trying to reference anything

Well you need to try the approach I first mentioned. This is not relevant if you haven't passed the correct linker flags to libtool. Please reread my previous message and try that apprach.

Thanks for the informative email! I just might look into your libtool suggestion, even though the one shipped with the source is the latest stable version.

That isn't really saying much, because most people still think 1.4.3 is the most current, when in fact 1.5.0 is the latest "stable" release. Do not be deceived by the labeling in the cygwin package, the truth of the matter is that 1.4.x is no longer being maintained.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]