autobook hello.exe fails to link w/dll on cygwin - undefined 'greet'

l, /usr/local/lib main.o: In function `main': /home/dcarter/cygwin-1.0/main.c:12: undefined reference to `greet' collect2: ld returned 1 exit status make: *** [hello.exe] Error 1 Any suggestions? Thanks, David Carter [EMAIL PROTECTED] _

to libtool or not: Windows & Unix NSAPI program

ce a Windows dll that needs to be linked against other windows dlls (ns-httpd40.dll, cygwin, etc.) Libtool doesn't seem to like windows file extensions -- dll, lib, etc. If I don't use libtool, how can I do this with automake? Thanks

libwww make fails: libtool: ltconfig version `' does not match ltmain.sh version `1.3.4'

ome/dcarter/libwww' make: *** [all-recursive-am] Error 2 Am I overlooking something obvious here? Thanks for any clues! -- David Carter [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Link Time Optimization

I've been searching mailing list for supporting -flto in libtool, and seen several (commited?) patches. The problem is that I've tried git version of libtool (trunk) and still it is not supported since any program will compile with -flto (for example, mysql-5.1.50). Then, I have several questi

Re: Link Time Optimization

I feel like lto is something that is sufficient important to be tested as soon as possible, and, imho, gives as a new interesting level of optimization. Personally, I use gentoo and try to optimize as much as I can.. Anyway, thanks for looking at th

Re: Avoid exporting of internal symbols

I cant remember now the syntax, but maybe the gcc hidden visibility attribute is what you are looking for. El 04/03/2013 08:06, "Satz Klauer" escribió: > I'm creating a shared library using libtool: > > libtool --mode=compile g++ -Wall -fPIC -shared -Wno-unused > -Wno-unused-result $(CFLAGS) $(LF

Re: Running an uninstalled executable

El Tue, 12 May 2015 11:38:42 +0200 Alberto Luaces escribió: > Hello, > > in an autoconf+automake+libtool C++ project containing only one > program, I want to run the executable before installing it. > > Reading the manual I thought that it could be done with > > libtool --mode=execute program_b

Re: [Fink-devel] Re: libtool "module" behavior and darwin

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 >Feel free to take the patches from NetBSD pkgsrc and makes noises with the KDE people. http://www.netbsd.org/Documentation/software/packages.html No need to make noise with the KDE people, I am reading this list *grins* If you have a patch a

First Annual Linux User's Training Conference and Awards Presentation

Title:   To:      [EMAIL PROTECTED]   First Annual Linux Users' Training Conference And Awards Presentation “New Enterprise Solutions Through Linux” October 30, 2000 Ronald Reagan Building and International Trade

More info

t in touch? We wouldn't want to duplicate effort would we? david ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Undefined symbols

where that says that static libraries can be made from files built with PIC? This is OK on BeOS so if there is a way of using it we may as well... Thanks. david ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

.lo files are being passed to directly to linker on solaris

Hello, I'm having a problem i am having trouble diagnosing under Solaris with a libtoolized library i am developing, gsk. under a subdirectory that is supposed to produce libgsk-protocol.la % make /bin/sh ../../libtool --mode=link gcc -g -O2 -o libgsk-protocol.la -rpath /usr/local/lib gskba

OS-sympathetic installation (fwd)

o get a toehold to see whether such a thing is possible or feasible. -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham :

Re: OS-sympathetic installation (fwd)

On 14 Feb 2001, Tom Tromey wrote: > >>>>> "David" == David Lee <[EMAIL PROTECTED]> writes: > > David> But any such project would, I think, have a "libtool" > David> interaction, and I know almost nothing about the insides of > D

Re: OS-sympathetic installation (fwd)

On Wed, 14 Feb 2001, Olly Betts wrote: > In message <[EMAIL PROTECTED]>, > David Lee writes: > >But the "big picture" is to be able to produce something along the lines of: > > > > # Directories... > > $prefix=/usr > >[...] > > &g

building shared objects...

what commands should be required to be passed in to a build to make a shared object? Sorry if this is a bit 101, bit I want to verify that a project is passing in the correct command line before I go into too much more effort on it. Thanks. david

