Re: Building DLL

2004-07-11 Thread boekhold
Hi all, I've been trying the suggestions mentioned on this list: 1. Create an import library echo EXPORTS > foo.def nm foo.exe | grep ' T _' | sed 's/.* T _//' >> foo.def dlltool --def foo.def --dllname foo.exe --output-lib foo.a I couldn't get this to work. In the executable I am trying to load

Re: How change libtool rule of naming dlls from "cygFOO-version.dll" to "FOO.dll"?

2004-12-23 Thread Maarten Boekhold
Mikhail Dmitrievsky wrote: Hello! I have a problem. I write dll for Tcl and my dll must have fixed name "libsurfit.dll" because of fixed initial procedure name, but using libtool i have cygsurfit-1.dll :( Use the "-module" flag with libtool. That will create libsurfit-1.dll instead of cygsurfi

XEmacs 21.4.15, shell-mode not working?

2004-03-30 Thread Maarten Boekhold
Hi all, I just install the latest version of cygwin (downloaded last friday) on a new computer, and I'm having a small problem with XEmacs (21.4.5). It appears the shell-mode is not working. If I do 'M-x shell', it instead executes 'shell-command', if I do 'M-x shell', 'shell' is not listed as a

cygwin affected by windows domain settings?

2004-06-07 Thread Maarten Boekhold
Hi, Is cygwin in any way affected by the windows domain settings, other than user credentials? Reason I ask: I'm trying to check out some CVS sources from a server that requires you to use ssh as the remote shell, so I do: export CVS_RSH="ssh" cvs ... ssh complains that it: Could n

Re: cygwin affected by windows domain settings?

2004-06-07 Thread Maarten Boekhold
Maarten Boekhold wrote: ssh complains that it: Could not create directory //server/user.name$/.ssh Doh, sorry. Just noticed that my user entry in /etc/passwd was still pointing to the network drive. Changed this, and it's working fine... -- Unsubscribe info: http://cygwin.c

Building DLL

2004-07-07 Thread Maarten Boekhold
Hi all, Now that GTK2 is in the package tree, I thought I'd give building XFCE a try. This package depends on 'Disk based hashes' (dbh), which needs to be built as a shared library. Dbh uses libtool in its build process. Of course this complains with libtool: link: warning: undefined sym

Re: Building DLL

2004-07-08 Thread Maarten Boekhold
Hi all, Gerrit P. Haase wrote: Maarten wrote: Now that GTK2 is in the package tree, I thought I'd give building XFCE a try. This package depends on 'Disk based hashes' (dbh), which needs to be built as a shared library. Dbh uses libtool in its build process. You don't need .def files on Cygwin. J

Re: Building DLL

2004-07-09 Thread Maarten Boekhold
Gerrit P. Haase wrote: You don't need .def files on Cygwin. Just add -no-undefined to libxyz_LDFLAGS. OK, I'm making progress with getting XFCE to compile under cygwin (with help of one of the XFCE developers), but now we're running into the following: XFCE has a plugin mechanism, based on sha

Re: Building DLL

2004-07-09 Thread Maarten Boekhold
Put all the functions into a library. Link the application and the modules against this library (building only the appA's main() into the executable). Hmmm, not sure if I can convinve the XFCE developers of such a change, as it's fairly major. It was also reported that creating an import librar

Re: Building DLL

2004-07-10 Thread Maarten Boekhold
Larry Hall wrote: It was also reported that creating an import library (or stub library) for the executables functions is sufficient if it is linked in, IIRC it this might be more acceptable, but I have no idea of how to go about that... Anybody knows more about how to do this? was the same prob

Re: Building DLL

2004-07-12 Thread Maarten Boekhold
Hi all, Sorry to keep going on about this, I really want to get this working. I've made *some* progress in how to build "plugin libraries". I have attached my test case to this mail in case somebody is willing to have a look at it. Let me describe it first. I did some reading on the libtool docu

dlopen under cygwin

2004-07-13 Thread Maarten Boekhold
Hi all, Is dlopen() & friends supported under cygwin? If so, is the DLL that gets loaded using dlopen() a regular Win32 DLL, or a 'special' type of cygwin DLL? Reason I ask it that (while trying to get 'plugins' to work under cygwin) I had a look at the gmodule source code of glib, and it seems

Cygwin's libtool, passing .def file name to gcc during linking

2004-09-09 Thread Maarten Boekhold
Hi, I'm trying to port an application to Cygwin that uses libtool to drive compilation/linking. This application needs to be linked with a ".def" file during the linking stage, i.e. (formatted to make it readable) /bin/bash ./libtool --mode=link gcc -g -O2 -o libplugin.la -

Re: Cygwin's libtool, passing .def file name to gcc during linking

2004-09-09 Thread Maarten Boekhold
Ha, who'd have thought... I found it. I can use '--export-symbols plugin.def' for this. Even though the plugin.def doesn't contain exports, but imports... (this is a plugin library that invokes functions contained in the executable that loads the library...) Maarten Maarte

libtool-1.5.6-3, export-symbols-regex bug?

2004-09-11 Thread Maarten Boekhold
Hi, libtool-1.5.6-3, cygwin 1.5.10(0.116/4/2) I noticed the following today when trying to compile an application. Before I upgraded libtool earlier this week (not sure from which version, but a very recent one), this worked. When you use '-export-symbols-regex "^[^_].*"', libtool generates a fi

Re: libtool-1.5.6-3, export-symbols-regex bug?

2004-09-12 Thread Maarten Boekhold
Gerrit P. Haase wrote: Please see: http://sources.redhat.com/ml/cygwin/2004-08/msg00607.html Glad I'm not the only one who noticed this. In Chuck's reply to the cygwin list he says he'll look into this. I haven't seen any further reply from him yet, neither on the cygwin list nor on the libtool

cygwin glib/g_module_build_path

2004-09-12 Thread Maarten Boekhold
Hi Gerrit, Using libtool under cygwin, it is quite common that a shared library (eg. cygfoo.dll) is installed in a different directory than the libtool library (eg. libfoo.la). libfoo.la would then point to the location of the actual DLL: # The name that we can dlopen(3). dlname='../bin/cygxfce

Exporting const functions from DLL

2004-09-24 Thread Maarten Boekhold
Hi, I ran into the following: icons.h: const gchar * resolve_folder_icon(tree_entry_t * en); icons.c: __declspec(dllexport) const gchar *resolve_folder_icon (tree_entry_t * en) { etc.. } Compile error: icons.c:562: error: external linkage required for symbol 'resolve_icon' because of 'dllexport' a

Re: Exporting const functions from DLL

2004-09-24 Thread Maarten Boekhold
Hi all, sorry, never mind. My mistake... As you probably noticed, I was looking at the wrong function! Maarten Maarten Boekhold wrote: Hi, I ran into the following: icons.h: const gchar * resolve_folder_icon(tree_entry_t * en); icons.c: __declspec(dllexport) const gchar *resolve_folder_icon

Memory debugging under cygwin

2004-10-02 Thread Maarten Boekhold
Hi all, I have a program that segfaults, and it's quite obvious that this is caused due to some memory corruption. Except it segfaults at a place where, if running it in gdb, there shouldn't be a problem. There seems to be some memory corruption somewhere, and I can't figure out where. I tried

Building plugin that is used from multiple executables

2004-10-06 Thread Maarten Boekhold
Hi, Suppose I have a plugin library that contains calls that reside in the executable that dlopen()'s that plugin. You can link such a plugin by using a .def file that contains something like: IMPORTS symbol = executable.exe.symbol Now if I need to be able to use the *same* plugin from *two* exe

Re: Memory debugging under cygwin

2004-10-07 Thread Maarten Boekhold
Dan Osborne wrote: Could you get the test program to work? That shows how it wants to play. The only problem I found with it was that it wouldn't follow shared objects. Yeah, that seems to be the problem I have to. Unfortunately the memory corruption I'm looking for is *in* a shared object. And c

Plugins and referencing *variables* in the loading program

2004-10-08 Thread Maarten Boekhold
Hi, suppose I have application A, that loads (gmodule_open) a module B. 'A' contains a variable: A.c: G_MODULE_EXPORT int var = 1; B refers to that variable: B.c: G_MODULE_IMPORT int var; B is linked with a A.def file: A.def: IMPORTS var = A

Re: Plugins and referencing *variables* in the loading program

2004-10-09 Thread Maarten Boekhold
in is trying to reference a *variable* in the loading program, and that *fails*. I can post my test program if anybody is interested... Maarten Brian Dessent wrote: Maarten Boekhold wrote: suppose I have application A, that loads (gmodule_open) a module B. 'A' contains a varia

Re: Plugins and referencing *variables* in the loading program

2004-10-09 Thread Maarten Boekhold
Maarten Boekhold wrote: I can post my test program if anybody is interested... Please see attached. $ tar zxf vartest.tar.gz $ cd vartest $ ./autogen.sh ... $ make install ... $ /usr/local/bin/plugintest.exe 5 ** Message: trying to open /usr/local/lib/cygplugin.dll val coming from the executable

Re: Plugins and referencing *variables* in the loading program

2004-10-09 Thread Maarten Boekhold
Maarten Boekhold wrote: Maarten Boekhold wrote: I can post my test program if anybody is interested... Please see attached. Damned and double damned... The previous version had an obvious error in it. Sorry all for wasting your band-width. Attached is a correct version. Maarten

Autotool versions

2004-11-06 Thread Maarten Boekhold
Hi all, I seem to remember that the cygwin versions of libtool/autoconf/automake have/had cygwin specific patches applied to them. Is that (still) the case, or is cygwin distributed with the official upstream versions? Kind regards, Maarten -- Unsubscribe info: http://cygwin.com/ml/#unsubsc

Re: Using Sybase DLLs from Cygwin apps

2004-11-26 Thread Maarten Boekhold
Jason Tishler wrote: Why not use FreeTDS (http://www.freetds.org/) instead of the Sybase's Win32 libraries? IIRC, both sqsh and FreeTDS build OOTB under Cygwin. FWIW, I have used Cygwin sqsh/FreeTDS successfully with Microsoft SQL Server. However, YMMV with Sybase... For sqsh, FreeTDS works fine