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

[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 cygsurfit-1.dll.

If you also want to get rid of the version number, use in addition the 
"-avoid-version" flag.

eg.
libtool -module -avoid-version ...
Maarten
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Using Sybase DLLs from Cygwin apps

[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, however I suspect that Michael's ultimate 
goal is to link DBD::Sybase (Michael is the maintainer of that) with the 
Sybase libraries.

It's possible to build DBD::Sybase with FreeTDS, but it doesn't have 
complete functionality. '?' placeholders in prepared statements don't 
work because FreeTDS doesn't support them yet for Sybase databases. 
That's a pretty important piece of functionality that's missing.

It's funny, I've been trying the same thing as Michael yesterday, for 
probably the same reasons. I wonder if it wouldn't be easier to try to 
help out the FreeTDS team to implement the missing functionality.

Maarten
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Autotool versions

[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/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

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

[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


vartest.tar.gz
Description: GNU Zip compressed data
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

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

[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: 1626351103
$ make uninstall
...
Maarten


vartest.tar.gz
Description: GNU Zip compressed data
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

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

[Maarten Boekhold]

Hi Brian,
Don't know if you noticed, but the thread you are referring to was 
started by me as well :) All the material discussed in there I managed 
to apply just fine.

However, that thread deals with importing *functions*, not variables. I 
created a stand-alone test in which the plugin 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 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.exe.var
When I use 'var' in B, it has a completely wrong value.
Can the windows linker resolve references to external variables when
loading a library with gmodule_open/dlopen?

You might want to read this thread:
<http://sources.redhat.com/ml/cygwin/2004-10/msg00339.html>
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Plugins and referencing *variables* in the loading program

[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.exe.var
When I use 'var' in B, it has a completely wrong value.
Can the windows linker resolve references to external variables when 
loading a library with gmodule_open/dlopen?

Maarten
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Memory debugging under cygwin

[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 compiling the 
whole app static isn't an option, because it also involves a dynamically 
loaded module :(

Great shame that valgrind isn't ported to cygwin!
Yup...
Maarten
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Building plugin that is used from multiple executables

[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*
executables, how do I resolve that??? Can I use a .def file that
contains:

IMPORTS
symbol = executable_1.exe.symbol
symbol = executable_2.exe.symbol

My gut feeling says 'no', but hope against hope...

Maarten

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Memory debugging under cygwin

[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 linking the app with dmalloc, but I can't get it to generate a 
log file, even if I explicitly request one by including calls to the 
dmalloc library in the application. Valgrind doesn't seem to be 
available on cygwin either.

Can anybody recommend a way to debug this sort of error? Are there any 
other memory debuggers available that work with cygwin?

Maarten
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Exporting const functions from DLL

[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 (tree_entry_t * en)
{
etc..
}
Compile error:
icons.c:562: error: external linkage required for symbol 'resolve_icon' 
because of 'dllexport' attribute.
make: *** [libxffm_basic_la-icons.lo] Error 1

I found a reference to a similar problem at:
http://www.cygwin.com/ml/cygwin/2003-11/msg00654.html
I tried removing the const, adding extern to the include file and all 
possible combinations of that, but no luck...

$ gcc --version
gcc (GCC) 3.3.3 (cygwin special)
$ uname -a
CYGWIN_NT-5.1 DXBM2003 1.5.11(0.116/4/2) 2004-09-04 23:17 i686 unknown 
unknown Cygwin

Does anybody know how to solve this?
Maarten
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Exporting const functions from DLL

[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' attribute.
make: *** [libxffm_basic_la-icons.lo] Error 1

I found a reference to a similar problem at:
http://www.cygwin.com/ml/cygwin/2003-11/msg00654.html
I tried removing the const, adding extern to the include file and all 
possible combinations of that, but no luck...

$ gcc --version
gcc (GCC) 3.3.3 (cygwin special)
$ uname -a
CYGWIN_NT-5.1 DXBM2003 1.5.11(0.116/4/2) 2004-09-04 23:17 i686 unknown 
unknown Cygwin

Does anybody know how to solve this?
Maarten
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

cygwin glib/g_module_build_path

[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/cygxfce4_desktop_menu.dll'
An application using g_module_build_path would usually assume that a 
library is installed in the directory where the libtool archive is located.

g_module_build_path as included in the cygwin version does not take any 
.la libtool archives into account at all, and is therefore likely to 
return the wrong location for a specific shared library. However, 
g_module_open *does* know how to handle .la files and find the actual 
location/filename of the DLL in question.

Should we add a special case to gmodule-win32.c:_g_module_build_path() 
that checks whether there exists a libtool archive at the specified 
directory/module_name location (eg. directory + "/lib" + module_name + 
".la") and if so return that as a path? Or would there be a better 
solution for this?

Maarten
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

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

[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 lists. 
Have you heard anything back?

Q: do you know what a line such as 'parent_class DATA' in the exported 
symbols means?

Maarten
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

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

[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 file 
according to:

/bin/nm -B  .libs/libxfce4util_la-i18n.o 
.libs/libxfce4util_la-licenses-texts.o .libs/libxfce4util_la-utf8.o 
.libs/libxfce4util_la-xfce-desktopentry.o 
.libs/libxfce4util_la-xfce-fileutils.o 
.libs/libxfce4util_la-xfce-kiosk.o 
.libs/libxfce4util_la-xfce-miscutils.o .libs/libxfce4util_la-xfce-rc.o 
.libs/libxfce4util_la-xfce-rc-config.o 
.libs/libxfce4util_la-xfce-rc-simple.o 
.libs/libxfce4util_la-xfce-resource.o  | sed -n -e 's/^.*[ 
]\([ABCDGIRSTW][ABCDGIRSTW]*\)[  ][ 
]*\(_\)\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2\3 \3/p' | /bin/sed -e 
'/^[BCDGS] /s/.* \([^ ]*\)/\1 DATA/' | /bin/sed -e '/^[AITW] /s/.* //' | 
sort | uniq > .libs/libxfce4util.exp
grep -E -e "^[^_].*" ".libs/libxfce4util.exp" > ".libs/libxfce4util.expT"

(sorry for the ugly way the lines are broken...)
The first part (nm -B ... > .libs/libxfce4util.exp) generates a file 
that looks like:

R _xfce_builtin_license_BSD xfce_builtin_license_BSD
R _xfce_builtin_license_GPL xfce_builtin_license_GPL
R _xfce_builtin_license_LGPL xfce_builtin_license_LGPL
_xfce_rc_config_close
_xfce_rc_config_flush
_xfce_rc_config_get_entries
...
_xfce_rc_simple_write_entry
parent_class DATA
utf8_string_remove_controls
xfce_desktop_entry_get_file
xfce_desktop_entry_get_int
xfce_desktop_entry_get_string
xfce_desktop_entry_get_type
...
I suspect that the "R _xfce..." lines are invalid. The 'parent_class 
DATA' line also looks suspicious to me.

Can the cygwin libtool maintainer please comment on this? Is this a bug, 
or should I adjust the regex passed to -export-symbols-regex?

Kind regards, Maarten
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

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

[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
Maarten Boekhold wrote:
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 -rpath /usr/local/lib
-no-undefined
-module
libplugin_la-plugin.lo -lgobject-2.0
-lglib-2.0 -lintl -liconv plugin.def
  ^^
rm -fr  .libs/libplugin.dll.a
gcc -shared  .libs/libplugin_la-plugin.o
-L/usr/lib /usr/lib/libgobject-2.0.dll.a
/usr/lib/libglib-2.0.dll.a /usr/lib/libintl.dll.a
/usr/lib/libiconv.dll.a  -o .libs/cygplugin-0.dll
-Wl,--image-base=0x1000
-Wl,--out-implib,.libs/libplugin.dll.a
as you see I'm trying to pass a 'plugin.def' filename to libtool, with 
the intention this shows up in the GCC command. It doesn't, and I can't 
figure out how to pass this apart from manually hacking libtool.

Anybody have any suggestions?
(btw. the reason I send this to the cygwin list is that I know the 
cygwin version of libtool is somewhat hacked. I'm using devel btw.)

Maarten
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

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

[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 -rpath /usr/local/lib
-no-undefined
-module
libplugin_la-plugin.lo -lgobject-2.0
-lglib-2.0 -lintl -liconv plugin.def
  ^^
rm -fr  .libs/libplugin.dll.a
gcc -shared  .libs/libplugin_la-plugin.o
-L/usr/lib /usr/lib/libgobject-2.0.dll.a
/usr/lib/libglib-2.0.dll.a /usr/lib/libintl.dll.a
/usr/lib/libiconv.dll.a  -o .libs/cygplugin-0.dll
-Wl,--image-base=0x1000
-Wl,--out-implib,.libs/libplugin.dll.a
as you see I'm trying to pass a 'plugin.def' filename to libtool, with 
the intention this shows up in the GCC command. It doesn't, and I can't 
figure out how to pass this apart from manually hacking libtool.

Anybody have any suggestions?
(btw. the reason I send this to the cygwin list is that I know the 
cygwin version of libtool is somewhat hacked. I'm using devel btw.)

Maarten
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

dlopen under cygwin

[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 
that gmodule uses regular Win32 LoadLibrary() calls to load the DLL, 
instead of calling dlopen(). I was wondering if that it actually correct.

Kind regards,
Maarten
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Building DLL

[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 documentation, and according to that, 
libtool 1.5.6 has specific support for dlopen'ed libraries (which is 
what glib/gmodule uses under the hood if I'm not mistaken). The trick is 
an extra macro to your configure.ac (AC_LIBTOOL_DLOPEN) and two 
additional flags to libtool: -module and -export-dynamic. Now, I'm not 
sure if that support is supposed to work on cygwin. But together with a 
"plugin.def" file that defines to the library that a symbol is exported 
by the executable, I can now get things to compile.

Caveat: I cannot get the 'plugin.def' file passed to the gcc command 
line when linking:

/bin/bash ./libtool --mode=link gcc  -g -O2   -o libplugin.la -rpath 
/usr/local/lib -no-undefined -module plugin.def libplugin_la-plugin.lo 
-lgobject-2.0 -lglib-2.0 -lintl -liconv
gcc -shared  .libs/libplugin_la-plugin.o  -L/usr/lib 
/usr/lib/libgobject-2.0.dll.a /usr/lib/libglib-2.0.dll.a 
/usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a  -o .libs/cygplugin-0.dll 
-Wl,--image-base=0x1000 -Wl,--out-implib,.libs/libplugin.dll.a

So instead I editted the generated 'libtool' (after running autogen.sh) 
and added it manually:

# Commands used to build and install a shared archive.
archive_cmds="\$CC -shared \$libobjs \$deplibs \$compiler_flags -o 
\$output_objdir/\$soname \${wl}--image-base=0x1000 
\${wl}--out-implib,\$lib plugin.def"

Note the "plugin.def" at the end. Now 'make' succeeds. If anybody knows 
how I can pass the "plugin.def" to the GCC command line, I'd be very 
interested to know.

Run 'make install', and then:
/usr/local/bin/plugintest /usr/local/lib/libplugin.la
This now gives:
$ /usr/local/bin/plugintest.exe /usr/local/lib/libplugin.la
** ERROR **:  1627507512s not a valid Win32 application.
aborting...
Aborted (core dumped)
Is this expected, and is there a way to fix this? Has anybody seen this 
before? (note: for people not familiar with gmodule, the g_module_open() 
function explicitly tests whether this is a libtool library, and if so 
retrieves the actual DLL name from the libplugin.la file).

Kind regards,
Maarten


plugintest.tar.gz
Description: GNU Zip compressed data
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Building DLL

[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 problem with naim & plugins.  Maybe there are some useful
hints in the naim sources.
Wouldn't this work, substituting "executable" for "DLL" in the obvious 
places?


I've looked at this, and I'm willing to give it a try, but I'd like to 
test this first on a small sample. Does anybody have any suggestions on 
how I can test this? I'm a little worried that when you use something 
like 'dlltool --dllname foo.exe ' the name of the executable is 
embedded in the import library, and that you therefore have to build 
that import library with the executable already installed in its final 
location.

There was also discussion of this in the email archives, if you're
interested in that.
Sorry, searched for that, but couldn't come up with any references of 
using dlltool in combination with an executable...

Maarten
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Building DLL

[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 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 problem with naim & plugins.  Maybe there are some useful
hints in the naim sources.
Maarten
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Building DLL

[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 shared libraries. These plugins 
use functions/symbols from the program that they 'plug in to'. I.e. if I 
have appA, and libB is a plugin for appA, then libB contains calls that 
are defined in appA.

How do I get this to work under cygwin? Obviously I can't link libB 
against appA!

Maarten
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Building DLL

[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.  Just add -no-undefined to
libxyz_LDFLAGS.
Of course Gerrit is right. Adding this works. *But only if I use a copy 
of /usr/autotool/devel/bin/libtool*. I.e. I always have to do:

autoreconf
./configure 
cp /usr/autotool/devel/bin/libtool .
make && make install
However, the reported version number of this libtool is the same as the 
one created through configure (autoreconf?) (1.5.6). Is the version 
distributed with cygwin a patched version? If so, is there an official 
release of the autotools that include those patches? If so I'd like to 
try to convince the XFCE developers to upgrade...

Finally, (I know, not really the correct list for this): I'm only 
vaguely familiar with the whole autotools toolchain, and I was wondering 
if somebody could show me some boiler plate configure.ac/Makefile.am 
content so that I can forward the XFCE developers a patch to 
conditionally include '-no-undefined' to the libtool invocation in the 
XFCE build process...

Maarten
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Building DLL

[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 symbols not allowed in
i686-pc-cygwin shared libraries
As far as I know, to get this to build I need to create a .def file, and 
somehow include this in the libtool invocation.

Are there some general hints to determine which functions/symbols need 
to be included in this .def file, and how to modify the libtool 
invocation to use this file?

Kind regards,
Maarten
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: cygwin affected by windows domain settings?

[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.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

cygwin affected by windows domain settings?

[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 not create directory //server/user.name$/.ssh
but:
   echo $HOME
   /home/Maarten (which is a local directory)
Kind regards,
Maarten

Cygwin Configuration Diagnostics
Current System Time: Mon Jun 07 21:38:12 2004

Windows XP Professional Ver 5.1 Build 2600 Service Pack 1

Path:   C:\cygwin\root\opt\postgresql\bin
C:\cygwin\root\opt\postgresql\lib
C:\cygwin\root\bin
C:\cygwin\root\sbin
C:\cygwin\root\bin
C:\cygwin\root\usr\sbin
C:\cygwin\root\usr\local\bin
C:\cygwin\root\usr\local\bin\i686-pc-cygwin
C:\cygwin\root\usr\local\sbin
C:\cygwin\root\usr\X11R6\bin
C:\cygwin\root\opt\lftp\bin
c:\Maarten\script
c:\Maarten\bin
c:\Progra~1\Micros~3\Common\Tools\WinNT
c:\Progra~1\Micros~3\Common\MsDev98\Bin
c:\Progra~1\Micros~3\Common\Tools
c:\Progra~1\Micros~3\VC98\bin
C:\sw\tibco\tibrv\bin
C:\sw\tibco\jms\bin
C:\sw\tibco\administrator\5.1\bin
C:\sw\tibco\designer\5.1\bin
C:\sw\tibco\bw\5.1\bin
C:\sw\tibco\tra\5.1\bin
C:\sw\tibco\tibrv\bin
C:\sw\jdk\1.4.2_02\bin
C:\sw\jdk\1.4.2_02\jre\bin\hotspot
C:\cygwin\root\opt\sybase\bin
C:\cygwin\root\opt\sybase\dll
C:\cygwin\root\opt\sqsh\bin
C:\cygwin\root\opt\wxwidgets\bin
C:\cygwin\root\opt\wxwidgets\lib
C:\cygwin\root\opt\mono\bin
C:\cygwin\root\opt\mono\lib
c:\WINDOWS
c:\WINDOWS\SYSTEM32

Output from C:\cygwin\root\bin\id.exe (nontsec)
UID: 159482(maarten.boekhold) GID: 10513(Domain Users)
10513(Domain Users)

Output from C:\cygwin\root\bin\id.exe (ntsec)
UID: 159482(maarten.boekhold) GID: 10513(Domain Users)
0(root)   
544(Administrators)   547(Power Users)
545(Users)
1005(Debugger Users)

SysDir: C:\WINDOWS\System32
WinDir: C:\WINDOWS

CYGWIN = `binmode tty ntsec'
HOME = `c:\Maarten'
MAKE_MODE = `UNIX'
PWD = `/home/maarten'
USER = `maarten.boekhold'

ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\maarten.boekhold\Application Data'
CLASSPATH = 
`C:\sw\tibco\tibrv\lib\tibrvj.jar;C:\sw\tibco\jms\clients\java\jms.jar;C:\sw\tibco\jms\clients\java\jndi.jar;C:\sw\tibco\jms\clients\java\tibjms.jar;C:\sw\tibco\jms\clients\java\tibcrypt.jar;C:\sw\tibco\jms\clients\java\jnet.jar;C:\sw\tibco\jms\clients\java\jcert.jar;C:\sw\tibco\jms\clients\java\jsse.jar'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `DXBM2003'
COMSPEC = `C:\WINDOWS\system32\cmd.exe'
CVS_RSH = `/bin/ssh'
CYGWIN_ROOT = `C:\cygwin\root'
DISPLAY = `127.0.0.1:0.0'
DSQUERY = `DXBM2003'
HOMEDRIVE = `C:'
HOMESHARE = `\\dxbs02\maarten.boekhold$'
HOSTNAME = `DXBM2003'
INFOPATH = 
`/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:'
LESS = `-Sr'
LOGNAME = `m_boekhold'
LOGONSERVER = `\\DXBD01DMC'
LS_COLORS = 
`no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:ex=00;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.deb=01;31:*.rpm=01;31:*.jpg=01;35:*.png=01;35:*.gif=01;35:*.bmp=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.png=01;35:*.mpg=01;35:*.avi=01;35:*.fli=01;35:*.gl=01;35:*.dl=01;35:'
MANPATH = 
`/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man:/usr/X11R6/man'
MONOBASEPATH = `/opt/mono'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/home/maarten/script'
OS = `Windows_NT'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PGDATA = `/opt/postgresql/data'
PKG_CONFIG_PATH = `/usr/X11R6/lib/pkgconfig'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 9 Stepping 5, GenuineIntel'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0905'
PROGRAMFILES = `C:\Program Files'
PROMPT = `$P$G'
PS1 = `\[\033]0;\w\007
[EMAIL PROTECTED] \[\033[33m\w\033[0m\]
$ '
SESSIONNAME = `Console'
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINDOWS'
TEMP = `C:\Temp'
TERM = `xterm'
TERMCAP = `xterm-r6|xterm|xterm X11R6 
version:am:km:mi:ms:xn:co#120:it#8:li#43:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:ae=^O:al=\E[L:as=^N:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cr=^M:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:do=^J:ei=\E[4l:ho=\E[H:im=\E[4h:is=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E>:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:kD=\E[3~:kI=\E[2~:kN=\E[6~:kP=\E[5~:kd=\EOB:ke=\E[?1l\E>:kh=\E[1~:kl=\EOD:kr=\EOC:ks=\E[?1h\E=:ku=\EOA:le=^H:md=\E[1m:me=\E[m:mr=\E[7m:nd=\E[C:rc=\E8:sc=\E7:se=

XEmacs 21.4.15, shell-mode not working?

[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
known command. In the 'Tools->Shell' menu, the 'Shell' option is listed, but it
is grayed out.

I installed the following xemacs related packages:
- xemacs
- xemacs-emacs-common
- xemacs-mule-sumo
- xemacs-tags

Anybody knows what could be wrong?

Maarten

__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/