Path to library?

ugh I'm on Solaris, it is important that the solution be capable of being used portably across a range of systems, insofar as those systems allow it.) Feel free to refer me to page numbers in GNU Libtool (and autoconf and automake) documents and to page numbers in the "Goat" book "

Help needed to build shared library with libtool

btool created a command that started with: g++ -shared -o /libGUI.so whereas the failing command (above) starts with: libtool: link: g++ -o libGUI.so I realise that the absence of '-shared' in the latter is probably causing my problem. Why is it not present ple

Help needed to build shared library with libtool

btool created a command that started with: g++ -shared -o /libGUI.so whereas the failing command (above) starts with: libtool: link: g++ -o libGUI.so I realise that the absence of '-shared' in the latter is probably causing my problem.  Why is it not present ple

Help needed to build shared library with libtool

btool created a command that started with: g++ -shared -o /libGUI.so whereas the failing command (above) starts with: libtool: link: g++ -o libGUI.so I realise that the absence of '-shared' in the latter is probably causing my problem.  Why is it not present ple

RE: Help needed to build shared library with libtool

r/lib/gcc/x86_64-redhat-linux/4.4.4/crtendS.o /usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../lib64/crtn.o -pthread -pthread -Wl,-soname -Wl,libGUI.so.0 -o libGUI.so.0.0.0 libtool: link: (cd ) ln: creating symbolic link `libGUI.so.0': Operation not suppor

RE: Help needed to build shared library with libtool

e better off > not using libtool at all, and just doing > g++ -shared -o libGUI.so Well that would be fine. We just need to build for Linux. To be honest I don't know why we are using libtool. I will try just using g++ ... Thanks again David ___ https://lists.gnu.org/mailman/listinfo/libtool

RE: Help needed to build shared library with libtool

Hi Peter I have tried using just g++ (no libtool) and the link succeeds. On this occasion it seems easiest for me just not to use libtool. Thanks for your help and advice. Best regards David ___ https://lists.gnu.org/mailman/listinfo/libtool

Re: Fwd: Fwd: android support

Hello, Glad seeing this being addressed :-) On Tue, Sep 10, 2013 at 12:41 AM, Brooks Moses wrote: > Hello, Marco, > > Thanks for pinging this -- I'm trying to work through some of the libtool > patch backlog, and I'll have a look at this in the next few days. > > I

solaris 10: [EMAIL PROTECTED]

to the above: in my own case, I know that our GNU ld and libtool are somewhat out-of-date. So I've attempted to get libtool 1.5.18 installed. "make check" is fine on S8, but has a failure in "mdemo2-make.test" on S10. If someone can guide

Re: solaris 10: [EMAIL PROTECTED]

On Wed, 29 Jun 2005, Ralf Wildenhues wrote: * David Lee wrote on Tue, Jun 28, 2005 at 07:10:59PM CEST: Quite a few folk seem to be having trouble linking on Solaris 10. These seem to be well-established applications, that have compiled and linked for years on a wide range of OSes, including

Re: solaris 10: [EMAIL PROTECTED]

On Wed, 29 Jun 2005, Ralf Wildenhues wrote: * David Lee wrote on Tue, Jun 28, 2005 at 07:10:59PM CEST: (Incidentally: this may or may not be relevant to the above: in my own case, I know that our GNU ld and libtool are somewhat out-of-date. So I've attempted to get libtool 1.5.18 inst

Re: solaris 10: [EMAIL PROTECTED]

On Mon, 4 Jul 2005, Howard Chu wrote: Bob Friesenhahn wrote: On Mon, 4 Jul 2005, David Lee wrote: I'm using GNU/ld; but I'd be happy,as part of the experiments, to try to redirect our "gcc" to use the Solaris/ld. (How to redirect it?) I recommend that anyone wh

Re: solaris 10: [EMAIL PROTECTED]

On Mon, 4 Jul 2005, David Lee wrote: [...] For instance, do we _know_ that this S10/[EMAIL PROTECTED] problem is _definitely_ 100% attributable to GNU/ld? Is "libtool" known/proven to be not contributing in any way to this problem? As was mentioned in my email of 29th June, the &

ltdl dlpreopen behavior

ith a substitution into my actual C code, but thats kind of ugly... Any suggestions? I imagine my program would be a fairly common design wrt builtin+optional modules (the linux kernel is an obvious example). Thanks, David ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: handling of missing AR

configure detects an inconsistency, this is a "hard fail" and it bails out.) This has had the huge benefit of giving new end-users a "configure" that actually completes. They can then quickly move on to a final product (albeit one that may lack some desirable (but not vit

Re: automake/libtool question

Thank you for responding Ralf, On 9/12/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: [ Cc:ing both lists; let's drop the automake list ] Hello David, * David Everly wrote on Tue, Sep 12, 2006 at 01:02:47AM CEST: > > HP-UX B.11.23 U ia64 > automake (GNU automake) 1

Re: wgcc 2.0 RC1 released

"Duft Markus" <[EMAIL PROTECTED]> writes: > Hi again! > > For all interested in native Windows binaries built with Autotools and > mnay other interesting things: I'm not sure whether this is on-topic for Boost; it seems of somewhat borderline relevance. However, now that you've started the thr

Re: [boost] wgcc 2.0 RC1 released

"Duft Markus" <[EMAIL PROTECTED]> writes: > When building with wgcc there are a few benefits: > > Wgcc uses the native windows compiler to build (so the code may or may > not be faster ;o)) and whats a lot more important: the debug > information produced is readable by visual studio, so you can de

force shared noinst_LTLIBRARIES?

f hook to remove unwanted installs (ick). Or is there a simpler (yet still portable) way to do what I want? Thanks in advance. Fang David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Nets

Re: force shared noinst_LTLIBRARIES?

> On Thu, July 26, 2007 01:20, David Fang wrote: > > I wasn't able to find an answer for this in the libtool/automake > > manuals: Is there a way to force libtool (with automake) to create the > > shared version of an uninstalled library? I would like to use libtool

libltdl's (1.5.24) Makefile.in configure ... autotool version mixing?

nonexistent 'mkinstalldirs' and the top-level dist/distcheck seems happy. Is this a sin I'm going to pay for? Thanks in advance. David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~f

Re: libltdl's (1.5.24) Makefile.in configure ... autotool version mixing?

I am not going to release 1.5.26 for this though :) Not critical for sure, but perhaps worth noting somewhere in the docs? That libltdl's build support files are generated with version X, but the above steps can be done to regenerate with version Y. I can see this being applicable to

dlopening installable ltdl modules failing (OS X problem only)

with more concrete details if I haven't been clear enough. Thanks in advance. Fang David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!) ___

Re: dlopening installable ltdl modules failing (OS X problem only)

> > I'm having a problem testing some libtool (ltdl) modules, but only > > on OS X (darwin7 and darwin8, libtool 1.5.22 and .24). My executable > > lt_dlopens a .la library in another built directory (during make check > > testing), and fails with an lt_dlerror message like: > > > > dlopen(../

Re: dlopening installable ltdl modules failing (OS X problem only)

> > It is entirely possible that you've found a bug, Mac OS X should work > > the same as linux et.al. in this regard. Does the module itself have any > > dependencies that possibly are not being found (check with otool -L > > mymodule.0.so)? If that is not the case, please send more info (if you >

Re: dlopening installable ltdl modules failing (OS X problem only)

> > > It is entirely possible that you've found a bug, Mac OS X should work > > > the same as linux et.al. in this regard. Does the module itself have any > > > dependencies that possibly are not being found (check with otool -L > > > mymodule.0.so)? If that is not the case, please send more info (

Re: dlopening installable ltdl modules failing (OS X problem only)

Hi, Must've missed this message earlier... > > The executable takes command-line arguments that call lt_dladdsearchpath > > (option -L) and lt_dlopenext (option -l). The file, ../../lib/mymodule.la > > has already been built at the time of testing. The executable is invoked > > with "-L.

Sun Studio linking issues in Solaris 9

$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \ - $(libauthldap_la_LDFLAGS) $(LDFLAGS) -o $@ + $(LDFLAGS) $(libauthldap_la_LDFLAGS) -o $@ am_libauthmysql_la_OBJECTS = authmysql.lo preauthmysql.lo \ authmysqllib.lo libauthmysql_la_OB

Re: Sun Studio linking issues in Solaris 9

that part out of the Makefile.in and forward your response back to him. I don't see how libtool could be at fault here when the arguments are being given to libtool incorrectly. Thanks for the help anyways, -Dave -- ==== David Halik Student Programmer OSS/NBCS - OIT

Re: C++ Plugins and virtual destructors.

tion outside of main, i.e. one thrown and uncaught during statics. I'm not sure a C++ plug-in would work in C, but if you had a function for cleaning up resources (something likely to appear in a dtor), you could register a cleanup function with atexit(). Fang David Fang Computer Systems La

passing flags to the librarian

I'm building a libtool-based package (pcre) using Microsoft command line tools in a cygwin shell. I use a wrapper script for the compiler and linker (cccl), but the librarian (lib) gets invoked directly. I'd like to specify the /LTCG (link time code generation flag) to the librarian. Beats me wh

RE: passing flags to the librarian

On Tuesday, December 11, 2007, Duft Markus wrote: > You may wanr to have a look at parity > (http://www.sf.net/projects/parity). It was written more or less to be > more powerfull than cccl (but for now is only tested with interix, not > cygwin). I'm going to stick with cccl for now. > Also par

Re: GNU Libtool 2.2 released.

=2 -C % make && make -k check ... All 124 tests passed and 63 tests behaved as expected. 1 test was skipped. (skipped #55: template test with subdirs) Looking forward to using 2.2! Fang David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornel

Re: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half

enSolaris, Darwin. -- David Johnson ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: IA64 HP-UX libtool / gcc question about shared libraries

th works but it searches for build directories not present on the install system. David ___ http://lists.gnu.org/mailman/listinfo/libtool

Problem upgrading Xorg--libtool issue?

st an alternate solution. For example, can I simply remove the libxcb-xlib references from all the .la files? How about simply making a dummy libxcb-xlib.so library? Anything else? Thanks in advance. Please CC me directly as I don't subscribe

Re: Problem upgrading Xorg--libtool issue?

Hi Ralf, Thanks for the reply. I tried the dummy lib option and amazingly it worked. As far as I can tell, all the apps I've tried (whether part of xorg or not) seeem to work. David On Fri, 2009-04-10 at 17:50 +0200, Ralf Wildenhues wrote: > Hello David, > > sorry

different flags for static and shared

Sorry if this is a FAQ. I'm building a library using the pr-msvc-support branch of libtool so I'm using native MSVC tools. When building a shared lib I'm doing one of the methods prescribed here: http://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Shar ed-Libraries.html Spec

RE: different flags for static and shared

On July 25, 2009, Ralf Wildenhues wrote: > * David Byron wrote on Tue, Jun 30, 2009 at 12:22:52AM > CEST: > > > In the case where a build directory is configured for > > static only (e.g. invoked with --disable-shared) I can > > add -DLIBFOO_STATIC to one of the CPPFL

using $bindir when installing using msys

I've run into a situation where libtool isn't installing my DLL where I expect it to. I'm invoking configure with these options: --prefix=/c/foo/install --libdir=/c/foo/install/lib/Debug --bindir=/c/foo/install/bin/Debug but when I run make install, libtool leaves me with: $ ls /c/foo/install/l

RE: using $bindir when installing using msys

> > I'm curious why libtool doesn't seem to be honoring the > > --bindir option I passed to configure. > > A fix is being worked on: > > Sorry for the noise. -DB ___

global_symbol_pipe not picking up an initialized global variable with msvc

I'm pretty sure I'm running into a pr-msvc-support-specific problem but I'm still learning about libtool so... I'm trying to get rid of unresolved externs when linked an executable against a libtool shared library compiled with msvc. The unresolved externs are global variables. The code in quest

RE: global_symbol_pipe not picking up an initialized globalvariable with msvc

> > UTL_EXPORT becomes __declspec(dllexport) when compiling > > the shared lib, __declspec(dllimport) when compiling the > > executable that uses it. > > did you double check if that really works on both sides? > your problem sound to me as if dllimport is missing > somewhere. Not enough. I chec

RE: global_symbol_pipe not picking up an initialized global variable with msvc

> I tried to reproduce (but failed, so I think the symbol pipe is > definitely out of the loop): I agree. I was on the road to put this together when I found the broken UTL_EXPORT as the culprit. Thanks for going to the trouble to build a simple example. By bad for not doing this before I poste

RE: different flags for static and shared

> > #if BUILDING_LIBFOO && HAVE_VISIBILITY > > #define LIBFOO_DLL_EXPORTED __attribute__((__visibility__("default"))) > > #elif BUILDING_LIBFOO && defined _MSC_VER > > #define LIBFOO_DLL_EXPORTED __declspec(dllexport) > > #elif defined _MSC_VER > > #define LIBFOO_DLL_E

extra exports with libtool (pr-msvc-support)

I'm running into a situation where libtool is exporting something I don't expect it to. I've attached a tarball that demonstrates this. So it's more clear what I'm talking about without having to dive into the attachment, I'm compiling a shared library that I think should have one export. But

RE: extra exports with libtool (pr-msvc-support)

Re-ordering paragraphs... > Not on all systems, but I think that will happen with gcc/ld though. > I think they will only export dllexported symbols if at least one such > symbol exist. However, this causes some trouble if you e.g. have a > library that is not decorated with dllexport and which us

RE: extra exports with libtool (pr-msvc-support)

> The portable way to specify which symbols you want to be > visible (with libtool) is to use -export-symbols or > -export-symbols-regex, IIUC. So, assuming you have some > visibility requirements you are better off using those > options anyway. Lightbulb goes on a bit. Whatever happens with __de

RE: extra exports with libtool (pr-msvc-support)

> Indeed, good to know. Your input made me realize that it > should be possible to work around the extra exports with > something like -export-symbols-regex=probably_not_a_match > or with an empty SYMFILE and -export-symbols=SYMFILE > > Untested though, but the linker should then pick up the > sym

pr-msvc-support: building .DLLs with symbols

Even when I set LDFLAGS to -DEBUG, I can't seem to get libtool to use that flag when building a dll. So, I want to get debug information into the .dll but it's not there. I verified that it's not there by looking at the output of dumpbin -all. Here's the libtool invocation and output for the lin

RE: pr-msvc-support: building .DLLs with symbols

> You want to send -DEBUG to link.exe, not to cl.exe. I'm > sure you know this, but simply adding -DEBUG to LDFLAGS is > not the way you do this. The correct way would be to use > -Wl,-DEBUG. If the msvc stuff were complete, libtool would > then feed -DEBUG to the linker. But this does not > curre

RE: extra exports with libtool (pr-msvc-support)

> > I just tried this by adding > > > > libfoo_la_LDFLAGS += -export-symbols symfile > > > > and manually creating an empty file named symfile in the > > example I posted earlier. Now the only symbol that gets > > exported is the one decorated with dllexport. Thanks > > for the workaround. One

control where win32 DLLs get installed behavior

I've grabbed the latest libtool sources from the pr-msvc-support branch, hoping to get more control over where libtool installs DLLs. Unfortunately, my DLLs are going to the same place they were before. I got libtool to do the advertised thing when I invoke it manually, like this: /bin/sh ./libt

RE: control where win32 DLLs get installed behavior

On November 1, 2009, Ralf Wildenhues wrote: > Yes. We haven't figured out whether and when automake > should do this automatically. If we do, then a future > release of Automake may change this. Until then you can > use add `-bindir $(bindir)' to either AM_LDFLAGS (if this > is to be set for a

