Libtool HEAD testsuite
Hi! I'm currently working on porting my wgcc patches from 1.5.22 to HEAD (*pfff*). Now recently i changed the default output of wgcc to a.exe, so i have an extension for my exe's, since otherwise they don't really work that good in some cases ;o) However, no i realized, that the whole libtool testsuite does *not* think about any possible extension, but simply calls the executable with the basename only. In order to port my patches i need the testsuite to recognize exe's... What should i do? Cheers, Markus ___ http://lists.gnu.org/mailman/listinfo/libtool
build program before library
Hi, How do I build a program before a library with automake and libtool? By default, the library is being built first and that is not what I want. Thanks, Bob Rossi ___ http://lists.gnu.org/mailman/listinfo/libtool
RE: Libtool HEAD testsuite
Hi again! Sorry, i must correct myself. $EXEEXT *is* used *sometimes* and as far as my situation is concerned, completely in the wrong places... I made the func_exec type of functions intelligent enough to recognize an exe with or without extension... For example tagdemo does this: func_require "tagdemo-make" "tests/tagdemo/tagdemo$EXEEXT" Which fails (of course) because the tests/tagdemo/tagdemo (without extension) is the wrapper around tests/tagdemo/.libs/tagdemo.exe I don't claim to have found a solution for this, but at least for now, and for me i got a workaround I think there is some work to be done here ;o) Cheers, Markus Duft Markus <> wrote: > Hi! > > I'm currently working on porting my wgcc patches from 1.5.22 to HEAD > (*pfff*). Now recently i changed the default output of wgcc to a.exe, > so i have an extension for my exe's, since otherwise they don't > really work that good in some cases ;o) > > However, no i realized, that the whole libtool testsuite does *not* > think about any possible extension, but simply calls the executable > with the basename only. > > In order to port my patches i need the testsuite to recognize exe's... > What should i do? > > Cheers, Markus > > > ___ > http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
Getting foo-config to go into installed bin directory
Hi, I'm writing a Makefile.am file for a library. When I do make, the foo-config is in the build directory. However, when I do 'make install' it doesn't go into the bin directory. Any idea how to force it to? Reading the documentation for libtool and automake didn't seem to help. Thanks, Bob Rossi ___ http://lists.gnu.org/mailman/listinfo/libtool
windows static archive, missing symbols
Hi,
I've got a quick question hopefully. I'm building pcre on windows. I've
been able to build it into a dll and link against it with a small
program. However, when I build a static library, and link it with a
small program, I get the missing symbols error.
I know the symbols are in the library because nm tells me so,
$ nm -g /home/bobbybrasko/download/pcre/pcre/install/lib/libpcre.a|grep
compile
libpcre_la-pcre_compile.o:
5550 T _pcre_compile
Here is the link line of the small program,
$ gcc-4.1 -g -Wall -o test test.c
-L/home/bobbybrasko/download/pcre/pcre/install/lib \
-lpcreposix -lpcre
-I/home/bobbybrasko/download/pcre/pcre/install/include
C:/WINDOWS/TEMP/ccgGAsIC.o(.text+0x2e): In function `main':
C:/msys/1.0/home/bobbybrasko/download/pcre/pcre/build/tmp/test.c:13:
undefined reference to `_imp__pcre_compile'
collect2: ld
returned 1 exit status
[EMAIL PROTECTED] ~/download/pcre/pcre/build/tmp
Here is the test program,
$ cat test.c
#include
#include
#include
pcre *re;
char *pattern;
const char *error;
int erroffset;
int
main (void)
{
re = pcre_compile(
pattern, /* the pattern */
0,/* default options */
&error, /* for error message */
&erroffset, /* for error offset */
NULL);
return 0;
}
Here is the link line of the library pcre,
/bin/sh ./libtool --mode=link gcc -g -O2 -o libpcre.la -rpath
/home/bobbybrasko/download/pcre/pcre/static/../install/lib
libpcre_la-pcre_chartables.lo libpcre_la-pcre_compile.lo
libpcre_la-pcre_config.lo libpcre_la-pcre_dfa_exec.lo libpcre_la-pcre_exec.lo
libpcre_la-pcre_fullinfo.lo libpcre_la-pcre_get.lo libpcre_la-pcre_globals.lo
libpcre_la-pcre_info.lo libpcre_la-pcre_maketables.lo
libpcre_la-pcre_newline.lo libpcre_la-pcre_ord2utf8.lo
libpcre_la-pcre_refcount.lo libpcre_la-pcre_study.lo libpcre_la-pcre_tables.lo
libpcre_la-pcre_try_flipped.lo libpcre_la-pcre_ucp_searchfuncs.lo
libpcre_la-pcre_valid_utf8.lo libpcre_la-pcre_version.lo
libpcre_la-pcre_xclass.lo
libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared
libraries
rm -fr .libs/libpcre.a .libs/libpcre.la .libs/libpcre.lai
ar cru .libs/libpcre.a libpcre_la-pcre_chartables.o libpcre_la-pcre_compile.o
libpcre_la-pcre_config.o libpcre_la-pcre_dfa_exec.o libpcre_la-pcre_exec.o
libpcre_la-pcre_fullinfo.o libpcre_la-pcre_get.o libpcre_la-pcre_globals.o
libpcre_la-pcre_info.o libpcre_la-pcre_maketables.o libpcre_la-pcre_newline.o
libpcre_la-pcre_ord2utf8.o libpcre_la-pcre_refcount.o libpcre_la-pcre_study.o
libpcre_la-pcre_tables.o libpcre_la-pcre_try_flipped
Re: windows static archive, missing symbols
Bob Rossi wrote: Hi, I've got a quick question hopefully. I'm building pcre on windows. I've been able to build it into a dll and link against it with a small program. However, when I build a static library, and link it with a small program, I get the missing symbols error. I know the symbols are in the library because nm tells me so, $ nm -g /home/bobbybrasko/download/pcre/pcre/install/lib/libpcre.a|grep compile libpcre_la-pcre_compile.o: 5550 T _pcre_compile Here is the link line of the small program, $ gcc-4.1 -g -Wall -o test test.c -L/home/bobbybrasko/download/pcre/pcre/install/lib \ -lpcreposix -lpcre -I/home/bobbybrasko/download/pcre/pcre/install/include C:/WINDOWS/TEMP/ccgGAsIC.o(.text+0x2e): In function `main': C:/msys/1.0/home/bobbybrasko/download/pcre/pcre/build/tmp/test.c:13: undefined reference to `_imp__pcre_compile'collect2: ld returned 1 exit status Does anyone understand why I'd be getting these errors? Are .def files important for static windows libraries or only for dll's? Any advice? First of all, obviously "_imp__pcre_compile" is not the same as "_pcre_compile" so the error message is legitimate - the symbol that it's actually looking for is not there. The next question is, why is it looking for an import symbol instead of using the real symbol. The answer to that must lie in your header files; they probably declare the function to be a DLL export, which causes the compiler to generate references to an import symbol. Have a look at your header files. Remove any DLL declspec's on any function declarations you find there; modern linkers don't need them. I.e., the GNU linker is smart enough to use an import symbol in place of a reference to a real symbol. Apparently it won't do the opposite. Unfortunately if a library exports variables as well, you need to preserve the export declspecs there. This means for any Windows library that you use, you have to know whether you will be using a static or a dynamic version, whenever compiling an app that uses the library. Very braindead, and there's no solution to that problem. The workaround is to never export variables from your libraries, only functions/accessor methods. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: windows static archive, missing symbols
Bob Rossi wrote: > I know the symbols are in the library because nm tells me so, > $ nm -g /home/bobbybrasko/download/pcre/pcre/install/lib/libpcre.a|grep > compile > libpcre_la-pcre_compile.o: > 5550 T _pcre_compile Note here that this is just a regular symbol, as you would expect with a non-shared library. > -I/home/bobbybrasko/download/pcre/pcre/install/include > C:/WINDOWS/TEMP/ccgGAsIC.o(.text+0x2e): In function `main': > C:/msys/1.0/home/bobbybrasko/download/pcre/pcre/build/tmp/test.c:13: > undefined reference to `_imp__pcre_compile' > But here you're trying to dllimport the symbol. But you don't want to do that in the case of static linking. You'll have to look at the header and see how the dllimport/dllexport is #defined, usually it means you have to add some extra -DSTATIC or similar when you are using the static archive so that the prototypes are not defined dllimport. If libpcre is a libtoolized library and you used libtool to compile instead of invoking gcc yourself it should take care of this for you, though. That's kind of the whole point of libtool, to abstract this away. > Does anyone understand why I'd be getting these errors? Are .def files > important for static windows libraries or only for dll's? Any advice? AFAIK .def files have absolutely nothing to do with static libraries, which are just collections of .o files really. A .def file is used to express what symbols a given .dll exports and imports, but these concepts don't even exist in the case of a static library. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: windows static archive, missing symbols
On Fri, Jan 19, 2007 at 06:30:19PM -0800, Howard Chu wrote: > The next question is, why is it looking for an import symbol instead of > using the real symbol. The answer to that must lie in your header files; > they probably declare the function to be a DLL export, which causes the > compiler to generate references to an import symbol. Have a look at your > header files. Remove any DLL declspec's on any function declarations you > find there; modern linkers don't need them. I.e., the GNU linker is > smart enough to use an import symbol in place of a reference to a real > symbol. Apparently it won't do the opposite. Yes, there was this code in the header, #ifndef PCRE_STATIC # define PCRE_DATA_SCOPE extern __declspec(dllimport) #endif so, I #defined PCRE_STATIC before including pcre.h. This allowed the link to work. So, the correct way is to tell the author to remove the declspec's alltogether from the header file? That will work for both dynamic and static setup? Thanks, Bob Rossi ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: windows static archive, missing symbols
On Sat, Jan 20, 2007 at 12:42:36AM -0500, Bob Rossi wrote: > On Fri, Jan 19, 2007 at 06:30:19PM -0800, Howard Chu wrote: > > The next question is, why is it looking for an import symbol instead of > > using the real symbol. The answer to that must lie in your header files; > > they probably declare the function to be a DLL export, which causes the > > compiler to generate references to an import symbol. Have a look at your > > header files. Remove any DLL declspec's on any function declarations you > > find there; modern linkers don't need them. I.e., the GNU linker is > > smart enough to use an import symbol in place of a reference to a real > > symbol. Apparently it won't do the opposite. > > Yes, there was this code in the header, > #ifndef PCRE_STATIC > # define PCRE_DATA_SCOPE extern __declspec(dllimport) > #endif > > so, I #defined PCRE_STATIC before including pcre.h. This allowed the > link to work. > > So, the correct way is to tell the author to remove the declspec's > alltogether from the header file? That will work for both dynamic and > static setup? Sorry, it's late for me. I meant to say "static or shared (dll)". Thanks, Bob Rossi ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: windows static archive, missing symbols
Bob Rossi wrote: On Fri, Jan 19, 2007 at 06:30:19PM -0800, Howard Chu wrote: The next question is, why is it looking for an import symbol instead of using the real symbol. The answer to that must lie in your header files; they probably declare the function to be a DLL export, which causes the compiler to generate references to an import symbol. Have a look at your header files. Remove any DLL declspec's on any function declarations you find there; modern linkers don't need them. I.e., the GNU linker is smart enough to use an import symbol in place of a reference to a real symbol. Apparently it won't do the opposite. Yes, there was this code in the header, #ifndef PCRE_STATIC # define PCRE_DATA_SCOPE extern __declspec(dllimport) #endif so, I #defined PCRE_STATIC before including pcre.h. This allowed the link to work. So, the correct way is to tell the author to remove the declspec's alltogether from the header file? That will work for both dynamic and static setup? Judging from the name of that macro, it may be affecting data declarations. As I said in my previous email, data declarations still need the declspec; you can only omit them for function declarations. If you're sure that the macro is only being used for function declarations then yes, it's safe to remove it. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: windows static archive, missing symbols
Bob Rossi wrote: > So, the correct way is to tell the author to remove the declspec's > alltogether from the header file? That will work for both dynamic and > static setup? No, it's not the right way. The right way is to add -DPCRE_STATIC to the CPPFLAGS. When linking against a DLL without __declspec(dllimport), it will still work but it's suboptimal as there will be an extra jump instruction through the function stub (and possibly an extra relocation to resolve, I don't remember.) This means the binary is larger and slower. Although the extent of this is debatable, you don't want to do that if you can avoid it, which you can by just using -DPCRE_STATIC, which is how it was designed to work. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: windows static archive, missing symbols
Brian Dessent wrote: Bob Rossi wrote: So, the correct way is to tell the author to remove the declspec's alltogether from the header file? That will work for both dynamic and static setup? No, it's not the right way. The right way is to add -DPCRE_STATIC to the CPPFLAGS. When linking against a DLL without __declspec(dllimport), it will still work but it's suboptimal as there will be an extra jump instruction through the function stub (and possibly an extra relocation to resolve, I don't remember.) This means the binary is larger and slower. Although the extent of this is debatable, you don't want to do that if you can avoid it, which you can by just using -DPCRE_STATIC, which is how it was designed to work. That's false. It's just an address relocation, performed by the runtime linker. Writing code that requires XXX_STATIC macros is nothing but ignorant, and hasn't been necessary for at least 5 years. http://www.cygwin.com/ml/cygwin/2002-01/msg00236.html -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/ ___ http://lists.gnu.org/mailman/listinfo/libtool
