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

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

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

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

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)

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

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

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

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: 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 ___

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

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

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