Re: release procedure

) use libltdl in C++ projects. Sure, the header forces symbols to have C-linkage in any case, but I'd sleep better knowing this was covered somehow. Fang David Fang http://www.csl.cornell.edu/~fang/ http://www.achronix.com/ ___ http://lists.gnu.o

Re: Getting executable to link to libtool-built library

self. Anyway, after I supplied the definitions and rebuilt the library, I can link tuxmath to it. Anyway, if someone would confirm that AC_CHECK_LIB is the right way to do this, I would be a most appreciative libtool newbie. Thanks, David Bruce ___ ht

Getting executable to link to libtool-built library

kcommon.la in tuxmath's Makefile.am, which fails with "no rule to make libt4kcommon.la needed by tuxmath". However, I don't think LDADD is the correct approach here anyway. Anyone have any suggestions for the probably obvious step I&#x

Re: Getting executable to link to libtool-built library

Hello, On Mon, Dec 28, 2009 at 3:22 AM, Alberto Luaces wrote: > David Bruce writes: > >> Hello, >> >> I have two related programs (tuxmath and tuxtype) that share a lot of >> code in a human-maintained, copy-and-past fashion.  We have been >> working o

excluding libraries

Hi, I have a question about using libtool... Here's the situation: Our project has the FOX gui toolkit as a dependency. FOX is autoconfiscated and uses libtool too, so when FOX installs itself there is a libFOX.la created in /usr/lib. One unfortunate thing about FOX is that it has some

Re: [Autogen-devel] autogen configuration on Mac OS X

At 3:13 PM -0800 3/28/02, Bruce Korb wrote: >David Bacher wrote: >> I'm currently trying to work through multiply-defined symbol errors >> in autoopts, which look like a problem with libtool. The link command >> generated by libtool is including a convenience libr

Re: excluding libraries

Did anyone read my posting? I got no help or response whatsoever... If you just don't know how to answer I guess just don't respond, but if you don't understand my question, let me know and I'll try to explain again. David Durham wrote: > Hi, > > I have a

Supporting separate build roots

ake libtool 1.4a (at least the version used by KDE 2.2) honor $ROOT properly. The code is slightly wrong in that if a library is missing from $ROOT it will still find it in /usr, but that seemed like the simplest work-around for finding uninstalled helper libraries. David -- Dav

Re: gunzip: libtool-1.4.2.tar.gz: invalid compressed data--crc error

to be ok. The file size should be 1184578 bytes. //David Olofson --- Programmer, Reologica Instruments AB .- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional M

Re: "Re: libbfd, libtool & Win32" and "Re: Building a MinGW GLib etc..."

DL_AddTimer [ 1] SDL_AllocRW [ 2] SDL_AudioDriverName [ 3] SDL_AudioInit [ 4] SDL_AudioQuit [ 5] SDL_BuildAudioCVT ... Has anyone tried hacking a script to turn that into a .def file? Or should I, or someone else, just try to add a feature to objdump? //Da

Re: [Mingw-users] Re: libbfd, libtool & Win32

, we're talking about something that's *really* broken, inconcistent (any one else cares about HOST_CC...?), and a major PITA for a great number of users. (I might be the first, but even the established workarounds failed on my setup...) And now I'm not even

Re: Autoconf 2.54 is released

btool 1.4e (cvs), and tried autoconf 2.53, 2.54. Thanks -- ..... David L. Thompson The University of Montana mailto:[EMAIL PROTECTED] Computer Science Department http://www.cs.umt

Re: [Mingw-users] Re: libbfd, libtool & Win32

with trickier stuff must upgrade their binutils to a > recent version. How does that sound? That could work. Dunno' about the reliability or portability of fitering 'objdump -p' output, but if it works for most people for now, it can at least avoid strictly forcing every cross

Re: [Mingw-users] Re: libbfd, libtool & Win32

On Wednesday 18 September 2002 11:08, David Olofson wrote: [...] > Indeed, it seems that the export section is *not* really a symbol > table, which is why some DLLs can have symbols ('-syms'), while most > DLLs don't. (In fact, I think clean DLLs *shouldn't* have th

Re: [Mingw-users] Re: libbfd, libtool & Win32

On Wednesday 18 September 2002 11:46, Danny Smith wrote: > --- David Olofson <[EMAIL PROTECTED]> wrote: > On Tuesday 17 > > September 2002 20:33, Guido Draheim wrote: > > [...] > > > > > On another e-mail, you said to have some idea of the `objdump -p` >

Re: [Mingw-users] Re: libbfd, libtool & Win32

pgen.c...? > > It is an issue with impgen. Try: > % impgen c:/winnt/system32/user32.dll > > All the names should have stdcall decoration, but don't. Ok... Is that information at all available in a DLL, or does that mean we either have to make assumptions, or just *require*

Re: Converting a project to libtool

uot; which will produce a library like libwhatever.so.0.0.3. > > Don't know why it was done this way but there must have been a good > reason. AFAIK, the idea is that the version info used during build should be usable as a way of matching applications with a *range* of library v

Re: [Mingw-users] Re: libbfd, libtool & Win32

ea for other reasons. Would be nice if it could be made to work somehow, but I probably won't make use of that feature myself. //David Olofson --- Programmer, Reologica Instruments AB .- Coming soon from VaporWare Inc.... | The Return of Audi

Re: [Mingw-users] Re: libbfd, libtool & Win32

On Friday 20 September 2002 22:31, Guido Draheim wrote: > David Olofson wrote: [...] > > How about building import libs from headers? (You need the headers to > > compile anyway...) > > Ahhm, not quite - some functions are exported only on a case-by-case > basis,

Re: [Mingw-users] Re: libbfd, libtool & Win32

On Monday 23 September 2002 13:00, David Olofson wrote: > On Friday 20 September 2002 22:31, Guido Draheim wrote: [...] > > In > > fact, we have a set of function names for a given lib - in its > > symbol table. > > In an export table, I would say, as most clean Win32

Re: [Mingw-users] Re: libbfd, libtool & Win32

On Monday 23 September 2002 15:30, Earnie Boyd wrote: > David Olofson wrote: > > However, it's still a very bad idea to compile tools as part of the > > application build process. ;-) > > Right, if you want to install implib as part of distributable resource > when

cygwin static archives piecewise

generated libtool and the biggest problem is that /OUT:library.lib is part of the old_archive_cmds variable. So this needs to be broke up differently. Has this work already been fixed in CVS? Should I work on it? David

Re: getting a locally built library

On Thursday, November 14, 2002, at 11:36 AM, Bruce Korb wrote: You're specifically adding -L/sw/lib. Don't. It will get added by the configure script in the right place automatically, as long as /sw/bin/guile-config and xml2-config are properly found with the PATH variable. Gotcha. Removing

Re: getting a locally built library

On Thursday, November 14, 2002, at 08:39 AM, Alexandre Duret-Lutz wrote: David, could you explain where `-L../autoopts/.libs -lopts' comes from? Sure. Here are my original libtool link and compiler link commands: /bin/sh ../libtool --mode=link gcc -g -O2 -L/sw/lib -o autogen au

Linking problem

n both of the sets are PIC. So there shouldn't be any difference between them. But when I link the library using the files in "." directory - every thing is ok. Do you happen to know, where the problem is? David P.S.: I have the following flags: CXXFLAGS = -noimplicit_include -p

Lower your payments

___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

RE: Building JNI libraries on MacOS X and other systems

" on the link line. To use it for jnilibs, you will have to have some configury to set the option on MacOS X only. HTH, Robert -- ..... David L. Thompson Visualization and Imagery Solutions, Inc. mail

Test failures on a HP running HP-UX 10.20

configure: configure --prefix=/home/urban/local/hp --enable-shared --enable-static uname -a: HP-UX spica B.10.20 A 9000/735 2008140532 two-user license gcc -v: Reading specs from /home/urban/local/hp/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.96/specs gcc version 2.96 2612 (experimental) as -v: G

Re: DLL naming conventions

without stepping on the other things she installed last week. IMHO, this is why Windoz walked all over XNix; even tho' XNix was there first. Windoz is /hard/ on developers, but several million "simple" /users/ never see the difficulty -- except, of course, at the CompUSA cash regis

libtool adds multiple `-lg' options linking [v3] testsuite

Forwarded message: >From dave Thu Apr 26 13:01:45 EDT 2001 Subject: libtool adds multiple `-lg' options linking [v3] testsuite To: [EMAIL PROTECTED] Date: Thu, 26 Apr 2001 13:01:45 -0400 (EDT) From: "John David Anglin" X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Conten

  1   2   >