Re: MSVC Support

[Duft Markus]

Hi there!

You may want to have a look at
http://www.sourceforge.net/projects/interix-wgcc which is a MSVC wrapper
i wrote. It feels just like gcc, or at least it should ;o). So far
everything works fine (i'm using interix / SUA, but cygwin port should
be very easy). I'm just about looking into shared libs with libtool
(without they work fine). With the newest libtool realease shared libs
seem to work out of the box somehow, but not perfect... Also i need to
hack Automake to include .dll files in install processes or find some
other way to include them.

All other stuff should work fine with it, and i built numerous packages
(open and close source) with it. (The output is native Win32, without
any dependecies, just like cccl, except that there is a little (only
some Kb's) support library (static) which gets linked, to abstract some
ANSI / ISO differences for C).

You may want to give the latest version a try.

--
Markus Duft
Forschung & Entwicklung
 
Salomon Automation GmbH
A-8114 Friesach bei Graz
 
[EMAIL PROTECTED]


___
http://lists.gnu.org/mailman/listinfo/libtool

AW: libtool + MinGW

[Duft Markus]

Hi!

Do you want to get it to work with the MinGW GCC, or with the MSVC toolchain 
(i.e. cl.exe, link.exe etc...) ? This makes a big difference, since libltdl is 
really useless with the MS toolchain.

I think we allready talked about wgcc, did we? ;o)

Regards, Markus 

-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Brendon Costa
Gesendet: Freitag, 9. Juni 2006 15:58
An: libtool@gnu.org
Betreff: libtool + MinGW

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi All,

As part of my quest to get libtool and MSVC working together, i thought 
i would first get libtool working with an example project on a few other 
systems first. I have created this small example project to test using static 
and shared libraries, DLOpened modules and applications that use all these in 
normal modes + with the -all-static flag.

I am fine with getting it to work on my NetBSD box. I have been trying to get 
it working on my Windows box using MinGW - GCC and libtool 1.5.22.

In this project i am issuing libtool commands through a shell script in order 
to get an understanding of what needs to be done later when i implement some 
jam rules that make use of libtool.

The attached file is a tarball that is a cut down version of the project. It 
should however contain all files needed to run the script successfully. There 
is also a test.sh script that i am using to build this, and a results.txt file 
that shows the results from when i run the tests.sh file.

Basically i cant seem to get dlpreopening to work with GCC. The linking fails 
with multiply defined symbols of libltdl malloc and free functions when i use 
the -all-static option to libtool along with the -dlopen providing the dlopened 
module for preopening (Note i also tried using
- -dlpreopen)

Would someone be able to have a look at the script file and let me know what i 
am doing wrong?

Thanks for the help.
Brendon Costa.


Note: To run the script, extract the tarball, change into the System directory 
where you will find the script tests.sh and execute it.









-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFEiX5iLSWCuZeiyS0RAlJtAKCw+DbXKIZ32hg9iJ17XucTV3VOmwCfaPx3
ly+Sa0k5Y8zL4LTrPLY/m00=
=JuTk
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

AW: libtool + MinGW

[Duft Markus]

Hmmm.. Ok, maybe i'm wrong with this, but at least i'm successfully working 
with about 600mb sources on interix with the ms toolchain with libtool but 
without libltdl, and it works without any problems (static and about 50% shared 
so far)...

Sorry if the statement was wrong ;o)

Regards, markus 

-Ursprüngliche Nachricht-
Von: Ralf Wildenhues [mailto:[EMAIL PROTECTED] 
Gesendet: Montag, 12. Juni 2006 08:28
An: Duft Markus
Cc: Brendon Costa; libtool@gnu.org
Betreff: Re: libtool + MinGW

* Duft Markus wrote on Mon, Jun 12, 2006 at 08:24:00AM CEST:
> 
> Do you want to get it to work with the MinGW GCC, or with the MSVC 
> toolchain (i.e. cl.exe, link.exe etc...) ? This makes a big 
> difference, since libltdl is really useless with the MS toolchain.

This statement isn't true in general.
(Go and search for Peter Ekberg's work on this.)

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Interix Shared Libraries

[Duft Markus]

Hey ho 
;o)
 
To bring some (good) 
news (i think ;o)). I wrote a little compiler wrapper you may have heard of 
-> wgcc (www.sourceforge.net/projects/interix-wgcc) 
which behaves like gcc and uses microsofts toolchain in the background. As of 
0.6.0 the shared library support is quite stable. I also created a little patch 
for libtool 1.5.22 which allows building it shared with wgcc. This works ok for 
now (just some little probs with globals ;o//), and i'm prudktively building 
lots of libraries (about 200 MB Sources => about 4 GB Binaries...) with 
little or no modification (except updating libtool) (many of those sources have 
never seen windows!!).
 
The thing works on 
Interix 3.5, 5.2 and 6.0 (!!) (with the newest config.guess)
 
If anybody is 
interested in this, everything can be found at sourceforge (www.sourceforge.net/projects/interix-wgcc) 
(the patches for libtool too)
 
(if you wonder what ucl and 
ulink are: these are tool for the windows command line which allow linking in 
libraries with unix style names
without having to change the 
command line from cl.exe. Additionally the whole environment gcc would listen to 
is take into account,
and the pxwc library (wgcc) is 
linked in to allow in place path conversion at runtime with 
getenv...)
 
Any feedback would 
be really great!!
 
Regards, 
Markus
___
http://lists.gnu.org/mailman/listinfo/libtool

AW: Interix Shared Libraries

[Duft Markus]

Sure it would be great to see my changes incorporated in libtool! ;o)

I'll give func_win32_libid a try, although i'm not sure (after looking at it) 
if this will really work ;o// we'l see...

For the other hunks i'll generate another patch to make the changes wgcc only, 
and post that patch to sf.net again.

For results with wgcc:

./db/bin/libdb-4.3.so.dll
./glib/bin/libglib-2.0.so.0.800.3.dll
./glib/bin/libgmodule-2.0.so.0.800.3.dll
./glib/bin/libgobject-2.0.so.0.800.3.dll
./glib/bin/libgthread-2.0.so.0.800.3.dll
./interix-rpc/bin/librpc.so.0.0.0.dll
./libiconv/bin/libcharset.so.1.0.0.dll
./libiconv/bin/libiconv.so.2.2.0.dll
./libIDL/bin/libIDL-2.so.0.0.0.dll
./logtool/bin/liblogtool.so.0.0.0.dll
./mico/bin/idl2311.dll
./mico/bin/mico2311.dll
./mico/bin/micocoss2311.dll
./openldap/bin/liblber-2.3.so.0.2.12.dll
./openldap/bin/libldap-2.3.so.0.2.12.dll
./openldap/bin/libldap_r-2.3.so.0.2.12.dll
./openssl/bin/libcrypto.so.dll
./openssl/bin/libssl.so.dll
./ORBit2/bin/libORBit-2.so.0.0.0.dll
./ORBit2/bin/libORBit-imodule-2.so.0.0.0.dll
./ORBit2/bin/libORBitCosNaming-2.so.0.0.0.dll
./ORBit2/lib/bin/Everything_module.so.dll
./popt/bin/libpopt.so.0.0.0.dll
./pthreads-w32/bin/pthreadVC2d.dll
./readline/bin/history5.so.dll
./readline/bin/libhistory.so.dll
./readline/bin/libreadline.so.dll
./readline/bin/readline5.so.dll
./wgcc/bin/libpxwc.so.0.0.0.dll
./zlib/bin/libz.so.1.2.3.dll

All together it's exactly 162 dll's, but the rest is company internal stuff 
;o). Although not all of them
(but all of the above) are built using libtool/wgcc combo, one can see that it 
at least seems to work ;o)

I'll look into other tests, etc.

Regards, Markus

-Ursprüngliche Nachricht-
Von: Ralf Wildenhues [mailto:[EMAIL PROTECTED] 
Gesendet: Dienstag, 4. Juli 2006 13:00
An: Duft Markus
Cc: libtool@gnu.org
Betreff: Re: Interix Shared Libraries

Hello Markus,

* Duft Markus wrote on Tue, Jul 04, 2006 at 08:43:59AM CEST:
>  
> To bring some (good) news (i think ;o)). I wrote a little compiler 
> wrapper you may have heard of -> wgcc
> (www.sourceforge.net/projects/interix-wgcc) which behaves like gcc and 
> uses microsofts toolchain in the background. As of 0.6.0 the shared 
> library support is quite stable. I also created a little patch for 
> libtool 1.5.22 which allows building it shared with wgcc.

Is there interest in getting these changes merged into Libtool?
Support for newer interix major versions is interesting in any case.
Some of your changes look like they break the support for gcc, though, 
especially these are problematic:

| diff -rubB libtool-1.5.22.orig/libtool.m4 libtool-1.5.22/libtool.m4
| --- libtool-1.5.22.orig/libtool.m42006-07-03 07:48:02.0 +0200
| +++ libtool-1.5.22/libtool.m4 2006-07-03 07:49:41.0 +0200
| @@ -2361,7 +2361,8 @@
|  
|  interix*)
|# PIC code is broken on Interix 3.x, that's why |\.a not |_pic\.a 
| here
| -  lt_cv_deplibs_check_method='match_pattern /lib[[^/]]+(\.so|\.a)$'
| +  lt_cv_deplibs_check_method='pass_all'
| +  #lt_cv_deplibs_check_method='match_pattern /lib[[^/]]+(\.so|\.a)$'
|;;
|  
|  irix5* | irix6* | nonstopux*)
| @@ -3245,7 +3246,7 @@
|  _LT_AC_TAGVAR(hardcode_direct, $1)=no
|  _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
|  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
| -_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
| +_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)=''
|  # Hack: On Interix 3.x, we cannot compile PIC because of a broken gcc.
|  # Instead, shared libraries are loaded at an image base (0x1000 by
|  # default) and relocated if they conflict, which is a slow very 
| memory @@ -5542,7 +5543,7 @@
|_LT_AC_TAGVAR(hardcode_direct, $1)=no
|_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
|_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
| -  _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
| +  _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)=''
|# Hack: On Interix 3.x, we cannot compile PIC because of a broken gcc.
|# Instead, shared libraries are loaded at an image base (0x1000 by
|# default) and relocated if they conflict, which is a slow very 
| memory
| 

For the first hunk, you could probably try func_win32_libid (see Cygwin) when 
using wgcc (maybe also with gcc), but you'll have to test that.
The other hunks would probably work when special-cased for wgcc only (does the 
wrapper only handle C or also C++, Fortran, whatnot?).

I'd prefer to see test results for both wgcc and gcc (see README for how to 
report failures) before applying anything, and we'd need a copyright 
disclaimers (details off-list).

Cheers, and thanks for sharing this,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

AW: Interix Shared Libraries

[Duft Markus]

est
PASS: depdemo-exec.test
PASS: depdemo-inst.test
PASS: depdemo-unst.test
PASS: mdemo-conf.test
PASS: mdemo-make.test
PASS: mdemo-exec.test
PASS: mdemo-inst.test
PASS: mdemo-unst.test
PASS: dryrun.test
PASS: demo-nofast.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: demo-inst.test
PASS: demo-unst.test
PASS: demo-pic.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: demo-nopic.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: depdemo-nofast.test
PASS: depdemo-make.test
PASS: depdemo-exec.test
PASS: depdemo-inst.test
PASS: depdemo-unst.test
PASS: cdemo-shared.test
PASS: cdemo-make.test
PASS: cdemo-exec.test
PASS: demo-shared.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: demo-inst.test
FAIL: hardcode.test
PASS: build-relink.test
PASS: noinst-link.test
PASS: demo-unst.test
PASS: depdemo-shared.test
PASS: depdemo-make.test
PASS: depdemo-exec.test
PASS: depdemo-inst.test
PASS: build-relink2.test
PASS: depdemo-unst.test
PASS: mdemo-shared.test
PASS: mdemo-make.test
PASS: mdemo-exec.test
PASS: mdemo-inst.test
PASS: mdemo-unst.test
PASS: assign.test
PASS: link.test
PASS: link-2.test
PASS: nomode.test
PASS: quote.test
PASS: sh.test
PASS: suffix.test
PASS: pdemo-conf.test
PASS: pdemo-make.test
PASS: pdemo-exec.test
PASS: pdemo-inst.test
PASS: mdemo-conf.test
PASS: mdemo-make.test
PASS: mdemo2-conf.test
PASS: mdemo2-make.test
PASS: mdemo2-exec.test
PASS: duplicate_members.test
PASS: link-order.test
PASS: tagdemo-static.test
PASS: tagdemo-make.test
PASS: tagdemo-exec.test
PASS: tagdemo-conf.test
PASS: tagdemo-make.test
PASS: tagdemo-exec.test
PASS: tagdemo-shared.test
PASS: tagdemo-make.test
PASS: tagdemo-exec.test
PASS: f77demo-static.test
PASS: f77demo-make.test
PASS: f77demo-exec.test
PASS: f77demo-conf.test
PASS: f77demo-make.test
PASS: f77demo-exec.test
PASS: f77demo-shared.test
PASS: f77demo-make.test
PASS: f77demo-exec.test

1 of 112 tests failed
Please report to bug-libtool@gnu.org

gmake[2]: *** [check-TESTS] Error 1
gmake[1]: *** [check-am] Error 2
gmake: *** [check-recursive] Error 1

Regards, Markus

-Ursprüngliche Nachricht-
Von: Ralf Wildenhues [mailto:[EMAIL PROTECTED] 
Gesendet: Dienstag, 4. Juli 2006 13:00
An: Duft Markus
Cc: libtool@gnu.org
Betreff: Re: Interix Shared Libraries

Hello Markus,

* Duft Markus wrote on Tue, Jul 04, 2006 at 08:43:59AM CEST:
>  
> To bring some (good) news (i think ;o)). I wrote a little compiler 
> wrapper you may have heard of -> wgcc
> (www.sourceforge.net/projects/interix-wgcc) which behaves like gcc and 
> uses microsofts toolchain in the background. As of 0.6.0 the shared 
> library support is quite stable. I also created a little patch for 
> libtool 1.5.22 which allows building it shared with wgcc.

Is there interest in getting these changes merged into Libtool?
Support for newer interix major versions is interesting in any case.
Some of your changes look like they break the support for gcc, though, 
especially these are problematic:

| diff -rubB libtool-1.5.22.orig/libtool.m4 libtool-1.5.22/libtool.m4
| --- libtool-1.5.22.orig/libtool.m42006-07-03 07:48:02.0 +0200
| +++ libtool-1.5.22/libtool.m4 2006-07-03 07:49:41.0 +0200
| @@ -2361,7 +2361,8 @@
|  
|  interix*)
|# PIC code is broken on Interix 3.x, that's why |\.a not |_pic\.a 
| here
| -  lt_cv_deplibs_check_method='match_pattern /lib[[^/]]+(\.so|\.a)$'
| +  lt_cv_deplibs_check_method='pass_all'
| +  #lt_cv_deplibs_check_method='match_pattern /lib[[^/]]+(\.so|\.a)$'
|;;
|  
|  irix5* | irix6* | nonstopux*)
| @@ -3245,7 +3246,7 @@
|  _LT_AC_TAGVAR(hardcode_direct, $1)=no
|  _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
|  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
| -_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
| +_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)=''
|  # Hack: On Interix 3.x, we cannot compile PIC because of a broken gcc.
|  # Instead, shared libraries are loaded at an image base (0x1000 by
|  # default) and relocated if they conflict, which is a slow very 
| memory @@ -5542,7 +5543,7 @@
|_LT_AC_TAGVAR(hardcode_direct, $1)=no
|_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
|_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
| -  _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
| +  _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)=''
|# Hack: On Interix 3.x, we cannot compile PIC because of a broken gcc.
|# Instead, shared libraries are loaded at an image base (0x1000 by
|# default) and relocated if they conflict, which is a slow very 
| memory
| 

For the first hunk, you could probably try func_win32_libid (see Cygwin) when 
using wgcc (maybe also with gcc), but you'll have to test that.
The other hunks would probably

PATH as runpath_var?

[Duft Markus]

Hi!
 
Just a quick 
question: On windows all the compiled .dll files need to be in the path to be 
found at runtime ($PATH).
Is there some easy 
way of putting paths in there? Like just changing runpath_var to 
PATH??
 
Regards, 
markus
___
http://lists.gnu.org/mailman/listinfo/libtool

Interix, libtool, wgcc

[Duft Markus]

Hey 
all!
 
After some hard 
work, i've released another version of wgcc (see sourceforge, "interix-wgcc") 
which now has some major improvements for shared libraries (and static ones, and 
mixing both types of libraries), it even generates some assembler code on the 
fly while linking. ;o)
 
Now i'd need some 
people who have some spare time to take a look at wgcc and test it a little. I 
so far got nearly no feedback on things working or not, so i can only tell that 
the things i compile myself work... Would be great to know a little 
more.
 
If you are 
interested, just read on the few following lines, i'll explain some 
traps:
 
for global variables 
in shared libraries one has to modify the sources a little. If you have the 
following original sources:
 

==
lib.h:
 
extern int 
variable;
 
 
lib.c:
 
#include 
"lib.h"
int variable = 
10;
==
 
you will have to 
modify that to look something like that to work on all 
platforms:
 
==
lib.h:
 
#if 
defined(_WIN32)
#    
if defined(_COMPILING_lib_)
#    define _lib_EXPORT 
__declspec(dllexport)
#    
else
#    define _lib_EXPORT 
__declspec(dllimport)
#    
endif
#else
#    
define _lib_EXPORT
#endif
 
extern _lib_EXPORT 
int variable;
 
lib.c:
 
#include 
"lib.h"
 
_lib_EXPORT int 
variable = 10;

==
 
just define _COMPILING_lib_ if you're 
compiling the shared library objects, and DON'T worry about static libraries, if 
you need them, they will work with exactly the same sources as shown above, 
since wgcc generates some assembler sources to include all symbols needed for 
this, and somehow fits things together (i not quite sure if _I_ know how it 
works ;o))
 
this should be everything you have to know 
to test things. I just added the import/export defines above myself to 
i-don't-know-how-many files, and my fingers still hurt ;o) but it's worth... and 
it doesn't take too long... ;o)
 
i hope somebody has interest in this, 
otherwise tell me !
 
Regards, 
Markus
___
http://lists.gnu.org/mailman/listinfo/libtool

Recheck Bug??

[Duft Markus]

Hi 
together!
 
seems i found a 
little ... äähmm ... bug(??) ;o) when i do:
 
$ CC=wgcc CXX=wgcc 
LD=wgcc ../libtool-1.5.22/configure 
--prefix=/wamas/libtool/test/binary
 
and after that 
bootstrap libtool, and do "$ gmake" libtool trys to recheck 
with:
 
$ gmake/bin/sh 
./config.status --recheckrunning /bin/sh ../libtool-1.5.22/configure  
--prefix=/wamas/libtool/test/binary CC=wgcc CXX=wgcc 
--enable-ltdl-install  --no-create --no-recursion
 
which isn't too 
good, since LD is not set, and /opt/gcc3.3/blahblah.../ld is used instead of 
wgcc, which breaks everything
 
For now i just 
configure manually which works perfectly, but you know 
;o)
 
Regards, 
Markus
___
http://lists.gnu.org/mailman/listinfo/libtool

Recheck Bug...

[Duft Markus]

Hi!
 
Seems i was wrong 
with the recheck bug. Whenever i reconfigure in a directory where i allready 
configured libtool i get this:
 
rm -f 
ltmain.shTdate=`/bin/sh ../libtool-1.5.22/mkstamp < 
../libtool-1.5.22/ChangeLog` &&  sed -e 's/@''PACKAGE@/libtool/' -e 's/@''VERSION@/1.5.22/'  -e "s%@""[EMAIL PROTECTED]%" 
../libtool-1.5.22/ltmain.in > ltmain.shTmv -f ltmain.shT 
../libtool-1.5.22/ltmain.sh ||  (rm -f ../libtool-1.5.22/ltmain.sh 
&& cp ltmain.shT ../libtool-1.5.22/ltmain.sh && rm -f 
ltmain.shT)cp ../libtool-1.5.22/ltmain.sh 
../libtool-1.5.22/libltdl/configure: error: tag name "CXX" already 
exists
 
h
 
Regards, 
Markus
___
http://lists.gnu.org/mailman/listinfo/libtool

AW: improve support for building DLLs on cygwin and mingw

[Duft Markus]

Hi there!

I implemented wgcc (a compiler wrapper behaving like gcc but calling cl.exe). 
Since the target should be to compile sources with minimum changes i have done 
lot's of work for this. The only thing one has to do with wgcc is:

Define a macro like MYPROG_EXPORT to __declspec(dllexport) when compiling the 
sources, and to __declspec(dllimport) when using the header file from the 
outside (this shouldn't be that hard ;o)) (gets even better in wgcc v2, one 
will not need to export anymore, just import ;o)). This works for shared, and 
(!!) for static libraries, since wgcc generates some symbols. This was one of 
the main problems, that any executeable sources can _never_ know which library 
gets linked statically or shared.

Maybe you want to have a look at it, since its as far as i think a not too bad 
way of doing it...

By the way wgcc is supported by libtool with the wgcc patch which can be found 
@ www.sourceforge.net/projects/interix-wgcc

Cheers, Markus

-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Bruno Haible
Gesendet: Montag, 4. September 2006 13:49
An: libtool@gnu.org
Cc: Charles Wilson; Danny Smith; Filip Navara
Betreff: improve support for building DLLs on cygwin and mingw

Hi,

There are 4 ways to deal with the problem of exported variables when building 
shared libraries on Woe32 platforms. Programmers of shared libraries have to 
choose among them. Two of them I'd consider unacceptable for use in serious 
projects, and among the remaining two ways one is hard to put in place in 
projects that make use of gnulib.

The remaining way appears to be a good compromise between
  - memory use and standards conformance - the resulting DLLs behave like
DLLs built with Microsoft's compiler,
  - efficiency of the generated code - it does not have more indirections than
code compiled with -fPIC on ELF,
  - amount of code changes - the only change to source code is that declarations
of exported variables in header files must be marked as DLL_VARIABLE; no
changes needed for functions,
  - amount of configure / makefile infrastructure - only the DLL_VARIABLE macro
must be defined; its value can be determined in an autoconf macro and is
fixed throughout the compilation.

You find complete details about this approach in
  http://www.haible.de/bruno/woe32dll.html

A prototype of this approach is being used in GNU libiconv-1.11 and GNU 
gettext-0.15.

But currently, libtool lacks about 20 lines of code to make this approach 
actually work.

I'd suggest to add this support to libtool. Details are in the above mentioned 
web page.

I don't suggest to add it to the linker (GNU ld), because I heard rumours that 
libtool shall in the long term also support the Microsoft compiler and linker 
('cl'). Putting the support for this approach into libtool will also make it 
work with 'cl', whereas putting it into GNU ld would not.

Bruno


___
http://lists.gnu.org/mailman/listinfo/libtool


___
http://lists.gnu.org/mailman/listinfo/libtool

AW: improve support for building DLLs on cygwin and mingw

[Duft Markus]

 
No. __declspec(dllimport) tells the compiler that an indirection is
needed. The compiler will simplify '&externvar' to '_imp__externvar'.
There is one _imp__externvar per library, but all their values are the
same.

The "same function name, different address" problem will occur - as far
as I understand it - when you don't use __declspec(dllimport) for
functions.
This is the case when the linker adds trampoline functions looking like:

_externfunc:
jmp *__imp__externfunc

(This case was also a headache in the ELF/IA-64 glibc implementation.)

==

As far as i know this isn't really true for functions. The function
trampolines get generated in the import library on windows (cl) so they
are allways present, even if you don't specify dllimport, and they also
get used allways if they are present at link time. Other than this is
with data, where the trampolines get generated at link time in the
resulting binary image.
This means that for functions there is absolutely no problem exporting
automatically by generating a def file for example (and importing works
automatically), but with data one allways needs the
__declspec(dllimport) for the trampoline to get generated (export can be
done via def file too).

I'm currently writing wgcc v2 which implements all this (only dllimport
for data is needed anymore, all other __declspecs can be omitted, since
all stuff gets generated (a def file, and some .asm code).

Cheers, Markus


___
http://lists.gnu.org/mailman/listinfo/libtool

windows and dlopen

[Duft Markus]

hi 
there!
 
i'm currently 
working on wgcc v2 and the libltdl behaviour on windows. looking at 
mdemo-static.test and co. i have a little problem. since all libs are linked in 
static, the symbols which are looked up are contained in the executeable itself, 
so my idea was to dlopen the executeable, and just treat it as a normal dll. 
This doen't work, since an executeable misses some things a dll has, so i can't 
find _any_ symbol in an executeable image somehow. it just seems to be empty 
;o)
 
any sugestions how 
to get this to work?
 
Cheers, 
Markus
___
http://lists.gnu.org/mailman/listinfo/libtool

wgcc v2 first release

[Duft Markus]

phuu
 
wgcc-2.0-pre.1 
officially released at sourceforge, for those interested. here some 
notes:
 
wgcc-2.0-pre.1: 
brandnew codebase, everthing got better ;o) supports many new things, but whats 
even better, all the old stuff still works as expected... everything just got 
really much more powerfull. All the mess from v-0.x disappeared. pxwc is on by 
default. Build first wgcc then pxwc from the distfile into the _SAME_ prefix, or 
you'll have to manually edit the ${prefix}/etc/.wgccrc file.new is also the 
support for the apache stdcxx library which is a _much_ better implementation 
than the microsoft STL ;o) (the support is just that the configure script checks 
for it, and puts the correct stuff in the configuration; be sure to set 
STDCXX_HOME to the stdcxx prefix, set STDCXX_STD to the build version of the 
release library (for example "15d") and STDCXX_DBG to debug library build name 
(for example 12d) and STDCXX_FLAGS to any required flags like /D_RWSHARED and so 
on _before_ configuring...)
 
Cheers, 
Markus
___
http://lists.gnu.org/mailman/listinfo/libtool

wgcc critical update

[Duft Markus]

hey 
everybody.
 
there was a really 
bad, bad, bad malloc in all 2.0-pre.x versions, which is fixed in 
wgcc-2.0-pre.3. there was one byte missing in the alloc, which caused 
unpredictable behaviour (core dumps) when processing command 
outputs.
 
i.e. when cl.exe 
& co. didn't output anything, everything went ok ;o///
 
if you use one of 
those versions, please upgrade, distfile is @ sourceforge as 
usual...
 
Additionally the 
libtool patch for 2.x is available now on sourceforge too. There are a few tests 
that are now possible with wgcc 2.x, which were impossible to get working with 
1.x. This depends mostly on the new export behaviour, which does NOT export 
variable from external libraries anymore (i.e. each library linked in is private 
to the resulting binary image, which is the best behaviour 
;o))
 
some current test 
results with the sources currently on sourceforge are:
 
PASS: 
cdemo-static.testPASS: cdemo-make.testPASS: cdemo-exec.testPASS: 
demo-static.testPASS: demo-make.testPASS: demo-exec.testPASS: 
demo-inst.testPASS: demo-unst.testPASS: depdemo-static.testPASS: 
depdemo-make.testPASS: depdemo-exec.testPASS: depdemo-inst.testPASS: 
depdemo-unst.testPASS: mdemo-static.testFAIL: mdemo-make.testSKIP: 
mdemo-exec.testSKIP: mdemo-inst.testPASS: mdemo-unst.testPASS: 
cdemo-conf.testPASS: cdemo-make.testPASS: cdemo-exec.testPASS: 
demo-conf.testPASS: demo-make.testPASS: demo-exec.testPASS: 
demo-inst.testPASS: demo-unst.testPASS: deplibs.testPASS: 
depdemo-conf.testPASS: depdemo-make.testPASS: depdemo-exec.testPASS: 
depdemo-inst.testPASS: depdemo-unst.testPASS: mdemo-conf.testFAIL: 
mdemo-make.testSKIP: mdemo-exec.testSKIP: mdemo-inst.testPASS: 
mdemo-unst.testFAIL: dryrun.testPASS: demo-nofast.testPASS: 
demo-make.testPASS: demo-exec.testPASS: demo-inst.testPASS: 
demo-unst.testPASS: demo-pic.testPASS: demo-make.testPASS: 
demo-exec.testPASS: demo-nopic.testPASS: demo-make.testPASS: 
demo-exec.testPASS: depdemo-nofast.testPASS: depdemo-make.testPASS: 
depdemo-exec.testPASS: depdemo-inst.testPASS: depdemo-unst.testPASS: 
cdemo-shared.testPASS: cdemo-make.testPASS: cdemo-exec.testPASS: 
demo-shared.testPASS: demo-make.testPASS: demo-exec.testPASS: 
demo-inst.testFAIL: hardcode.testFAIL: build-relink.testPASS: 
noinst-link.testPASS: demo-unst.testPASS: depdemo-shared.testPASS: 
depdemo-make.testPASS: depdemo-exec.testPASS: depdemo-inst.testFAIL: 
build-relink2.testPASS: depdemo-unst.testPASS: 
mdemo-shared.testFAIL: mdemo-make.testSKIP: mdemo-exec.testSKIP: 
mdemo-inst.testPASS: mdemo-unst.testPASS: assign.testPASS: 
link.testPASS: link-2.testPASS: nomode.testPASS: quote.testPASS: 
sh.testPASS: suffix.testPASS: pdemo-conf.testPASS: 
pdemo-make.testPASS: pdemo-exec.testPASS: pdemo-inst.testPASS: 
mdemo-conf.testFAIL: mdemo-make.testPASS: mdemo2-conf.testSKIP: 
mdemo2-make.testSKIP: mdemo2-exec.testPASS: 
duplicate_members.testFAIL: link-order.testPASS: 
tagdemo-static.testPASS: tagdemo-make.testPASS: 
tagdemo-exec.testPASS: tagdemo-conf.testPASS: tagdemo-make.testPASS: 
tagdemo-exec.testPASS: tagdemo-shared.testPASS: 
tagdemo-make.testPASS: tagdemo-exec.testFAIL: 
f77demo-static.testSKIP: f77demo-make.testSKIP: 
f77demo-exec.testFAIL: f77demo-conf.testSKIP: f77demo-make.testSKIP: 
f77demo-exec.testFAIL: f77demo-shared.testSKIP: 
f77demo-make.testSKIP: 
f77demo-exec.test12 of 98 tests 
failed(14 tests were not run)Please report to bug-libtool@gnu.org
 

all the 
libtool mdemo tests still fail, because there is still a problem with 
dlopen and static libraries, i.e. dlpreopening, because the libtool generated 
symbols conflict with some assembler code that wgcc generates. this will be the 
next thing to work on, so if there is a solution for this, it should be 
available in a few days
 
for the hardcode 
test -> this is simply not possible on windows
for the relink tests 
-> i have really no idea here yet..
 
the test results 
look pretty much better than in version 1.x, except that in v1 building the 
mdemo tests went ok, so there seem to be more fails and skips now, but thats 
really not true, because 1.x failed one step later (i did much patching 
there...) ;o)
 
that the f77 tests 
failed. i think this is ok ;o) wgcc does not know fortran, i forgot to 
disable those tests
 
Cheers, Markus 
Duft
___
http://lists.gnu.org/mailman/listinfo/libtool

wgcc-2.0-pre.7

[Duft Markus]

Hi everybody!
i'm 
proud to announce that wgcc-2.0-pre.7 and it's documentation have been 
released. This version is close to the first RC and is capable of building (with 
little or no modifications) OpenLDAP, OpenSSL, libtool, zlib, Berkeley DB, 
expat, gettext, libiconv, pkgconfig, glib, libIDL, popt, ORBit2, and many 
others. Additionally now the Apache stdcxx project is fully supported. A Patch for GNU Libtool is available to give it 
support for wgcc (the work on this support is finished to about 
80%). For any Questions, feel free to mail me! 
Cheers, Markus
___
http://lists.gnu.org/mailman/listinfo/libtool

wgcc 2.0 RC1 released

[Duft Markus]

Hi 
again!
 
For all interested 
in native Windows binaries built with Autotools and mnay other interesting 
things:
 
wgcc is a cross-compiler tool primarily written for 
Microsoft's Interix. Its primary purpose is to produce native Windows binaries 
(internally using the Microsoft Tool chain), and to mimic the behaviour of the 
GNU compiler collection. This means that wgcc understands many of GCC's command 
line arguments, and in most cases delivers the same results as expected, 
sometimes manipulating the underlying tool's input and output.
 
Even though wgcc was written for Interix only, it 
can be used on native Windows (without Interix), and other Systems, like Cygwin. 
The only restriction is that on Platforms other than Interix, only Windows style 
paths are understood. This will change in the future for Cygwin, and/or others. 
On Interix wgcc automatically converts UNIX style paths to Windows style ones 
(i.e. /wgcc to C:\SFU\wgcc).
 
wgcc abstracts away lots of inconveniences that are 
introduced by building static libraries, shared libraries (DLL's) and 
executables with any possible combination of those three. When using wgcc both 
static and shared libraries behave exactly the same on Windows, and this makes 
tons of defines unnecessary. The only thing that still has to be done is to give 
all Data symbols (i.e. Variables) an import attribute (__declspec(dllimport)) 
when using them (i.e. in the library header files) in an executable. For a 
simple example take a look at the file tests/shared.test inside the wgcc 
distribution.
 
The Release Candidate 1 of wgcc has a completely 
rewritten Configuration File parser, which allows for faster and safer parsing; 
now adding the ability to include empty directives in configuration files. This 
could be something like "paths.c++ =" to unset all C++ search 
directories.
 
Also the ability to automatically generate export 
definitions and import trampolines for mixing static and shared libraries with 
executables has been reviewed and improved. This did not change the behaviour of 
wgcc regarding the 2.0-pre.x versions, but only speeded it up a 
little.
 
pxwc, the accompanying library for wgcc allows 
further abstraction for C code, allowing use of the ANSI function names (i.e. 
without the leading "_"). pxwc currently includes only a small set of functions, 
so your help is needed to find out which others to include. Just open a Feature 
Request at http://sourceforge.net/tracker/?group_id=158081&atid=806407 
and we will try to add functionality as soon as possible.
 
Using the patch provided for GNU Libtool, wgcc can 
be used with many Open Source packages. After patching and installing Libtool, 
simply bootstrap the package in question, configure (set CC, CXX and LD to 
"wgcc") and build. The configure Script should tell that the linker in use is 
the "Interix to Win32 cross linker (wgcc)".
 
Since the version jump to 2.x wgcc now resides in 
the Sourceforge Subversion Repository. The CVS Repository still continues to 
contain previous wgcc versions (0.x).
 
To continue improving wgcc and pxwc packages, we 
now need your help in testing them. Please download wgcc and try to compile you 
software using it. If something goes wrong please contact mduft or open an issue 
using the Sourceforge Tracker at http://sourceforge.net/tracker/?group_id=158081&atid=806404, 
or ask your questions at the forums at http://sourceforge.net/forum/?group_id=158081.
 
You can browse the Subversion Repository here: http://svn.sourceforge.net/viewvc/interix-wgcc/trunks/
 
Documentation can be found here: http://sourceforge.net/project/showfiles.php?group_id=158081&package_id=203917&release_id=446943Source 
Packages can be found here: http://sourceforge.net/project/showfiles.php?group_id=158081&package_id=177049&release_id=445894The 
Patch for Libtool can be found here: http://sourceforge.net/project/showfiles.php?group_id=158081&package_id=196163&release_id=446510
___
http://lists.gnu.org/mailman/listinfo/libtool

AW: [boost] wgcc 2.0 RC1 released

[Duft Markus]

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 debug the output. Gdb on windows (at 
least on interix) is so terribly broken, i could not debug 10 lines of code 
without gdb failing at some point. The visual studio debugger (the 2005 version 
especially) is very very much better. (gdb on cygwin doesn't behave too good 
either. This was the initial reason for wgcc to be written (we are a 300 
programmer company ;o), we need to debug...))

With cygwin the thing is, that cygwin isn't really quite stable on win xp and 
above when using more than one CPU. I don't know how MinGW behaves there.

The second thing is, that resulting executables depend on msvcrt.lib and are 
therefore binary compatible with nearly everything ;o) on windows. When using 
gcc it has it's own libc (on interix gcc is a interix build, and has really not 
much to do with windows ;o//) and one can't link those things together, so 
in gcc built binaries one can _not_ use the win32 API which, on windows, is not 
really desireable.

The last thing is, that tools such as Rational Purify may be used to examine 
the resulting binaries. It's all just really native ;o)

At the moment as i wrote in my release note only Interix is supported, since 
this is also stable on win xp and above with multiple processors. But using 
cygwin as a build environment only, using wgcc as compiler is possible too, i'd 
just need to implement one method, about 5 lines of code, to convert paths from 
unix <-> windows style.

I hope this is an answer to your questions!

I'm really overwhelmed that someone outside my company finally shows at least 
_some_ interest. It's really cool, give it a try!

Cheers, Markus

-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von David Abrahams
Gesendet: Dienstag, 19. September 2006 16:07
An: boost@lists.boost.org
Cc: libtool@gnu.org
Betreff: Re: [boost] 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 thread, one obvious 
question leaps to mind: why would anyone want to use wgcc in lieu of Cygwin or 
MinGW gcc?

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


___
http://lists.gnu.org/mailman/listinfo/libtool

AW: wgcc 2.0 RC1 released

[Duft Markus]

Hm, really i started out porting from unix to windows using cccl, but it took 
not too long to realize that cccl is far to less powerfull. Cccl is capable of 
translating some command line options, not really much more. This doesn't mean 
cccl is bad. If one doesn't need more than this, its perfect. Wgcc is just 
_more_ and more powerfull.

Cccl has, i don't know, say 200 lines of shell script code?
Wgcc has about 10.000 lines of c++ code (9305).

It does a little more than just wrapping around the command line. It has many 
benefits over comparable wrappers like cccl, c89 (interix) and wcc (interix, 
see interopsystems.com) which are all shell scripts just wrapping some 
arguments.

You may want to take a look at the docs for rc.1. there is a section about 
building libraries with wgcc which may be of interest regarding this question...

Cheers, Markus

-Ursprüngliche Nachricht-
Von: Albert Chin [mailto:[EMAIL PROTECTED] 
Gesendet: Dienstag, 19. September 2006 17:03
An: Duft Markus
Cc: libtool@gnu.org
Betreff: Re: wgcc 2.0 RC1 released

On Tue, Sep 19, 2006 at 11:05:25AM +0200, Duft Markus wrote:
>  
> For all interested in native Windows binaries built with Autotools and 
> mnay other interesting things:
>  
> wgcc is a cross-compiler tool primarily written for Microsoft's 
> Interix. Its primary purpose is to produce native Windows binaries 
> (internally using the Microsoft Tool chain), and to mimic the 
> behaviour of the GNU compiler collection. This means that wgcc 
> understands many of GCC's command line arguments, and in most cases 
> delivers the same results as expected, sometimes manipulating the 
> underlying tool's input and output.

So, with this tool, someone doesn't need the cccl Visual C++ wrapper:
  http://cccl.sourceforge.net/

--
albert chin ([EMAIL PROTECTED])


___
http://lists.gnu.org/mailman/listinfo/libtool

RE: [boost] wgcc 2.0 RC1 released

[Duft Markus]

All i can talk of is my experience using interix, since i didn't use
cygwin that much. Cygwin was more or less dead at out company when i
came in. The yhad too much problems with the cygwin builds. Some of the
problems are, that the w32api for cygwin and mingw is not the *real*
w32api, but some own thing they built. I really don't know how this
w32api behaves, or if it has any drawbacks.
As for gdb, the version that comes with interix 3.5 is from
i-don't-know-when (seems like year 2k or something), so many years old.
Maybe newer versions would work better. Debugging C code is not a
problem, everything works fine there, but never try to debug C++, you'll
get 10 lines far or so (until first using a STL string.) ;o)
As of the import/export problems with MS, wgcc really does a lot in this
direction, one can say most of it's code is just for those problems. And
i think it manages to push things in the right direction. One has to
_only_ put __declspec(dllimport) in place where needed, and that _only_
for Data symbols. There is no need to differenciate static and shared
libraries, just put the import everywhere ;o) wgcc manages the rest.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Brendon Costa
Sent: Wednesday, September 20, 2006 10:43 AM
To: David Abrahams
Cc: boost@lists.boost.org; libtool@gnu.org
Subject: Re: [boost] wgcc 2.0 RC1 released

David Abrahams wrote:
> "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 debug 
>> the output. Gdb on windows (at least on interix) is so terribly 
>> broken, i could not debug 10 lines of code without gdb failing at 
>> some point.
> 
> Works great for me under Cygwin, especially through emacs.

Code may not be faster. It really depends on the implementation of the
compiler. The differences would be negligible from my understanding,
though with more resources MS may be able to optimise some things in
their compiler... I don't know.

I do prefer the MS debugger, but my experience with GDB is that it also
works fine in windows (Under Cygwin and with MSYS/MinGW) and achieves
its purpose well enough (I guess not using emacs is part of my problem
:-) as it seems a little more clunky to use having to type in all these
breakpoints... I need a GUI frontend for GDB i think...)


>> The second thing is, that resulting executables depend on msvcrt.lib 
>> and are therefore binary compatible with nearly everything ;o) on 
>> windows.
> 
> That's also true of MinGW, right?

Yes. MinGW depends on msvcrt.lib


>> When using gcc it has it's own libc (on interix gcc is a interix 
>> build, and has really not much to do with windows ;o//) and one 
>> can't link those things together, so in gcc built binaries one can 
>> _not_ use the win32 API which, on windows, is not really desireable.
> 
> Huh?  Not so; I have used the win32 API even through cygwin GCC.
> And then there's gcc -mno-cygwin.

Yep. There is a win32api library for cygwin. Same as MinGW really with
-mno-cygwin i think...

>> The last thing is, that tools such as Rational Purify may be used to 
>> examine the resulting binaries. It's all just really native ;o)
>>
>> I'm really overwhelmed that someone outside my company finally shows 
>> at least _some_ interest. It's really cool, give it a try!
> 
> Not sure what I'm missing here, but at this point I don't see why I 
> should bother.  The existing tools work for me and are 
> well-established, with good support.
> 

One possible reason I can think of is that in the non-free world...
Sometimes a company might distribute a C++ library + some header files
(Without any source code). I have encountered this before. Since the ABI
is not the same between MSVC and MinGW/GCC it forces you to use the
compiler they have created the libraries using (Unless it is a pure C
interface) and if you have a desire to use the autotools build framework
(autoconf/automake/libtool) then this could be useful.

Having a wrapper for MSVC that behaves like gcc would mean that you can
use the autotools (A particulary important part of it is libtool for
this discussion) build framework with the MSVC compiler. This may be
beneficial in some situations instead of using the MSVC build
environment.


I tried cccl a while ago and shortly discovered a HEAP of issues
especially trying to compile things using libtool. So i went and started
my own shell script wrapper that improved on cccl. It got a fair way but
i was not willing to put more time into it and 

RE: AW: boost ?!

[Duft Markus]

The initial reason for writing wgcc was, that we have tons and tons of unix 
software in-house, and need to port them to windows. We have our own build and 
distribution mechanism, and use much of autotools and libtool as well. To not 
break everything, i wrote wgcc, so that we are able to (under interix) use our 
mechanisms and the autotools on windows as well (even without the need to 
change makefiles much).
Some simple changes are allways required ;o) thats because of the really 
different concepts between compilers.

Of course i'd like wgcc to understand as m uch as possible! I'd love to see 
stdcxx built with wgcc by the way. But at the moment i have not really enough 
time to look into it. Don't know how much changes this would need.

Cheers, Markus

-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, September 20, 2006 11:02 PM
To: stdcxx-dev@incubator.apache.org
Subject: Re: AW: boost ?!

Duft Markus wrote:
> OMG, i'm so blind.. I messed up 12d and 15d, maybe those should get other 
> names ;o) now it's all clear why it can't work

Yes, container iterators have different types between debug and optimized 
builds, with std::string and std::vector being plain pointers for efficiency. 
This makes the two kinds of builds incompatible with one another.

> 
> Anyway thanks for your time, and sorry for messing around in here!

No problem. Glad you got it worked out.

Martin

PS I haven't played with wgcc too much yet but I like the concept.
In fact, I've been thinking about writing a similar tool for some time, one 
that would provide a uniform interface to all compilers (i.e., the same set of 
compiler options across all). Have you considered enhancing wgcc in this way?

> 
> Cheers, Markus
> 
> -Ursprüngliche Nachricht-
> Von: Duft Markus [mailto:[EMAIL PROTECTED]
> Gesendet: Dienstag, 19. September 2006 09:37
> An: stdcxx-dev@incubator.apache.org
> Betreff: AW: boost ?!
> 
> Hm, the struct thing was completely wrong, sorry
> 
> Ok, i just digged a little into this:
> 
> For example one of the unresolved symbols is:
> 
> [EMAIL PROTECTED]@[EMAIL PROTECTED]@std@@[EMAIL PROTECTED]@2@@s
> td@@QAEPADXZ
> 
> Which would be:
> 
> __declspec(dllimport) public: char * __thiscall 
> std::basic_string,class 
> std::allocator >::begin(void)
> 
> The Stdcxx library has symbols some symbols which are close:
> 
> [EMAIL PROTECTED]@[EMAIL PROTECTED]@std@@[EMAIL PROTECTED]@2@@s
> td@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@std@@V?$
> [EMAIL PROTECTED]@2@@std@@[EMAIL PROTECTED]@@XZ
> 
> Which would be:
> 
> __imp_public: class __rw::__rw_debug_iter std::basic_string,class 
> std::allocator >,char *,char *> __thiscall 
> std::basic_string,class 
> std::allocator >::begin(void)
> 
> I now think that somehow there is a problem with the headers thinking they 
> need to compile debug iterators (in build 15d!?) and when using the lib, they 
> think something else ;o// i looked at my config.h but there was nothing i 
> could see in there. I attached it, maybe you can see something.
> 
> Cheers, Markus
> 
> -Ursprüngliche Nachricht-
> Von: Martin Sebor [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 18. September 2006 17:34
> An: stdcxx-dev@incubator.apache.org
> Betreff: Re: boost ?!
> 
> Duft Markus wrote:
> 
>>Hey again!
>> 
>>I'm currently fighting to get boost compiled with stdcxx... ;o) It 
>>seems, that boost uses both char and wchar_t versions of methods from 
>>stdcxx, which at least seems to compile, but cannot link, since there 
>>is no wchar_t impl in the stdlib15d.lib/.dll. Now my question is: can 
>>i somehow use 15d and 15D together on windows, so that both kind of 
>>symbols are present?
> 
> 
> The difference between 15d and 15D is that the first is a 32-bit build type 
> (ILP32) while the second is a 64-bit or wide one (LLP64 on Windows). The 
> "wide" has nothing to do with wchar_t, it refers to the width of the data 
> type(s).
> 
> Stdcxx has full support for wchar_t as long as the compiler supports it. Keep 
> in mind that the MSVC /Zc:wchar_t option changes the type and mangling of 
> wchar_t and thus is a binary incompatible option.
> Programs that link with the library must be compiled with same setting of the 
> option as the library (i.e., both on or both off).
> 
> See http://msdn2.microsoft.com/en-us/library/dh8che7s.aspx
> 
> 
>>And there seem to be some differences from windows STL to this one in 
>>which files get included automatically from other includes and so on, 
>>since i need to explicitly include some files for some things to work 
>>(like std::hex and std::dec are not found, ex

Wgcc 2.0 RC2 released.

[Duft Markus]

wgcc is a cross-compiler tool primarily written for Microsoft's Interix.
Its primary purpose is to produce native Windows binaries (internally
using the Microsoft Tool chain), and to mimic the behaviour of the GNU
compiler collection. This means that wgcc understands many of GCC's
command line arguments, and in most cases delivers the same results as
expected, sometimes manipulating the underlying tool's input and output.

Even though wgcc was written for Interix only, it can be used on native
Windows (without Interix), and other Systems, like Cygwin. The only
restriction is that on Platforms other than Interix, only Windows style
paths are understood. This will change in the future for Cygwin, and/or
others. On Interix wgcc automatically converts UNIX style paths to
Windows style ones (i.e. /wgcc to C:\SFU\wgcc).

wgcc abstracts away lots of inconveniences that are introduced by
building static libraries, shared libraries (DLL's) and executables with
any possible combination of those three. When using wgcc both static and
shared libraries behave exactly the same on Windows, and this makes tons
of defines unnecessary. The only thing that still has to be done is to
give all Data symbols (i.e. Variables) an import attribute
(__declspec(dllimport)) when using them (i.e. in the library header
files) in an executable. For a simple example take a look at the file
tests/shared.test inside the wgcc distribution.

The Release Candidate 2 of wgcc is more or less a bug fix release
compared to RC1. There is not too much new. Bug fixes include a nearly
complete rewrite of the Import Trampoline gererator and the Export
Definition generator, since those two worked very bad for C, but only
for C++.

pxwc has been reviewed and changed a little, to not include that many
defines, where inlined static functions are possible. Still pxwc
currently includes only a small set of functions, so your help is needed
to find out which others to include. Just open a Feature Request at
http://sourceforge.net/tracker/?group_id=158081&atid=806407 and we will
try to add functionality as soon as possible.

To continue improving wgcc and pxwc packages, we now need your help in
testing them. Please download wgcc and try to compile your software
using it. If something goes wrong please contact mduft or open an issue
using the Sourceforge Tracker at
http://sourceforge.net/tracker/?group_id=158081&atid=806404, or ask your
questions at the forums at
http://sourceforge.net/forum/?group_id=158081.

You can browse the Subversion Repository here:
http://svn.sourceforge.net/viewvc/interix-wgcc/trunks/

Documentation can be found here:
http://sourceforge.net/project/showfiles.php?group_id=158081&package_id=
203917&release_id=446943
Source Packages can be found here:
http://sourceforge.net/project/showfiles.php?group_id=158081&package_id=
177049&release_id=445894
The Patch for Libtool can be found here:
http://sourceforge.net/project/showfiles.php?group_id=158081&package_id=
196163&release_id=446510

Cheers, Markus


___
http://lists.gnu.org/mailman/listinfo/libtool

Dlpreopen on windows

[Duft Markus]

Hey together ;o)

I again played a little with dlpreopening on windows (with wgcc). Now i
again know why it didn't work ;o)

Libtool generates a symbol table on the fly which it then compiles and
links in, correct?
That symbols table contains both .text and .data symbols. There is no
problem with .text symbols so far ;o)
As i saw the nmS file uses a one letter prefix to identify the type
of symbol. My mdemo.nmS for exmaple has three types:

 T  .text i think, so all functions
 B  .bss (??) i think, initialized data
 C  .data (??) uninitialized data?

Please correct me if i'm wrong ;o). Now on windows, it would be cool
(and neccessary) to know if a symbol comes from a shared library (since
i then need to import it.). The extern definition of data symbols should
have a __declspec(dllimport) where apropriate. With wgcc it would be a
little easier, since wgcc automatically generates the "__imp_" pointers
(needed for __declspec(dllimport) to work) for all static libraries too,
so one would not have to differentiate (but this would *only* work for
wgcc then...).

I now changed libtool a little (quick and dirty hack ;o) to be:

global_symbol_to_cdecl="awk '{ if(\$1 != \"T\") { print \"extern
__declspec\(dllimport\) int \" \$3 \";\" } else { print  "extern int \"
\$3 \";\" } }'"

This puts another problem into place: this does *not* compile with the
microsoft compiler *except* when using C++. For that reason i added the
-xc++ option to the compiler command.

Now i ran mdemo test ok with wgcc ;o)

Any thoughts on this?

Cheers, Markus

P.S.: the windows compiler does not define data symbols in object files
if they are not referenced at least once in that object file. So the
libtool mdemo/foo(1|2).c nothing variable is missing in the objects
unless i initialize them with something (0 in my case...).


___
http://lists.gnu.org/mailman/listinfo/libtool

FW: [wgcc-dev] Dlpreopen on windows

[Duft Markus]

Hey together ;o)

I again played a little with dlpreopening on windows (with wgcc). Now i
again know why it didn't work ;o)

Libtool generates a symbol table on the fly which it then compiles and
links in, correct?
That symbols table contains both .text and .data symbols. There is no
problem with .text symbols so far ;o) As i saw the nmS file uses a
one letter prefix to identify the type of symbol. My mdemo.nmS for
exmaple has three types:

 T  .text i think, so all functions
 B  .bss (??) i think, initialized data
 C  .data (??) uninitialized data?

Please correct me if i'm wrong ;o). Now on windows, it would be cool
(and neccessary) to know if a symbol comes from a shared library (since
i then need to import it.). The extern definition of data symbols should
have a __declspec(dllimport) where apropriate. With wgcc it would be a
little easier, since wgcc automatically generates the "__imp_" pointers
(needed for __declspec(dllimport) to work) for all static libraries too,
so one would not have to differentiate (but this would *only* work for
wgcc then...).

I now changed libtool a little (quick and dirty hack ;o) to be:

global_symbol_to_cdecl="awk '{ if(\$1 != \"T\") { print \"extern
__declspec\(dllimport\) int \" \$3 \";\" } else { print  "extern int \"
\$3 \";\" } }'"

This puts another problem into place: this does *not* compile with the
microsoft compiler *except* when using C++. For that reason i added the
-xc++ option to the compiler command.

Now i ran mdemo test ok with wgcc ;o)

Any thoughts on this?

Cheers, Markus

P.S.: the windows compiler does not define data symbols in object files
if they are not referenced at least once in that object file. So the
libtool mdemo/foo(1|2).c nothing variable is missing in the objects
unless i initialize them with something (0 in my case...).


___
http://lists.gnu.org/mailman/listinfo/libtool

Wgcc status report

[Duft Markus]

Hey again!

Wgcc status report ;o) (this is rc4 with libtool patch from today):

PASS: cdemo-static.test
PASS: cdemo-make.test
PASS: cdemo-exec.test
PASS: demo-static.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: demo-inst.test
PASS: demo-unst.test
PASS: depdemo-static.test
PASS: depdemo-make.test
PASS: depdemo-exec.test
PASS: depdemo-inst.test
PASS: depdemo-unst.test
PASS: mdemo-static.test
PASS: mdemo-make.test
PASS: mdemo-exec.test
PASS: mdemo-inst.test
PASS: mdemo-unst.test
PASS: cdemo-conf.test
PASS: cdemo-make.test
PASS: cdemo-exec.test
PASS: demo-conf.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: demo-inst.test
PASS: demo-unst.test
PASS: deplibs.test
PASS: depdemo-conf.test
PASS: depdemo-make.test
PASS: depdemo-exec.test
PASS: depdemo-inst.test
PASS: depdemo-unst.test
PASS: mdemo-conf.test
PASS: mdemo-make.test
PASS: mdemo-exec.test
PASS: mdemo-inst.test
PASS: mdemo-unst.test
PASS: dryrun.test
PASS: demo-nofast.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: demo-inst.test
PASS: demo-unst.test
PASS: demo-pic.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: demo-nopic.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: depdemo-nofast.test
PASS: depdemo-make.test
PASS: depdemo-exec.test
PASS: depdemo-inst.test
PASS: depdemo-unst.test
PASS: cdemo-shared.test
PASS: cdemo-make.test
PASS: cdemo-exec.test
PASS: demo-shared.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: demo-inst.test
SKIP: hardcode.test
FAIL: build-relink.test
PASS: noinst-link.test
PASS: demo-unst.test
PASS: depdemo-shared.test
PASS: depdemo-make.test
PASS: depdemo-exec.test
PASS: depdemo-inst.test
FAIL: build-relink2.test
PASS: depdemo-unst.test
PASS: mdemo-shared.test
PASS: mdemo-make.test
PASS: mdemo-exec.test
PASS: mdemo-inst.test
PASS: mdemo-unst.test
PASS: assign.test
PASS: link.test
PASS: link-2.test
PASS: nomode.test
PASS: quote.test
PASS: sh.test
PASS: suffix.test
PASS: pdemo-conf.test
PASS: pdemo-make.test
PASS: pdemo-exec.test
PASS: pdemo-inst.test
PASS: mdemo-conf.test
PASS: mdemo-make.test
PASS: mdemo2-conf.test
PASS: mdemo2-make.test
FAIL: mdemo2-exec.test
PASS: duplicate_members.test
PASS: link-order.test
PASS: tagdemo-static.test
PASS: tagdemo-make.test
PASS: tagdemo-exec.test
PASS: tagdemo-conf.test
PASS: tagdemo-make.test
PASS: tagdemo-exec.test
PASS: tagdemo-shared.test
PASS: tagdemo-make.test
PASS: tagdemo-exec.test

3 of 102 tests failed
(1 tests were not run)
Please report to bug-libtool@gnu.org


This looks *very* cool ;o) For the tests failed: hardcode will never
work, thats clear (fails with gcc too). The other three, i really have
no idea there. Mdemo2 fails only half, as far as i've seen the static
version executes OK. I think the error is, that libltld allways tries to
dlopen the static library, not the shared one, but i can't figure it out
(i hate dlpreopening ;o)) (and i can't read my own changed code
anymore... *argl* ;o))

I also tested gcc, to see if my changes influenced it somehow. Only
hardcode.test failed, and thats ok (it does without my patch too) ;o).

I now changed the hardcode.test to skip on all interix platforms for
now.

Cheers, Markus


libtool-1.5.22-wgcc-2.x-26-09-2006.patch
Description: libtool-1.5.22-wgcc-2.x-26-09-2006.patch
___
http://lists.gnu.org/mailman/listinfo/libtool

Hardcoding paths.

[Duft Markus]

Hi again!

With wgcc (again ;o)) i now tell libtool, that hardcoding is
"unsupported". Configure tells this too now, so everything seems to be
ok. But when i run hardcode.test:

= Searching for hardcoded library directories in each program
.libs was not hardcoded in `hc-direct', as libtool expected
.libs was not hardcoded in `hc-libflag', which fooled libtool
.libs was not hardcoded in `hc-libpath', as libtool expected
.libs was not hardcoded in `hc-minusL', as libtool expected
FAIL: hardcode.test

Err... When hardcoding is unsupported, why the ... Does libtool expect
hardcoded paths? Libtool looks like this:

hardcode_action=unsupported
hardcode_into_libs=yes
hardcode_libdir_flag_spec="\${wl}-rpath,\$libdir"
hardcode_libdir_flag_spec_ld=""
hardcode_libdir_separator=""
hardcode_direct=no
hardcode_minus_L=no
hardcode_shlibpath_var=no
hardcode_automatic=no

I know i will set hardcode_into_libs to no in the future, but i don't
think this is the reason, or could this be?

Cheers, markus


___
http://lists.gnu.org/mailman/listinfo/libtool

New libtool patch for new wgcc.

[Duft Markus]

Hey together!

For all interested in this, i released a new patch for libtool 1.5.22 to
work with the current wgcc. Both is brandnew and can be found on
sourceforge.
Current wgcc version is 2.0.1 and the patch has the date 27.09.2006.

This fixes some minor things and makes things a little cleaner ... There
are still four tests failing:

FAIL: hardcode.test
FAIL: build-relink.test
FAIL: build-relink2.test
FAIL: mdemo2-exec.test

Note that the mdemo tests (dlpreopening) now work ;o) only mdemo2 has a
problem with the shared part of the test *argl*... ;o)

Ralf: could you have a look at the patch (if you have time) and tell me
if there is still something to fix before you can integrate the patch? I
have currently no time to port the patch to cvs libtool.

Cheers, Markus


___
http://lists.gnu.org/mailman/listinfo/libtool

Wgcc 2.0.2 released.

[Duft Markus]

wgcc is a cross-compiler tool primarily written for Microsoft's Interix.
Its primary purpose is to produce native Windows binaries (internally
using the Microsoft Tool chain), and to mimic the behaviour of the GNU
compiler collection. This means that wgcc understands many of GCC's
command line arguments, and in most cases delivers the same results as
expected, sometimes manipulating the underlying tool's input and output.

Even though wgcc was written for Interix only, it can be used on native
Windows (without Interix), and other Systems, like Cygwin. The only
restriction is that on Platforms other than Interix, only Windows style
paths are understood. With the release of version 2.0.1 this changed.
Now Cygwin too is able to convert paths correctly. On Interix (and now
Cygwin) wgcc automatically converts UNIX style paths to Windows style
ones (i.e. /wgcc to C:\SFU\wgcc).

wgcc abstracts away lots of inconveniences that are introduced by
building static libraries, shared libraries (DLL's) and executables with
any possible combination of those three. When using wgcc both static and
shared libraries behave exactly the same on Windows, and this makes tons
of defines unnecessary. The only thing that still has to be done is to
give all Data symbols (i.e. Variables) an import attribute
(__declspec(dllimport)) when using them (i.e. in the library header
files) in an executable. For a simple example take a look at the file
tests/shared.test inside the wgcc distribution.

In release 2.0.2 there are again some big changes: wgcc now recognizes
debug information in object files built using Visual C++ 2005. In this
version Microsoft does not output line number information anymore, on
which wgcc relied. The handling of Directories (Include directories,
Library directories) has been fixed. There was a small bug when
validating a directory. In version 2.0.1 .wgccrc defined _DEBUG in debug
builds. This is not the case anymore, now the pxwc.h header file defines
_DEBUG whenever using the pxwc memory profiler (PXWC_MEMORY_PROFILER is
defined). The context dump behaviour in verbose output has been fixed.
In version 2.0.1 the context was only dumped when all tasks succeeded.
Now the context gets dumped anyway, regardless of compilation success.
As of 2.0.2 the expand-paths feature is enabled by default in .wgccrc.

The handling of preprocessed files was improved in 2.0.2. In earlier
versions wgcc treated preprocessed sources the same as any other source
file, which is wrong, since the library-header header file (normally
pxwc.h) was included twice.

Since 2.0.2 wgcc is known to work with ccache and distcc, which brings
great performance improvements in some cases, an For d allows for
distirbuted compilation over networks. For more information on how to
build and use those two packages, feel free to contact mduft.

Since a few days, http://interix-wgcc.sf.net is finally online. It's
only a very small page, so that there is not an empty directory listing
anymore. Additionally while designing the web page, a new logo was
created, which can be seen on the homepage and the documentation front
page.

The pxwc library stayed mostly the same, except that it now provides a
"sleep" function. As written above, pxwc.h now defines _DEBUG whenever
PXWC_MEMORY_PROFILER is defined. This should be the only case when one
needs the debug runtime from Microsoft.

To continue improving wgcc and pxwc packages, we now need your help in
testing them. Please download wgcc and try to compile your software
using it. If something goes wrong please contact mduft or open an issue
using the Sourceforge Tracker at
http://sourceforge.net/tracker/?group_id=158081&atid=806404, or ask your
questions at the forums at
http://sourceforge.net/forum/?group_id=158081.

You can browse the Subversion Repository here:
http://svn.sourceforge.net/viewvc/interix-wgcc/trunks/

Documentation can be found here:
http://sourceforge.net/project/showfiles.php?group_id=158081&package_id=
203917&release_id=446943
Source Packages can be found here:
http://sourceforge.net/project/showfiles.php?group_id=158081&package_id=
177049&release_id=445894
The Patch for Libtool can be found here:
http://sourceforge.net/project/showfiles.php?group_id=158081&package_id=
196163&release_id=446510


___
http://lists.gnu.org/mailman/listinfo/libtool

RE: Absolute paths generated by libtool.

[Duft Markus]

Hey!

You may want to look at www.sf.net/projects/interix-wgcc. If using
interix is an alternative for you, i think wgcc is a cool tool (which,
of course, i wrote ;o)). Using interix is good in any case, because it
is more stable and faster than cygwin. Additionally cygwin does not
correctly work on SMP machines with win2k or higher.

It has the great benefit that it creates native windows executables with
cl.exe (not a gcc build) and therefore produces binaries that are
debuggable with visual studio. The new version thats about to be
released even supports full gcc3-style dependency tracking!

There is a libtool patch available that makes libtool work together with
wgcc (libtool-1.5.22) and wgcc passes nearly all tests (3 fail or
so)

@Ralf: the patch has been tested on: i586-pc-interix3/5,
hppa2.0w-hp-hpux11.11, i386-pc-solaris2.10, i686-pc-linux-gnu,
powerpc-ibm-aix5.2.0.0, ia64-hp-hpux11.23, sparc-sun-solaris2.9. On
interix with wgcc and gcc, on all others with gcc and some with native
compilers too. I think ist mature enough to be integrated somehow, would
this be ok?

If you have questions, you're welcome to ask!

Cheers, Markus

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Benoit Sigoure
Sent: Tuesday, November 14, 2006 5:35 PM
To: libtool@gnu.org
Cc: [EMAIL PROTECTED]
Subject: Absolute paths generated by libtool.

Hello folks.

I'm developing Qt-based applications. The build system is controlled by
the autotools rather than by Qmake.

I'm porting our projects on Windows. We're using an automated build
system
(buildbot.sf.net) to build every commit on Linux/OSX/Windows. Automating
the process on Windows proved to be really annoying. I looked at how
other projects do it (Python, KDE, Subversion etc.) they all seem to use
hand written .bat files and/or Makefile.vc (for Visual C++) with nmake
and co. I didn't want to deal with special Makefiles or setting up a
special build system for each project, so I tried to do something more
generic.

Things are rather complicated but I'll try to explain them here.
Everything might not be relevant to the problem described below but I
suppose you people have a good experience about porting applications so
you might be able to advise me.

First off, I chose to use a Cygwin environment for the buildfarm. This
was convenient since Cygwin comes with lots of packages (python, vim,
zsh etc) and make it easy to have a complete environment on the Windows
machine. The buildbot (which is a python app) runs in that environment.

Qt distributes Windows binaries for mingw only so I ended up installing
mingw. This entails that everything is built by the mingw-gcc toolchain
rather than by the cygwin-gcc. Anyway, I *guess* that building mingw
apps in a Cygwin environment isn't a problem since there is probably not
much differences between both.

However, doing this made me run into several problems. For instance, Qt
generates Makefiles that have rules such as:
C:\Foo\Bar: C:\Baz\Qux
Which is a problem for cygwin's GNU make (since it sees "C" as a
target). For some reason the mingw GNU make has no problem with this
kind of rule, I guess they patched it. Nevermind, let's use mingw GNU
make. The problem is that when make runs commands such as
C:\Qt\4.2.1\bin\moc.exe, the backslashes are interpreted by the shell
(cygwin's shell) which leads to the execution of the command
C:Qt4.2.1binmoc.exe. I tried to use MSYS's shell (the shell provided
with mingw) or cmd.exe directly but this wouldn't work (for some reason
it always ended up running C:Qt4.2.1binmoc.exe).

My idea was to write a perl script and to invoke make SHELL=my_shell.pl.
That script would rewrite the command properly so that it works within
the Cygwin environment. I succeeded and I can now run configure scripts
and compile my projects using that shell-wrapper.
In order to make this automatic and transparent, I have ~/bin first in
my PATH and I wrote a shell script named make.exe there that forwards
the invocation of make to mingw's GNU make with the SHELL variable set.

However, on last problem remains, and that's where libtool comes in.
MingW applications don't know anything about the cygwin environment,
they're not aware of the pseudo filesystem emulated by cygwin. At the
end of the compilation, libtool is invoked to link the final executable
but for some reason, it transforms a relative path in an absolute one:

'C:/cygwin/bin/perl' -w C:/cygwin/home/build/bin/my_shell.pl ../libtool
--tag=CXX   --mode=link g++ -O2 -O2 -frtti -fexceptions -Wall -DUNICODE
-DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_NO_DEBUG -DQT_XML_LIB -DQT_GUI_LIB
-DQT_CORE_LIB -DQT_THREAD_SUPPORT -DQT_NEEDS_QMAIN -Wall -W
-Wold-style-cast -Woverloaded-virtual -pipe -g -O2 -lqscintilla2
-mthreads -Wl,-enable-stdcall-fixup -Wl,-enable-auto-import
-Wl,-enable-runtime-pseudo-reloc -Wl,-s -Wl,-s -Wl,-subsystem,windows
-o
urbidev.exe [MANY.o] -L"c:\Qt\4.2.1\lib" -lmingw32 -lqtmain -lQtXml4
-lQtGui4
-lQtCore4 ../behavio

RE: Absolute paths generated by libtool.

[Duft Markus]

We could talk about it if you would be able to talk like a grown up... 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Brian Dessent
Sent: Wednesday, November 15, 2006 8:17 AM
To: libtool@gnu.org
Subject: Re: Absolute paths generated by libtool.

Duft Markus wrote:

> Additionally cygwin does not
> correctly work on SMP machines with win2k or higher.

Need a shovel for that FUD you're slinging?


___
http://lists.gnu.org/mailman/listinfo/libtool


___
http://lists.gnu.org/mailman/listinfo/libtool

wgcc 2.0.5 released

[Duft Markus]

I am very proud to announce the release 2.0.5 of wgcc. Maybe there is
some interest. It is a very much improved version compared to the
previous ones. List of changes below.

Cheers, Markus

wgcc is a cross-compiler tool primarily written for Microsoft's Interix.
Its primary purpose is to produce native Windows binaries (internally
using the Microsoft Tool chain), and to mimic the behaviour of the GNU
compiler collection. This means that wgcc understands many of GCC's
command line arguments, and in most cases delivers the same results as
expected, sometimes manipulating the underlying tool's input and output.

Even though wgcc was written for Interix only, it can be used on native
Windows (without Interix), and other Systems, like Cygwin. The only
restriction is that on Platforms other than Interix, only Windows style
paths are understood. With the release of version 2.0.1 this changed.
Now Cygwin too is able to convert paths correctly. On Interix (and now
Cygwin) wgcc automatically converts UNIX style paths to Windows style
ones (i.e. /wgcc to C:\SFU\wgcc).

wgcc abstracts away lots of inconveniences that are introduced by
building static libraries, shared libraries (DLL's) and executables with
any possible combination of those three. When using wgcc both static and
shared libraries behave exactly the same on Windows, and this makes tons
of defines unnecessary. The only thing that still has to be done is to
give all Data symbols (i.e. Variables) an import attribute
(__declspec(dllimport)) when using them (i.e. in the library header
files) in an executable. For a simple example take a look at the file
tests/shared.test inside the wgcc distribution.

This release includes some really big, heavy and *cool* new things:
Instead if the very slow and memory intensive dumpbin.exe, wgcc now
includes a little library (libcoff) that does all the object and library
reading. This increases linking performance by about the factor three.
Additionally when used in a really big link, wgcc does not anymore need
up to 800 MB memory, but now uses constant low amounts like 5 to 10 MB.
There was a spelling error in the default .wgccrc file.
"no-import-filter" should have been "import-filter". This feature now
should work again.
All the warnings from dependency tracking have been move to level s3
(verbose). So Dependency tracking is quiet now.
Configuration files are now loaded in a slightly different way. The old
behaviour was to check a number of locations, and load each (!) file, if
it was there. The new one checks the same locations, but then only loads
the one (!) file that takes the highest precedence. The only exception
is, that configuration files that are specified with the "-config"
option get loaded over any already loaded file. Also the rules for file
lookup have been changed. Now first the Environment variable WGCC_CONFIG
is checked for a configuration file path, then the current directory,
then the "etc" directory in the wgcc prefix, then the directory where
wgcc resides.
The ln utility was broken in the last release, this has been fixed.
The order of include directories was fixed, and now the options from the
command line take precedence over any directories from the environment.
Some tools that may generate parts of the command line that is passed to
wgcc may include "\r" since win32 executables are used in this
processes. Wgcc now handles such things, and does not warn anymore,
about being unable to match an empty option.
Microsoft's compiler v8 uses 64bit time_t's by default (even on 32bit
systems, wgcc does not yet support 64bit). Wgcc provides the option to
revert to 32bit time_t's (which is the wgcc default) by setting the
"32bit-time_t" configuration directive.
The very time consuming runtime indicator checks may now be (and are by
default) disabled to speed up linking in shared libraries. However if
you plan to use the memory profiling feature from pxwc, you should
enable this option (using the "search-indicator" configuration
directive).
Some simple profiling has been implemented which takes times of the main
tasks. This is only available when building wgcc with gcc, not when
using the native win32 build with Visual Studio. To see the output, set
the debug level to s3. Future versions may include a separate debug
level to only include profiling output.
The "-static" option has been fixed in this release to behave like the
gcc counterpart, which refuses to link in shared libraries.

To continue improving wgcc and pxwc packages, we now need your help in
testing them. Please download wgcc and try to compile your software
using it. If something goes wrong please contact mduft or open an issue
using the Sourceforge Tracker at
http://sourceforge.net/tracker/?group_id=158081&atid=806404, or ask your
questions at the forums at
http://sourceforge.net/forum/?group_id=158081.

You can browse the Subversion Repository here:
http://svn.sourceforge.net/viewvc/interix-wgcc/trunks/

Documentation can be found here:
http

RE: Support for VC++ toolchain (was Re: Absolute paths generatedbylibtool.)

[Duft Markus]

Hi!

If you could tell me how i can bring outlook to do so, i will gladly ;o)
otherwise it would be too much work to hand-quote everything! ;o//

No, i didn't receive your mail, something went wrong there, could you
send it again?? I will be glad to help you ;o)

Yes wgcc would convert the path (even on cygwin this should work!). (i
didn't build wgcc on cygwin a while, but it should work!) Path
conversion and argument conversion is one of the strengths of wgcc ;o)

The configure script for wgcc does search for visual studio (it must be
in PATH). On interix simply globally (system settings) set
INTERIX_COMPILERDIR to C:\vcxx8 and this will do (interix does the rest,
not wgcc there) (for cygwin see below). Wgcc's configure looks for the
compiler and follows a (very simple :o)) rule to find include and lib
directories. Sometimes this doesnt work correctly, but you can edit the
paths in ${prefix}/etc/.wgccrc (see manual -> paths.c, paths.c++,
paths.linker).

The configure check assumes (for now) a full visual studio setup with
platformsdk in the VC dir, not an express edition with extra
platformsdk, so you will have to edit .wgccrc.

On cygwin when i last experimented with it for everything to work i had
to do the following (from a clean environment):

CYGWIN todo:


set TMPDIR to /tmp

extend PATH with AT LEAST the following:
/VC/bin:
/Common7/IDE:
/Common7/Tools:
/Common7/Tools/Bin:
/VC/PlatformSDK/Bin:
/cygdrive/c/Windows/system32



Hope this helps!

Cheers, Markus

-Original Message-
From: Benoit Sigoure [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 28, 2006 3:43 PM
To: Duft Markus
Cc: libtool@gnu.org
Subject: RE: Support for VC++ toolchain (was Re: Absolute paths
generatedbylibtool.)

Quoting Duft Markus <[EMAIL PROTECTED]>:
> Hi!

Hi, please answer below the quote :(
http://en.wikipedia.org/wiki/Top-posting

>
> Hmmm, what do you mean with "wgcc doesn't set the environment"? It's 
> true, wgcc doesn't, but why should it?? The thing is, that wgcc should

> be the only one to run cl.exe, and he knows how... Am i missing 
> something?
>
> Could be, that wgcc doesn't work that good under cygwin yet, since the

> primary platform is interix... ;o)

You can't run cl.exe unless you have the right environment variables
set.
According to my install of Visual C++ Express (under C:\vcxx8) these
are:

export VSINSTALLDIR='C:\vcxx8'
export VCINSTALLDIR='C:\vcxx8\VC'
export FrameworkDir='C:\WINDOWS\Microsoft.NET\Framework'
export FrameworkVersion='v2.0.50727'
export FrameworkSDKDir='C:\vcxx8\SDK\v2.0'
export DevEnvDir='C:\vcxx8\Common7\IDE'
export
PATH='C:\vcxx8\Common7\IDE;C:\vcxx8\VC\BIN;C:\vcxx8\Common7\Tools;C:\vcx
x8\SDK\v2.0\bin;C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;C:\vcxx8\V
C\VCPackages;c:\vcxx8\VC\PlatformSDK'
export INCLUDE='C:\vcxx8\VC\INCLUDE;c:\vcxx8\VC\PlatformSDK\Include;'
export
LIB='C:\vcxx8\VC\LIB;C:\vcxx8\SDK\v2.0\lib;c:\vcxx8\VC\PlatformSDK\Lib;'
export LIBPATH='C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727'

Notice that in the above PATH and INCLUD and LIB, I added MS Platform
SDK's stuff.

The MS Platform SDK adds the following:
export MSSdk='c:\vcxx8\VC\PlatformSDK'
export Bkoffice='c:\vcxx8\VC\PlatformSDK'
export INETSDK='c:\vcxx8\VC\PlatformSDK'
export Mstools='c:\vcxx8\VC\PlatformSDK'

>
> On interix wgcc does all the conversion from unix to windows. One can 
> work just as if using gcc under linux or elsewhere... And one *does 
> not* need to worry about environments or conversions or anything, 
> *and* libtool works just fine ;o)

So you're telling me that wgcc would transform a -I/home/build/include
in /IC:\cygwin\home\build\include ?

(by the way, I sent you an email a couple of days ago because I had a
problem with wgcc, did you receive it?)

Cheers,

>
> Cheers, Markus
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Benoit Sigoure
> Sent: Tuesday, November 28, 2006 2:14 PM
> To: libtool@gnu.org
> Subject: Re: Support for VC++ toolchain (was Re: Absolute paths 
> generatedby libtool.)
>
> Quoting Howard Chu <[EMAIL PROTECTED]>:
>> Benoit Sigoure wrote:
>>> Quoting Benoit Sigoure <[EMAIL PROTECTED]>:
>>>> [SNIP, see
>>>> http://lists.gnu.org/archive/html/libtool/2006-11/msg00018.html]
>>>>
>>>
>>> Hello folks,
>>> I think I finally succeeded: I can now build any UNIX program as 
>>> long
>
>>> as its code is portable on Windows with both mingw-gcc toolchain and
> MS VC++.
>>
>> Wow, what a lot of effort, when you could have simply installed MSYS 
>> and the cccl shell scri

RE: Support for VC++ toolchain (was Re: Absolute paths generatedby libtool.)

[Duft Markus]

Hi!

Hmmm, what do you mean with "wgcc doesn't set the environment"? It's
true, wgcc doesn't, but why should it?? The thing is, that wgcc should
be the only one to run cl.exe, and he knows how... Am i missing
something?

Could be, that wgcc doesn't work that good under cygwin yet, since the
primary platform is interix... ;o)

On interix wgcc does all the conversion from unix to windows. One can
work just as if using gcc under linux or elsewhere... And one *does not*
need to worry about environments or conversions or anything, *and*
libtool works just fine ;o)

Cheers, Markus 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Benoit Sigoure
Sent: Tuesday, November 28, 2006 2:14 PM
To: libtool@gnu.org
Subject: Re: Support for VC++ toolchain (was Re: Absolute paths
generatedby libtool.)

Quoting Howard Chu <[EMAIL PROTECTED]>:
> Benoit Sigoure wrote:
>> Quoting Benoit Sigoure <[EMAIL PROTECTED]>:
>>> [SNIP, see 
>>> http://lists.gnu.org/archive/html/libtool/2006-11/msg00018.html]
>>>
>>
>> Hello folks,
>> I think I finally succeeded: I can now build any UNIX program as long

>> as its code is portable on Windows with both mingw-gcc toolchain and
MS VC++.
>
> Wow, what a lot of effort, when you could have simply installed MSYS 
> and the cccl shell script. I guess you would still need to intercept 
> DOS-style commands like del and xcopy, but the MSYS shell takes care 
> of command line arguments and paths, and cccl takes care of 
> translating Unix cc options to switches that MSVC understands. With 
> these I can use an unmodified libtool script to build most autoconf'd 
> packages on Windows.
>

No sorry, this was necessary. MSYS isn't enough, and using it wouldn't
have enabled me to do what I do now. The shell still removes unecessary
backslashes and MSYS can't automagically handles things such as:
gcc -I/home/build/... (which needs to be rewritten in
-IC:/cygwin/home/build/...) for instance.
cccl helps but is rather incomplete compared to wgcc. Moreover, neither
wgcc nor cccl set the proper environment variables to be able to run
cl.exe (which returns 53 if any of them is wrong, eg if the PATH isn't
;-separated or contains forward slashes instead of backslashes etc...)
and to use MS PlateformSDK.

--
SIGOURE Benoit aka Tsuna
   _
  /EPITA\ Promo 2008, LRDE



___
http://lists.gnu.org/mailman/listinfo/libtool


___
http://lists.gnu.org/mailman/listinfo/libtool

wgcc 2.1.0 released

[Duft Markus]

Hi together!

I'm proud to announce the 2.1.0 "stabilizing release" of wgcc. For more
info read below.

Cheers, Markus
==

wgcc is a cross-compiler tool primarily written for Microsoft's Interix.
Its primary purpose is to produce native Windows binaries (internally
using the Microsoft Tool chain), and to mimic the behaviour of the GNU
compiler collection. This means that wgcc understands many of GCC's
command line arguments, and in most cases delivers the same results as
expected, sometimes manipulating the underlying tool's input and output.

Even though wgcc was written for Interix only, it can be used on native
Windows (without Interix), and other Systems, like Cygwin. The only
restriction is that on Platforms other than Interix, only Windows style
paths are understood. With the release of version 2.0.1 this changed.
Now Cygwin too is able to convert paths correctly. On Interix (and now
Cygwin) wgcc automatically converts UNIX style paths to Windows style
ones (i.e. /wgcc to C:\SFU\wgcc).

wgcc abstracts away lots of inconveniences that are introduced by
building static libraries, shared libraries (DLL's) and executables with
any possible combination of those three. When using wgcc both static and
shared libraries behave exactly the same on Windows, and this makes tons
of defines unnecessary. The only thing that still has to be done is to
give all Data symbols (i.e. Variables) an import attribute
(__declspec(dllimport)) when using them (i.e. in the library header
files) in an executable. For a simple example take a look at the file
tests/shared.test inside the wgcc distribution.

Teh 2.1.0 release of wgcc is a "stabilizing" release, means that there
are not many new features, but the existing code has been improved.
Since there was some feedback from 2.0.5 (finally) i could find some
memory leaks and performance hits. Especially the performance of the
2.1.0 release has been improved a lot (by about factor 2 to 3, means
it's up to three times faster).
This release of wgcc has a fairly small memory footprint which should be
in most cases under 10 MB. Also if the configuration is tweaked a little
(turn dependency tracking off) wgcc takes just between 70 and 150 ms (!)
for all its work (excluding external tasks like the compiler). This time
was taken while compiling with a fairly long command line under full (90
- 100%) CPU load.

Libtool has been removed from the wgcc and ucl packages, since it would
be an overhead. This only means that building wgcc is a little faster
now, and has no influence on the libtool patches shipped from the wgcc
page.

To continue improving wgcc and pxwc packages, we now need your help in
testing them. Please download wgcc and try to compile your software
using it. If something goes wrong please contact mduft or open an issue
using the Sourceforge Tracker at
http://sourceforge.net/tracker/?group_id=158081&atid=806404, or ask your
questions at the forums at
http://sourceforge.net/forum/?group_id=158081.

You can browse the Subversion Repository here:
http://svn.sourceforge.net/viewvc/interix-wgcc/trunks/

Documentation can be found here:
http://sourceforge.net/project/showfiles.php?group_id=158081&package_id=
203917&release_id=446943
Source Packages can be found here:
http://sourceforge.net/project/showfiles.php?group_id=158081&package_id=
177049&release_id=445894
The Patch for Libtool can be found here:
http://sourceforge.net/project/showfiles.php?group_id=158081&package_id=
196163&release_id=446510
The PXWC library can be found here:
http://sourceforge.net/project/showfiles.php?group_id=158081&package_id=
195309&release_id=449425


___
http://lists.gnu.org/mailman/listinfo/libtool

Wgcc critical bugfix!

[Duft Markus]

Hi!

The yesterday-released version of wgcc (2.1.0) has a critical bug,
making it crash whenever you pass certain options (like -O2) to it. This
has been fixed in 2.1.1 which is available now from SF.net.

Cheers, Markus


___
http://lists.gnu.org/mailman/listinfo/libtool

Libtool HEAD testsuite

[Duft Markus]

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

RE: Libtool HEAD testsuite

[Duft Markus]

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

RE: windows static archive, missing symbols

[Duft Markus]

Howard Chu <> wrote:
> 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. 

Hi!

There is a solution to this problem, but for now it is only present in
interix-wgcc, which uses cl.exe and not gcc/ld. The solution is, to make
a wrapper generate symbols whenusing static libraries, to make the
linker think it is a shared library... Works perfectly ;o)

Cheers, Markus



___
http://lists.gnu.org/mailman/listinfo/libtool

Problem with post(un)install cmds

[Duft Markus]

Hi!

I wrote the following two for libtool 1.5.22 and they worked perfectly.
Now i just copied them over to libtool 2.1a (CVS HEAD), and it doesn't
seem to work (the directory structure is the same, so this is ok...). I
believe that there is a difference in how libtool executes these code
snippets, is this correct?? If yes, how can i adapt this, so it works
with  libtool 2?

postinstall_cmds='base_file=`basename \${file}`~
dlpath=`$SHELL 2>&1 -c '\''. $dir/'\''\${base_file}'\''i;echo
\$dlname'\''`~
dldir=$destdir/`dirname \$dlpath` ~
set dummy `ls -l $dir/\$dlname*.dll` ~
while test -n "\${3}" ; do shift; done ~
dllname=`basename ${2}` ~
test -d \${dldir}/../bin || mkdir -p \${dldir}/../bin ~
$install_prog $dir/$dllname \$dldir/../bin/$dllname ~
chmod a+x \$dldir/../bin/$dllname'

postuninstall_cmds='dlpath=`$SHELL 2>&1 -c '\''. $file; echo
\$dlname'\''`~
set dummy `ls -l $dir/../bin/\$dlname*.dll` ~
while test -n "\${3}" ; do shift; done ~
$rm ${2}'


Thanks in Advance,
Cheers, Markus


___
http://lists.gnu.org/mailman/listinfo/libtool

RE: Libtool HEAD testsuite

[Duft Markus]

Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote:
> Hello Markus,
> 
> * Duft Markus wrote on Fri, Jan 19, 2007 at 05:28:41PM CET:
>> 
>> Sorry, i must correct myself. $EXEEXT *is* used *sometimes* and as
>> far as my situation is concerned, completely in the wrong places...
> 
> Well, it matches the Cygwin semantics of .exe interpolation:
> <http://cygwin.com/cygwin-ug-net/using-specialnames.html#id4729824>.
> 
> The other missing bit of data is that on Cygwin and MinGW, a C wrapper
> foo/tagdemo.exe for foo/.libs/tagdemo.exe is also created in addition
> to the shell wrapper foo/tagdemo.
> 
> You don't describe your situation sufficiently well for somebody
> else to do anything about it.  Do you use Cygwin, MinGW, or Interix?
> Native or cross-compile + simulator?  What semantics does the system
> in question have wrt. suffix interpolation?  Find out about those
> semantics and post the link to its documentation.  How come you don't
> post the actual verbose test failure output, so we could see which
> tests have the problem?
> 

The compiler i use is WGCC (still @ sourceforge ;o)) which i wrote
myself. The sematics for executable extensions are configurable, which
means one can set the default output filename in a configuration file.
The current default set by me is a.exe (like gcc...). It was a.out, but
that cause lots and lots of troubles with windows ;o// i will look
further into porting my patches to Interix/WGCC.

>> I don't claim to have found a solution for this, but at least for
>> now, and for me i got a workaround
> 
> Which you didn't post either (as a patch).  :-(
> 

The workaround is to remove $EXEEXT from all the test files and
therefore patch defs.in to check for both files, one with and one
without exe extension. I know thet this is probably not a really good
solution (i attached the patch...). I didn't look at all tests by now,
so there may be others still having EXEEXT in them. I additionally don't
know if i can use $EXEEXT or @EXEEXT@ on defs.m4sh so i for now just
hardcoded the .exe...

Cheers, Markus

> Cheers,
> Ralf



test-suite.patch
Description: test-suite.patch
___
http://lists.gnu.org/mailman/listinfo/libtool

RE: Libtool HEAD testsuite

[Duft Markus]

Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote:
> * Duft Markus wrote on Tue, Jan 30, 2007 at 09:02:24AM CET:
>> Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote:
>>> * Duft Markus wrote on Fri, Jan 19, 2007 at 05:28:41PM CET:
>>>> 
>>>> Sorry, i must correct myself. $EXEEXT *is* used *sometimes* and as
>>>> far as my situation is concerned, completely in the wrong places...
>>> 
>>> Well, it matches the Cygwin semantics of .exe interpolation:
>>> <http://cygwin.com/cygwin-ug-net/using-specialnames.html#id4729824>.
>>> [...] You don't describe your situation sufficiently well for
>>> somebody else to do anything about it.  Do you use Cygwin, MinGW,
>>> or Interix? Native or cross-compile + simulator?  What semantics
>>> does the system in question have wrt. suffix interpolation?
> 
> With the above question ...
> 
>> The compiler i use is WGCC (still @ sourceforge ;o)) which i wrote
>> myself. The sematics for executable extensions are configurable,
>> which means one can set the default output filename in a
>> configuration file. 
> 
> ... I meant the system (shell, libc), rather than the compiler here.
> Your compiler isn't going to try to execute those files.

Hi,

It's Interix's libc (kind of a pure POSIX implementation, which does not
know any windows paths or extensions). The shells in use are:
/bin/sh -> /bin/ksh which seems to be one or another version of PDKSH,
and a self built BASH (built with gcc 3.3 from interix. Both don't pay
attention to any extension so no matter where, the name(s) given must be
exact on interix.

The thing is, that there is a trick to make KSH recognize extensions
somehow, but it never worked for me. Additionally it would require some
special setup of the PATH variable, which i think is not very portable,
not even between different interix machines ;o//.

> 
> So, the question still stands: which system fails to execute
>   ./foo
> 
> if there is an executable foo.exe in the current directory?  Since
> apparently I don't know it, and apparently it's not Cygwin nor MinGW,
> I'd like to see documentation for it, so I can fix the ChangeLog entry
> below.

I digged into this again a little... The problem is that there could be
any shell in use that compiles on interix, not just ksh...
For example a CSH comes along with interix (ok, ok, it's not used for
script execution, that's still ksh... ;o))

FROM MAN KSH ON INTERIX
=

  PATH_WINDOWS

The Interix profile file sets the PATH_WINDOWS environment variable
in
which you can specify a suffix matching order. This is used to look
for
Windows commands with standard extensions, namely .com, .exe, .ksh,
.bat,
and .cmd. In the Interix Korn shell, if you type the echo
$PATH_WINDOWS
command, you will see the default value of PATH_WINDOWS set to the
following (or something similar):

 
/dev/fs/C/WINDOWS/system32/.com,.exe,.ksh,.bat,.cmd,:/dev/fs/C/SFU/commo
n/
.com,.exe,.ksh,.bat,.cmd,

The path name is in POSIX format, not Win32.

You can also specify your own suffix matching order. The value of
PATH_WINDOWS is a colon-separated list of directory names with the
following format:

pathname[/suffix-list][:pathname[/suffix-list]]

The suffix-list is a comma-separated list of suffixes. Each suffix
starts
with a period (.) and contains up to a total of three additional
characters, as illustrated in this example:

 
PATH_WINDOWS=/dev/fs/D/SFU/common/.exe,.ksh:/dev/fs/C/WINNT/system32/
.exe,.bat

In this example, .exe and .ksh files will be suffix matched in the
/dev/
fs/D/SFU/common directory, and .exe and .bat files in the
/dev/fs/C/WINNT/
system32 directory. A file with the .exe extension will be matched
in the
/dev/fs/C/WINNT/system32 directory only if it is not found in the
/dev/fs/
D/SFU/common directory.

If you specify only the directory, such as
PATH_WINDOWS=/dev/fs/C/WINNT/
system32 all the suffixes are matched in the following order:

* .com
* .exe
* .ksh
* .bat
* .cmd
* ""

The last example in the list is empty. This indicates the lack of a
suffix. For example, you can enter the following at an Interix shell
prompt:

PATH_WINDOWS=/dev/fs/C/WINNT/system32:/dev/fs/D/sfu/common/.exe
echo $PATH_WINDOWS

The echo $PATH_WINDOWS command displays:

 
/dev/fs/C/WINNT/system32/.com,.exe,.ksh,.bat,.cmd,:/dev/fs/D/SFU/common/
.exe

Note that the empty field between .cmd and : indicates that there is
a "no
suffix" entry in the search path.

FROM MAN KSH ON INTERIX
=

Again, this is for KSH, and not

Windows C++ support impossible?

[Duft Markus]

Hi again!

While thinking about the C++ support on windows, i stumbled over a
problem i had with WGCC a while ago. C++ mangled names are not valid C
identifiers. This doesn't sound too bad, but it really is. Since they
are not valid identifiers, one cannot generate a C-source file that
contains such symbols (for example fo rthe preloaded symbol table that
libtool generates...).

Wgcc solves this, by simply generating assembler source files, where the
mangled names are valid identifiers...
Still i don't think thats an option for libtool there, since the
generated assembler sources have some restrictions (which don't matter
with the wgcc generated source, and of course apply to microsoft's
assembler ml.exe)

* identifier may only be 247 characters long at maximum
* lines may only be 512 charcters long at maximum.

This is somehow *bad* because when using C++, and templates in special
one runs into this very quickly.

Are there any opinions on this. Should i simply say, that this libtool
feature is not available with wgcc/windows? This would mean, that i
would have to somehow disable *all* code generation in libtool... Are
their an objections against this?

P.S.: all this really only applies to C++, C works allready in most
cases ;o)

Cheers, Markus


___
http://lists.gnu.org/mailman/listinfo/libtool

RE: Windows C++ support impossible?

[Duft Markus]

Howard Chu <> wrote:
> Duft Markus wrote:
>> Are there any opinions on this. Should i simply say, that this
>> libtool feature is not available with wgcc/windows? This would mean,
>> that i would have to somehow disable *all* code generation in
>> libtool... Are their an objections against this?
>> 
> 
> That's probably OK in the short term. In the longer term, I think you
> could supply a tool with wgcc that generates the preloaded symbol
> table. Generating a valid object file that simply contains external
> symbol references is not a big deal, you can code that up without
> using a full assembler.

Yes, i think adding a tool for this would be OK. Still i'm asking myself
if it's realistic that on windows somebody is using this at all. With
our company for example there are just a few and very simple use-cases
for windows builds, that is just plain shared libraries, no magic stuff
or anything that is not supported by windows / the compiler anyways...
The only reason for enabling this on windows would be saving lines to
port to the windows platform (if dlpreload is used somewhere), correct
me if i'm wrong.

Cheers, Markus

>> P.S.: all this really only applies to C++,
> 
>>  C works allready in most
>> cases ;o)
>> 
> 
> Such a truism...



___
http://lists.gnu.org/mailman/listinfo/libtool

RE: Support for VC++ toolchain (was Re: Absolute pathsgeneratedbylibtool.)

[Duft Markus]

Olly Betts <> wrote:
> On 2006-11-28, Duft Markus <[EMAIL PROTECTED]> wrote:
>> If you could tell me how i can bring outlook to do so, i will gladly
>> ;o) 
> 
> Off-topic, but in the interests of improving the readability of this
> list (and others!):
> 
> Outlook:
> 
> http://home.in.tum.de/~jain/software/outlook-quotefix/

I'm using this, since late 2006 (since after this post), but Thanks
anyways!

Cheers, Markus

> 
> Outlook Express:
> 
> http://home.in.tum.de/~jain/software/oe-quotefix/
> 
> Or sign up for a gmail account - it handles lists pretty well.
> 
> Cheers,
> Olly
> 
> 
> 
> ___
> http://lists.gnu.org/mailman/listinfo/libtool



___
http://lists.gnu.org/mailman/listinfo/libtool

Relinking on windows

[Duft Markus]

Hi together!

I have a question regarding relinking on windows (while installing).
Everytime a library/exe is installed it is relinked, which costs tons of
time.

After thinking about the problem of having to relink (i assume because
of changing runpaths?) i realized that a Makefile target (pointing to
the installed binary) would solve the problem by checking timestamps (at
least i think so), but nobody is able to create the target;
automake/autoconf don't know anything about libtool, and libtool is not
able of creating makefile targets, correct so far?

Now on windows with wgcc >= 2.2.0 i support hardcoding paths too, so i'd
need relinking. But: i have autility wchrpath shipped with wgcc (same as
chrpath on linux) which is able to change the runpath of a binary
without relinking, and this would be *much* faster.

Is there any way to echange relinking with wchrpath? Maybe by simply
setting relink_cmd to wchrpath somewhere? This would also greatly
increase performance on Linux / maybe other Unix's...

Cheers, Markus

-- 
Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz



___
http://lists.gnu.org/mailman/listinfo/libtool

Possible bug regarding exeext

[Duft Markus]

Hi!

I believe i found a bug regarding exeext in libtool. When generating the
tag configuration to the "libtool" script there is a line:

exeext="$exeext"

Which seems wrong, since nowhere ever $exeext is set. When changing
$exeext to $ac_exeext everything works fine, and the final libtool
script has ".exe" in it as i'd expect.

Cheers, markus

-- 


Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz




___
http://lists.gnu.org/mailman/listinfo/libtool

Question about shlibpath_overrides_runpath / relinking

[Duft Markus]

Hi together!

I have a question about relinking. I'm porting libtool 1.5.24 to a
compiler which uses microsoft's cl.exe in the background. I have all
libtool tests passing right now.

Still i feel, that relinking should not be neccessary with my compiler
(it supports hardcoding correctly, LD_LIBRARY_PATH is my shlibpath_var,
and it is looked at after the hardcoded runpath to find libraries), it
just eats up a lot of time. Now, Settings shlibpath_overrides_runpath to
yes results in everything working fine, except the
build-relink[2].test(s), which now both fail, since libtool is able to
detect the false setting for shlibpath_overrides_runpath.

Is there any other way to tell libtool, that it should not relink, which
does not break anything else.

Thanks in advance,
Cheers, Markus

-- 


Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz




___
http://lists.gnu.org/mailman/listinfo/libtool

RE: Question about shlibpath_overrides_runpath / relinking

[Duft Markus]

Ralf Wildenhues <> wrote:
> Hello Markus,
> 
> * Duft Markus wrote on Mon, Oct 01, 2007 at 01:55:55PM CEST:
>> 
>> Still i feel, that relinking should not be neccessary with my
>> compiler [...] Is there any other way to tell libtool, that it
>> should not relink, which does not break anything else.
> 
> AFAIR we fixed that in CVS HEAD, for MinGW/MSYS.  No, I'm sorry I
> don't remember exactly, but grepping ChangeLog entries, the change
> on 2004-10-12 sounds like it could do the trick.

Hi!

Thanks for the answer, but i can't find an entry with the date
2004-10-12 in libtool-1.5.24's ChangeLogs, maybe it's only in HEAD?
Since i don't currently wan't HEAD to come into play, i guess that means
relinking, or some hack in ltmain.in for my compiler

Thanks anyway,
Markus

> 
> Hope that helps.
> 
> Cheers,
> Ralf
> 
> 
> ___
> http://lists.gnu.org/mailman/listinfo/libtool



___
http://lists.gnu.org/mailman/listinfo/libtool

Relinking issue

[Duft Markus]

Hi!

I'm again having issues with relinking: I have
shlibpath_overrides_runpath set to yes (which is really true now for my
compiler), which effectively prevents relinking, but only of libraries.

Somehow executables are still relinked, and i just can't find the place
where this happens. Something in the back of my mind tells me that it
has something to do with the lt-${name} executables, could this be
correct?

In my last port of libtool, i simply removed the lt- from the program
name and as far as i remember this solved the issue. Still i think this
is not correct.

Cheers, Markus

-- 
4.-5. Oktober 2007
Salomon Automation am Meraner Forum fur Familienunternehmen

17.-19. Oktober 2007
Salomon Automation am 24. Deutschen Logistik-Kongress der BVL, Berlin; Stand 
W/09

14. November 2007
Salomon Automation an der LogIT Retail im Leopoldsmuseum in Wien



Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz



___
http://lists.gnu.org/mailman/listinfo/libtool

RE: Relinking issue

[Duft Markus]

Sorry, forget this post, i found out that it is still relinking
libraries too...

Cheers, Markus

Duft Markus <> wrote:
> Hi!
> 
> I'm again having issues with relinking: I have
> shlibpath_overrides_runpath set to yes (which is really true now for
> my compiler), which effectively prevents relinking, but only of
> libraries. 
> 
> Somehow executables are still relinked, and i just can't find the
> place where this happens. Something in the back of my mind tells me
> that it has something to do with the lt-${name} executables, could
> this be correct?
> 
> In my last port of libtool, i simply removed the lt- from the program
> name and as far as i remember this solved the issue. Still i think
> this is not correct.
> 
> Cheers, Markus


-- 
4.-5. Oktober 2007
Salomon Automation am Meraner Forum fur Familienunternehmen

17.-19. Oktober 2007
Salomon Automation am 24. Deutschen Logistik-Kongress der BVL, Berlin; Stand 
W/09

14. November 2007
Salomon Automation an der LogIT Retail im Leopoldsmuseum in Wien



Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz



___
http://lists.gnu.org/mailman/listinfo/libtool

RE: Relinking issue

[Duft Markus]

Hi Ralf!

>> Somehow executables are still relinked, and i just can't find the
>> place where this happens. Something in the back of my mind tells me
>> that it has something to do with the lt-${name} executables, could
>> this be correct?
> 
> It's the other way round: because relinking is done, the
> .libs/lt-$name executable files are created.

Ah, i see. This time i left this part alone ;o) So libtool may do
whatever it has to do...

> 
>> In my last port of libtool, i simply removed the lt- from the program
>> name and as far as i remember this solved the issue. Still i think
>> this is not correct.
> 
> No, that's merely bugging around the symptoms.  If you want to
> backport the real fix from CVS HEAD to branch-1-5, then I suggest you
> go and look up the patch that fixed the issue in HEAD, and any
> changes that it depends on.  Sorry that I don't have the resources to
> do so, but if I were you, I would either simply base upon CVS HEAD,
> or go look up the changes through CVS or the viewcvs web interface,
> and corresponding discussions in the mailing list archives if any.

Yes, i think the same about that hack ;o) I now got everything right by
adding a few lines to ltmain.in regarding the
shlibpath_overrides_runpath variable. I've attached the whole patch i
made for my compiler (namely parity). If anybody could have a quick look
at it i would be glad, otherwise it doesn't break my heart ;o)

I have only access to a very limited amount of different machines,
mainly interix/windows, so i cannot do too many tests for this. (on
interix both GCC and parity work fine as expected (GCC 3.3 still failing
the hardcode test, as it was before too))

Regarding CVS HEAD: since this is all for production use on many, many
platforms, i can't upgrade (it's simply not my decision). Is HEAD
somewhat stable anyway? I noticed that binutils 2.18 use 2.1a, and - arg
- we can't build binutils on HP anymore as i heard from a colleague.

Cheers, Markus

> 
> Hope that helps.
> 
> Cheers,
> Ralf


-- 
17.-19. Oktober 2007
Salomon Automation am 24. Deutschen Logistik-Kongress der BVL, Berlin; Stand 
W/09

14. November 2007
Salomon Automation an der LogIT Retail im Leopoldsmuseum in Wien



Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz



lt-1.5.24-parity.patch.gz
Description: lt-1.5.24-parity.patch.gz
___
http://lists.gnu.org/mailman/listinfo/libtool

RE: Relinking issue

[Duft Markus]

Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote:
> Hello Markus,
> 
> * Duft Markus wrote on Tue, Oct 09, 2007 at 09:25:15AM CEST:
>> 
>> Regarding CVS HEAD: since this is all for production use on many,
>> many platforms, i can't upgrade (it's simply not my decision). Is
>> HEAD somewhat stable anyway? I noticed that binutils 2.18 use 2.1a,
>> and - arg - we can't build binutils on HP anymore as i heard from a
>> colleague. 
> 
> Can you point to a bug report for this?  If no, it would already help
> to know which exact system this was on (i.e., output of config.guess
> and of `./libtool --config') and how configure was invoked.  Bugs
> won't get fixed if they are not reported.
> 
> Thanks,
> Ralf

Hi!

Of course my colleague will report the issue (as he always does ;o)),
but first he wants to run the test-suite to reproduce things, since he
noticed the problems only inside binutils.

You will hear of him (haubi) ;o)

Cheers, Markus

-- 
17.-19. Oktober 2007
Salomon Automation am 24. Deutschen Logistik-Kongress der BVL, Berlin; Stand 
W/09

14. November 2007
Salomon Automation an der LogIT Retail im Leopoldsmuseum in Wien



Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz



___
http://lists.gnu.org/mailman/listinfo/libtool

RE: passing flags to the librarian

[Duft Markus]

Hi!

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).

Also parity comes with a patch for libtool to behave nicely, and i also
have a bunch of patches we required to be able to build pcre (on other
systems too, not only windows) - i attached them here (apply in source
directory with "patch -p1 < patchfile").

Hope that helps.

P.S.: have you tried ARFLAGS='/LTCG'?

Cheers, Markus

David Byron <> wrote:
> 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 why I need it, or what it actually does, but
> when I compile source with the equivalent option (/GL), I get this
> warning from the librarian if I don't have it:
> 
> /bin/sh ./libtool --tag=CC   --mode=link cccl  /W3 /Zc:wchar_t- /O2
> /Ob1 /Os /GL /GF /FD /Gy /MD -version-info 0:0:0 /LTCG -o
> libpcreposix.la -rpath
> /home/dbyron/src/tuneup/tuneup_juce/trunk/install/lib/Release
> pcreposix.lo libpcre.la /LTCG 
> cygpath: can't convert empty path
> libtool: link: warning: undefined symbols not allowed in
> i686-pc-cygwin shared libraries
> lib -OUT:.libs/libpcreposix.lib  pcreposix.obj
> Microsoft (R) Library Manager Version 8.00.50727.762
> Copyright (C) Microsoft Corporation.  All rights reserved.
> 
> pcreposix.obj : MSIL .netmodule or module compiled with /GL found;
> restarting link with /LTCG; add /LTCG to the link command line to
>  improve linker performance
> Microsoft (R) Library Manager Version 8.00.50727.762
> Copyright (C) Microsoft Corporation.  All rights reserved.
> 
> creating libpcreposix.la
> (cd .libs && rm -f libpcreposix.la && ln -s ../libpcreposix.la
> libpcreposix.la)
> 
> I tried as hard as I know how to get /LTCG on the lib command line, by
> invoking configure with LIB=/LTCG and LDFLAGS=/LTCG.  Here's the
> complete configure invocation:
> 
>   $ ../configure CC=cccl CXX=cccl CPPFLAGS=-DPCRE_STATIC -DNDEBUG
> CFLAGS=/W3 /Zc:wchar_t- /O2 /Ob1 /Os /GL /GF /FD /Gy /MD CXXFLAGS=/W3
> /EHsc /Zc:wchar_t- /O2 /Ob1 /Os /GL /GF /FD /Gy /MD LDFLAGS=/LTCG
> LIBS=/LTCG 
> --enable-shared=no --enable-newline-is-anycrlf --enable-bsr-anycrlf
> --enable-unicode-properties
> --prefix=/home/dbyron/src/tuneup/tuneup_juce/trunk/install
> --libdir=/home/dbyron/src/tuneup/tuneup_juce/trunk/install/lib/Release
> 
> The configure script was generated with autoconf 2.61.  Makefile.in
> was generated with automake 1.10.  Looking into ltmain.sh, I see:
> 
> PROGRAM=ltmain.sh
> PACKAGE=libtool
> VERSION=1.5.23b
> TIMESTAMP=" (1.1220.2.437 2007/02/17 09:08:45)"
> 
> Is this enough version info to see what tools I'm using?  Any
> suggestions about how to get an option to the librarian?
> 
> Thanks much.
> 
> -DB
> 
> PS I'm also curious about the:
> 
> cygpath: can't convert empty path
> 
> warning that comes from this line in the generated libtool script:
> 
> fix_srcfile_path="`cygpath -w "$srcfile"`"
> 
> I guess this gets called with an empty $srcfile but I'm not sure why.
> 
> 
> 
> ___
> http://lists.gnu.org/mailman/listinfo/libtool


-- 
19. - 21. Februar 2008
Salomon Automation auf der LogiMAT 2008, Neue Messe Stuttgart, Deutschland
Halle 6, Stand 527

23. - 27. Februar 2008
MoveRetail auf der EuroShop 2008 in Dusseldorf, Deutschland
Halle 6, Stand C50





Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz



pcre-patches.tar.gz
Description: pcre-patches.tar.gz
___
http://lists.gnu.org/mailman/listinfo/libtool

Avoid la files.

[Duft Markus]

Hi All!

I have a quick question about libtool: What can I break, if I fool
libtool into thinking that there are no .la files for any library on the
command line?

The background: We have a bunch of software (about 1000 libraries) which
are linked (shared) together in one executable. If manually linking it
takes about 30 seconds. If linking with libtool it takes 40 minutes
You see the problem? If I just comment out the double loop in libtool at
line (approximately) 2517 and set found=no allways, it takes only 36
seconds.

We have a completely standard environment, use gcc allways (but with
native linkers on some platforms). We're using AIX, SUN (Sparc, i386),
Linux (x86, x64_86), Windows (parity), HP (Itanium, PA-RISC).

Any ideas?

Cheers, Markus

-- 
19. - 21. Februar 2008
Salomon Automation auf der LogiMAT 2008, Neue Messe Stuttgart, Deutschland
Halle 6, Stand 527

23. - 27. Februar 2008
MoveRetail auf der EuroShop 2008 in Dusseldorf, Deutschland
Halle 6, Stand C50





Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz



___
http://lists.gnu.org/mailman/listinfo/libtool

RE: Avoid la files.

[Duft Markus]

Hello!

W32 was the fastest with 40 minutes, a x86_64 linux that i tried as well
took about 50 minutes before we canceled ;o(

I'm not sure if i can easily put in HEAD, we use 1.5.24. Would it be
enough to get HEAD built somewhere, and bootstrap only the last
component with it (leave all libraries untouched)? Maybe we can try on a
linux box, w32 won't work, since i don't have my patches ported for HEAD
;o(

I attached both the libtool call and the linker call from my w32 box, if
you wanr i can organize linux output as well.

There is not a single convenience library in play, since our tool which
handles these things (Confix, http://www.sf.net/projects/confix) is
still not able to produce those things (arg I know... We'd really
need it for our command lines)

The problem i think this command triggers is, that libtool looks at some
.la files most libraries depend on a lot of times. Maybe caching la
lookup results would be a solution, although i cannot think of how to do
this...

P.S.: the attached output has the .la searching commented out.. If you'd
need the outher output, you will have to wait a hour or two ;o) We have
two executables, both link looots of libraries, i attached both's
output.

P.P.S.: we recently changed Confix (see above) to include all dependent
libraries on the command line, because there are some weird implicit
dependencies around, which didn't get resolved otherwise... Arg - again

P.P.P.S.: please ignore the warnings in the output, they're fixed
already ;o)

And thanks for the fast reaction... ;o)

Cheers, Markus

Ralf Wildenhues <> wrote:
> Hello Markus,
> 
> Thanks for the report.
> 
> * Duft Markus wrote on Thu, Dec 13, 2007 at 10:34:16AM CET:
>> 
>> I have a quick question about libtool: What can I break, if I fool
>> libtool into thinking that there are no .la files for any library on
>> the command line? 
>> 
>> The background: We have a bunch of software (about 1000 libraries)
>> which are linked (shared) together in one executable. If manually
>> linking it takes about 30 seconds. If linking with libtool it takes
>> 40 minutes You see the problem? If I just comment out the double
>> loop in libtool at line (approximately) 2517 and set found=no
>> allways, it takes only 36 seconds.
> 
> Which Libtool version?  If branch-1-5, can you try out with HEAD as
> well?  Are those 1000 libraries all convenience archives?  Can you
> post the link command line and the output that libtool generates from
> it? Are those 40 minutes on w32 or some other system as well?
> 
> To be able to help I need to be able to reproduce the scalability
> issue. 
> 
> Cheers,
> Ralf
> 
> 
> ___
> http://lists.gnu.org/mailman/listinfo/libtool


-- 
19. - 21. Februar 2008
Salomon Automation auf der LogiMAT 2008, Neue Messe Stuttgart, Deutschland
Halle 6, Stand 527

23. - 27. Februar 2008
MoveRetail auf der EuroShop 2008 in Dusseldorf, Deutschland
Halle 6, Stand C50





Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz



linkout.tgz
Description: linkout.tgz
___
http://lists.gnu.org/mailman/listinfo/libtool

RE: Avoid la files.

[Duft Markus]

Good Morning ;)

Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote:
> * Duft Markus wrote on Thu, Dec 13, 2007 at 11:27:34AM CET:
>> 
>> I'm not sure if i can easily put in HEAD, we use 1.5.24. Would it be
>> enough to get HEAD built somewhere, and bootstrap only the last
>> component with it (leave all libraries untouched)?
> 
> Yes.

Ok, i will try on the Linux box (when the box's owner is here).

> 
>> Maybe we can try on a linux box, w32 won't work, since i don't have
>> my patches ported for HEAD ;o(
> 
> Yes, that should be sufficient.  I can't tell you yet whether it would
> help, though, as I'm not yet sure about the actual problem cause.

On the other hand i don't know if this would lead to anything. Even if
it works with HEAD - i can't go away from 1.5 right now.

> 
>> I attached both the libtool call and the linker call from my w32
>> box, if you wanr i can organize linux output as well.
> 
> Thanks.
> 
> So I gather all of those libraries are installed shared libraries that
> come from a third-party package?  And many of those libraries
> themselves depend on other libraries?

Those are nearly all libraries that come from us. About 460 libraries
belong to the program directly, and about 300 libraries are part of out
so-called "toolsbox". Most of the libraries that belong to the program
have dependecies among each other, and all have dependencies to toolsbox
libraries (to many of them)

> 
>> There is not a single convenience library in play, since our tool
>> which handles these things (Confix,
>> http://www.sf.net/projects/confix) is still not able to produce
>> those things (arg I know... We'd really need it for our command
>> lines) 
> 
> I still haven't understood whether this is actually a problem in your
> setup/Config/your package, and you want libtool to work around those
> limitations, or you *really* need five hundred different shared
> libraries and a program that links against all of them.

Naa, libtool doesn't need to do anything different from what it is doing
now, it just needs to be faster ;o) Our build tools simply don't know
yet of how to tell libtool to build convenience libraries, but that will
be solved sometimes...

The number of libraries (without convenience libraries) is one of the
little things i really cannot influence ;o( This is the structure of our
software, i'll have to live with that...

> 
> I mean, wow, have you ever considered that the runtime linker overhead
> for this kind of setup can be excessive?  Just symbol searching is
> bound to take a looong time, and that's even on sane systems like
> GNU/Linux. 

Yes, i'm aware of that. BTW on windows this is really fast ;o)

> 
> Be kindly advised to consider some general guidance how to create
> shared (ELF) libraries:
> <http://people.redhat.com/drepper/dsohowto.pdf>. 
> Note also that *fewer* shared libraries is a good thing for the
> reasons mentioned therein.

I know how to create shared libs, but this piece of software was never
designed to be shared. Or it was, but somebody missed it *lol*

> 
> However, if all those libraries should instead be convenience
> archives, because they should just be linked together into one (or a
> few) big shared libraries, then you can avoid the libtool performance
> problems by simply making those libraries convenience archives.

Yes, maybe, but that doesn't change the fact, that the algotithm for
reading .la files has big scalability problems. It would be really cool
if this would be fixed (or i get a patch for this issue), since my
quick-fix for now (commenting it out), also destroys usage of rpath,
since this information is contained in the .la files too.

I found a sed/grep combination, which i rewrote to try things out. This
didn't get me any performance boost. Also i tried linking a smaller
shared libraries with a few (10) objects and a few dependent libraries
(about 20 direct deps, and inderect about 100 deps...). This also has
more or less big performance problems. It takes about 1 minute with .la
reading, and 20 seconds without...

I don't think it should be too hard to reproduce... Just get yourseld
the library with the most dependencies on your system, and try once
normally, and the with lines 2159 through 2172 commented out in
ltmain.sh. This should give a great difference.

> 
>> The problem i think this command triggers is, that libtool looks at
>> some .la files most libraries depend on a lot of times. Maybe
>> caching la lookup results would be a solution, although i cannot
>> think of how to do this...
> 
> Hmm, then I may need to look at the full output.  But please don't
> send it just yet, please just answer the qu

RE: mingw install directory for shared lib

[Duft Markus]

Bob Friesenhahn <> wrote:
> On Tue, 8 Jan 2008, Ralf Wildenhues wrote:
>> 
>> General question before fixing this: on w32, should even plugins have
>> their DLLs go to $bindir?

Yes, i'd agree to this... ;o) If you try to load a library by yourself,
you will have to know what you're doing. If the DLL is linked to the
executable, you have no (easy) way to influence what is done by the
loader...

Of course there may still be problems if there are dependencies between
plugins, that are installed in different directories, since loading one
plugin will load all libraries this dll is linked to. If those are
plugins themselves, they will have to be in PATH to be found (or in the
same directory, etc.). The easiest solution is using parity ;) but thats
self-advertisement again, sorry...

Cheers, Markus

> 
> Plugin modules should be installed adjacent to the .la files in the
> directory the user specifies since the plugin module should be loaded
> directly without need to consult the PATH.  Of course the .la file
> needs to correctly reference the location of the plugin module.  Only
> general-purpose DLLs need to be installed in the executable search
> path.
> 
> Bob
> ==
> Bob Friesenhahn
> [EMAIL PROTECTED],
> http://www.simplesystems.org/users/bfriesen/ GraphicsMagick
> Maintainer,http://www.GraphicsMagick.org/ 
> 
> 
> 
> ___
> http://lists.gnu.org/mailman/listinfo/libtool


-- 
19. - 21. Februar 2008
Salomon Automation auf der LogiMAT 2008, Neue Messe Stuttgart, Deutschland
Halle 6, Stand 527

23. - 27. Februar 2008
MoveRetail auf der EuroShop 2008 in Dusseldorf, Deutschland
Halle 6, Stand C50





Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz



___
http://lists.gnu.org/mailman/listinfo/libtool

RE: mingw install directory for shared lib

[Duft Markus]

Hm, sorry, as i reread my mail, i realized that the text is in the wrong
position ;) of course my comment is targeted ar bob's text, not ralf's
question...

Duft Markus <> wrote:
> Bob Friesenhahn <> wrote:
>> On Tue, 8 Jan 2008, Ralf Wildenhues wrote:
>>> 
>>> General question before fixing this: on w32, should even plugins
>>> have their DLLs go to $bindir?
> 
> Yes, i'd agree to this... ;o) If you try to load a library by
> yourself, you will have to know what you're doing. If the DLL is
> linked to the executable, you have no (easy) way to influence what is
> done by the loader...
> 
> Of course there may still be problems if there are dependencies
> between plugins, that are installed in different directories, since
> loading one plugin will load all libraries this dll is linked to. If
> those are plugins themselves, they will have to be in PATH to be
> found (or in the same directory, etc.). The easiest solution is using
> parity ;) but thats self-advertisement again, sorry...
> 
> Cheers, Markus
> 
>> 
>> Plugin modules should be installed adjacent to the .la files in the
>> directory the user specifies since the plugin module should be loaded
>> directly without need to consult the PATH.  Of course the .la file
>> needs to correctly reference the location of the plugin module.  Only
>> general-purpose DLLs need to be installed in the executable search
>> path. 
>> 
>> Bob
>> ==
>> Bob Friesenhahn
>> [EMAIL PROTECTED],
>> http://www.simplesystems.org/users/bfriesen/ GraphicsMagick
>> Maintainer,http://www.GraphicsMagick.org/
>> 
>> 
>> 
>> ___
>> http://lists.gnu.org/mailman/listinfo/libtool


-- 
19. - 21. Februar 2008
Salomon Automation auf der LogiMAT 2008, Neue Messe Stuttgart, Deutschland
Halle 6, Stand 527

23. - 27. Februar 2008
MoveRetail auf der EuroShop 2008 in Dusseldorf, Deutschland
Halle 6, Stand C50





Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz



___
http://lists.gnu.org/mailman/listinfo/libtool

RE: mingw install directory for shared lib

[Duft Markus]

Bob Friesenhahn <mailto:[EMAIL PROTECTED]> wrote:
> On Wed, 9 Jan 2008, Duft Markus wrote:
> 
>> Bob Friesenhahn <> wrote:
>>> On Tue, 8 Jan 2008, Ralf Wildenhues wrote:
>>>> 
>>>> General question before fixing this: on w32, should even plugins
>>>> have their DLLs go to $bindir?
>> 
>> Yes, i'd agree to this... ;o) If you try to load a library by
>> yourself, you will have to know what you're doing. If the DLL is
>> linked to the executable, you have no (easy) way to influence what
>> is done by the loader...
> 
> Modules should not be linked with an executable.  That would surely be
> bad design and should not be supported.  There should be no need to
> load a module by yourself since libtool offers libltdl which does it
> for you by requesting to load the associated .la file. Regardless,
> loading modules directly is trivially easy under Windows.

Ok, i agree here.

> 
>> Of course there may still be problems if there are dependencies
>> between plugins, that are installed in different directories, since
>> loading one plugin will load all libraries this dll is linked to. If
>> those are plugins themselves, they will have to be in PATH to be
>> found (or in the same directory, etc.). The easiest solution is
>> using parity ;) but thats self-advertisement again, sorry...
> 
> There should be no dependencies between plugins.  That would surely be
> bad design and should not be supported.  Libtool should be supporting
> portable behavior.  If the user does not desire to implement portable
> behavior, then there is little value to using libtool or libltdl.
> 
> The portable definition for windows should be:
> 
> library - Executables (usually) link directly with libraries and when
> the library is a DLL it should be installed in the executable search
> path, and (ideally) be in the same 'bin' directory as the dependent
> executables.

I wrote some routines to support runpaths on windows, so i install all
my libs in the lib directory ;) Also all my executables and libraries
built with parity are LD_LIBRARY_PATH aware... So i can use full UNIX
like semantics on windows, without any costs (except writing parity
before, which of corse costed lots of nerves...)

> 
> module - Modules are only loaded via an explicit loading mechanism
> (e.g. Windows LoadLibrary() or libltdl.  Modules may depend on
> libraries (see above) but should not depend on other modules.  Since
> modules are explicitly loaded, they may be installed in an
> application-specific lib directory (just like for Unix).

When thinking of the default windows behaviour, i agree here too.

Markus

> 
> Bob
> ==
> Bob Friesenhahn
> [EMAIL PROTECTED],
> http://www.simplesystems.org/users/bfriesen/ GraphicsMagick
> Maintainer,http://www.GraphicsMagick.org/ 


-- 
19. - 21. Februar 2008
Salomon Automation auf der LogiMAT 2008, Neue Messe Stuttgart, Deutschland
Halle 6, Stand 527

23. - 27. Februar 2008
MoveRetail auf der EuroShop 2008 in Dusseldorf, Deutschland
Halle 6, Stand C50





Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz



___
http://lists.gnu.org/mailman/listinfo/libtool

HEAD testsuite.

[Duft Markus]

Hi all...

Could it be, that the autotest testsuite behaves badly if building
out-of-source? I'm getting a whole bunch of file not founds with
relative paths within the source dir. If yes, for now I will finish my
libtool port with building inside the source dir, so I manage to fugure
out which failures are my fault :)

Cheers, Markus


___
http://lists.gnu.org/mailman/listinfo/libtool

RE: HEAD testsuite.

[Duft Markus]

Hi

Another one... The "run" scripts for the failed tests seem to miss some
quoting (for exmaple my preprocessor is  -E, so i get:
testsuite: invalid option: -E...

Cheers, Markus

Duft Markus <> wrote:
> Hi all...
> 
> Could it be, that the autotest testsuite behaves badly if building
> out-of-source? I'm getting a whole bunch of file not founds with
> relative paths within the source dir. If yes, for now I will finish my
> libtool port with building inside the source dir, so I manage to
> fugure out which failures are my fault :)
> 
> Cheers, Markus
> 
> 
> ___
> http://lists.gnu.org/mailman/listinfo/libtool



___
http://lists.gnu.org/mailman/listinfo/libtool

Native Windows through parity

[Duft Markus]

Hi there (again :))!

I have a few patches for libtool in my queue again :)

* 1.5.24 -> all tests passed
* 1.5.26 -> all tests passed
* HEAD (2.1c) -> all classic tests passed, log for new testsuite
attached.

I hope this time they will make it into CVS :)

For HEAD, I'd need some help, please. I attached the log for test
no. 5, which fails like some others too with file not found errors which
I don't understand... (?) any ideas?

Note: I have chosen the *-*-winnt* host-triplet for my setup, since the
resulting binaries are plain native windows, so I think this is correct.
Also right now I'm the only one doing this, and as far as I know, there
are no collissions with others.

Note: I needed to patch config.guess to recognize my compiler on interix
(cygwin not done yet...). I did this for various automake releases and
the gnuconfig package from portage (did you know, that portage runs on
interix fine allready? :) I made a port of gentoo/alt-prefix). I
attached only the automake 1.10 patch, which should make obvious what I
did there. Of course this patch is not targeted at libtool, I attached
it here only, since it's a prerequisite to make things work on
interix...

Please could somebody review the patches and the testsuite log (which is
more important for me right now :)), and give me some feedback?

Thanks in advance!

Cheers, Markus


lt-1.5.26-parity.patch.gz
Description: lt-1.5.26-parity.patch.gz


automake-1.10-winnt.patch.gz
Description: automake-1.10-winnt.patch.gz


lt-1.5.24-parity.patch.gz
Description: lt-1.5.24-parity.patch.gz


testsuite.log.gz
Description: testsuite.log.gz
___
http://lists.gnu.org/mailman/listinfo/libtool

RE: HEAD testsuite.

[Duft Markus]

Gary V. Vaughan <> wrote:
> Hi Markus,
> 
> On 6 Feb 2008, at 22:17, Duft Markus wrote:
> 
>> Hi all...
>> 
>> Could it be, that the autotest testsuite behaves badly if building
>> out-of-source? I'm getting a whole bunch of file not founds with
>> relative paths within the source dir. If yes, for now I will finish
>> my libtool port with building inside the source dir, so I manage to
>> fugure out which failures are my fault :)
>> 
>> Cheers, Markus
> 
> 
> I ran 'make distcheck' successfully as part of the libtool-2.1b
> release process, which tests in tree, and out of tree builds.
> 
> Cheers,
>   Gary

Aye... This made me dig a little deeper, and i found that i had a
damaged ln in my PATH... Arg... Thanks anyway, now a whole lot of fails
disappeared.

Cheers, Markus


___
http://lists.gnu.org/mailman/listinfo/libtool

RE: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

[Duft Markus]

Duft Markus <> wrote:
> Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote:
>> You have several options to avoid this failure:
>> 
>> - find out why timestamps are not in the right order after   
>> libtoolize --ltdl=sub/ltdl 
>> 
>> (inside sub/ltdl, configure.ac should come before aclocal.m4 should
>> come before configure and Makefile.in).  This is a bug.  It seems
>> that has to do with your system's symlink semantics.
>> 
>> - upgrade to Automake 1.10 locally (your automake 1.9.6 gets run
>> accidentally by the test due to above timestamp messup.  This is
>> because having a toplevel package
>> 
>> - Fix your local automake 1.9.6 installation by using this patch:
>> 
>
<http://thread.gmane.org/gmane.comp.gnu.libtool.general/8191/focus=8200>
>> 
> 
> Ok Thanks. I will have a look at this. For Symlinks: i use cp -p
> instead of ln -s. can this cause the misbehaviour?
> 
> For Automake: i have gentoo/alt-prefix portage installed as system, so
> i'm using whatever a corresponding linux for example would use. I now
> double checked, but it seems i have only one automake installed:
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild   R   ] sys-devel/automake-1.10  0 kB
> 
> Total: 1 package (1 reinstall), Size of downloads: 0 kB
> mduft build.libtool $ type automake
> automake is /opt/gentoo/usr/bin/automake
> mduft build.libtool $
> 
> As for the patch for 1.9.6: i cannot find a 1.9.6 installation here. I
> will try and rebootstrap everything, but i have done this before
> running the testsuite as far as i remember

Hi!

This has to be a problem of every gentoo linux or gentoo/alt-prefix
installation on any host system: automake is a link to am-wrapper.sh
which in turn looks at Makefile.in to find out which version of automake
to use. If there is no Makefile.in it uses the newest (1.10)  Arg.
This means, that it will allways use 1.9.6 here, until 1.9.6 is
uninstalled from the system (yes i missed it before, it _is_ installed
of course...).

So of course this is not a libtool bug. I will talk to gentoo guys to
further follow this. Thanks for the help so far.

Cheers, Markus

> 
> Cheers, Markus
> 
>> Cheers,
>> Ralf
> 
> 
> 
> ___
> http://lists.gnu.org/mailman/listinfo/libtool



___
http://lists.gnu.org/mailman/listinfo/libtool

RE: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

[Duft Markus]

Ralf Wildenhues  wrote:
> You have several options to avoid this failure:
> 
> - find out why timestamps are not in the right order after
>libtoolize --ltdl=sub/ltdl
> 
> (inside sub/ltdl, configure.ac should come before aclocal.m4 should
> come before configure and Makefile.in).  This is a bug.  It seems
> that has to do with your system's symlink semantics.
> 
> - upgrade to Automake 1.10 locally (your automake 1.9.6 gets run
> accidentally by the test due to above timestamp messup.  This is
> because having a toplevel package
> 
> - Fix your local automake 1.9.6 installation by using this patch:
>

> 

Ok Thanks. I will have a look at this. For Symlinks: i use cp -p instead
of ln -s. can this cause the misbehaviour?

For Automake: i have gentoo/alt-prefix portage installed as system, so
i'm using whatever a corresponding linux for example would use. I now
double checked, but it seems i have only one automake installed:

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] sys-devel/automake-1.10  0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB
mduft build.libtool $ type automake
automake is /opt/gentoo/usr/bin/automake
mduft build.libtool $

As for the patch for 1.9.6: i cannot find a 1.9.6 installation here. I
will try and rebootstrap everything, but i have done this before running
the testsuite as far as i remember

Cheers, Markus

> Cheers,
> Ralf



___
http://lists.gnu.org/mailman/listinfo/libtool

RE: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

[Duft Markus]

Duft Markus <> wrote:
> Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote:
>> 
>> Thanks, I forgot about the need to 'make install' first.
>> 
>> Does ls have an option to show full time stamp resolution?  If yes,
>> please repeat the above after 'rm -rf t', using the option with both
>> ls invocations.
> 
> Ok, i added --full-time. In the meantime i found something in
> sub/ltdl/Makefile. The rule for distdir is:
> 
> 704 distdir: $(DISTFILES)
> 705 $(am__remove_distdir)
> 706 mkdir $(distdir)
> 
> The mkdir fails because the directory allready exists... I'll dig
> deeper there.
> 

Seems i found it: the distdir rule in the top level makefile looks a
little different:

472 distdir: $(DISTFILES)
473 $(am__remove_distdir)
474 test -d $(distdir) || mkdir $(distdir)

Shouldn't the one in sub/ltdl look the same? When adding the test -d
there, make dist runs through without error.

Cheers, Markus

> 
>> 
>> Cheers,
>> Ralf



___
http://lists.gnu.org/mailman/listinfo/libtool

RE: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

[Duft Markus]

Ralf Wildenhues  wrote:
> 
> Thanks, I forgot about the need to 'make install' first.
> 
> Does ls have an option to show full time stamp resolution?  If yes,
> please repeat the above after 'rm -rf t', using the option with both
> ls invocations.

Ok, i added --full-time. In the meantime i found something in
sub/ltdl/Makefile. The rule for distdir is:

704 distdir: $(DISTFILES)
705 $(am__remove_distdir)
706 mkdir $(distdir)

The mkdir fails because the directory allready exists... I'll dig deeper
there.

Cheers, Markus

> 
> Cheers,
> Ralf



log-interix1.gz
Description: log-interix1.gz
___
http://lists.gnu.org/mailman/listinfo/libtool

RE: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

[Duft Markus]

Ralf Wildenhues  wrote:
> Please enter the top build directory, execute these commands, and post
> log-interix1.gz:
> 
> ( mkdir t
> cd t
> ../libtoolize --copy --ltdl=sub/ltdl
> ls -lart sub/ltdl
> rm -rf sub
> ../libtoolize --ltdl=sub/ltdl
> ls -lart sub/ltdl
> cd ../tests/testsuite.dir/44
> head Makefile.in configure sub/ltdl/Makefile.in sub/ltdl/configure
> make -n distdir
> ) 2>&1 | tee log-interix1
> gzip log-interix1

Hi Ralf!

Since the commands reported errors/warnings at first, i did a gmake
install before repeating. I attached both logs.

Cheers, Markus

> 
> Thanks,
> Ralf



log-interix.tgz
Description: log-interix.tgz
___
http://lists.gnu.org/mailman/listinfo/libtool

Subject: [libtool 2.1c] testsuite: 44 45 46 failed

[Duft Markus]

Hi!

I have ported (again) libtool to windows using parity. No I'm stuck with
the last three testsuite failures, which I just can't find causes for...

Could you please have a look at this? I also attached the patch I use to
get things rolling :) I plan to add some more comments, etc. So this is
not the final version, but still enough to collect some comments.

Thanks in advance, Cheers, Markus.


testsuite.log.gz
Description: testsuite.log.gz


lt-2-HEAD.patch.gz
Description: lt-2-HEAD.patch.gz
___
http://lists.gnu.org/mailman/listinfo/libtool

RE: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

[Duft Markus]

Duft Markus <> wrote:
> Ralf Wildenhues <mailto:[EMAIL PROTECTED]> wrote:
> 
> Hi Ralf!
> 
> Since the commands reported errors/warnings at first, i did a gmake
> install before repeating. I attached both logs.

Hi!

I finally found the real error :) Seems i was just to blind to see... It
seems to be related to the gmake dist call:

mduft 44 $ rm -rf subproject-demo-2.1c/
mduft 44 $ gmake dist
{ test ! -d subproject-demo-2.1c || { find subproject-demo-2.1c -type d
! -perm -200 -exec chmod u+w {} ';' && rm -fr subproject-demo-2.1c; }; }
test -d subproject-demo-2.1c || mkdir subproject-demo-2.1c
list='sub/ltdl'; for subdir in $list; do \
  if test "$subdir" = .; then :; else \
test -d "subproject-demo-2.1c/$subdir" \
|| /opt/gentoo/bin/mkdir -p "subproject-demo-2.1c/$subdir" \
|| exit 1; \
distdir=`CDPATH="${ZSH_VERSION+.}:" && cd
subproject-demo-2.1c && pwd`; \
top_distdir=`CDPATH="${ZSH_VERSION+.}:" && cd
subproject-demo-2.1c && pwd`; \
(cd $subdir && \
  gmake  \
top_distdir="$top_distdir" \
distdir="$distdir/$subdir" \
am__remove_distdir=: \
am__skip_length_check=: \
distdir) \
  || exit 1; \
  fi; \
done
gmake[1]: Entering directory
`/home/mduft/parity/build.libtool/tests/testsuite.dir/44/sub/ltdl'
:
mkdir
/home/mduft/parity/build.libtool/tests/testsuite.dir/44/subproject-demo-
2.1c/sub/ltdl
mkdir: cannot create directory
`/home/mduft/parity/build.libtool/tests/testsuite.dir/44/subproject-demo
-2.1c/sub/ltdl': File exists
gmake[1]: *** [distdir] Error 1
gmake[1]: Leaving directory
`/home/mduft/parity/build.libtool/tests/testsuite.dir/44/sub/ltdl'
gmake: *** [distdir] Error 1

Cheers, Markus
> 
>> 
>> Thanks,
>> Ralf



___
http://lists.gnu.org/mailman/listinfo/libtool

RE: [patch/rfc] setting version type based on vendor

[Duft Markus]

Hi!

Ralf Wildenhues <> wrote:
> Hello Mike,
> 
> Please post patches to the libtool-patches list in the future, thanks.
> 
> * Mike Frysinger wrote on Sat, Feb 16, 2008 at 09:48:52AM CET:
>> i dont know if there's a policy on this, but we've been treating the
>> shared libraries in the Gentoo/FreeBSD port like Linux shared
>> libraries.  we control this based upon the vendor field in the
>> toolchain tuple. 
> 
> I have no problem with this, other than: the fact that it may create
> an incompatible switch-over point for gentoo users, and the unwary
> may be expecting for her libraries, built on gentoo, could be usable
> on other (gasp!) FreeBSD (-like) systems, and also that GNU/FreeBSD
> distributions other than gentoo (if there are any) should not be
> discriminated against.  At least with GNU/Linux, the vendor field is
> completely useless -- what about spin-offs of Gentoo for example,
> what do they use? 
> 
> What do the others think?

I'm running a gentoo/alt-prefix inside Interix on Windows, which i think could 
also be titled gentoo, but for sure does not behave fully like linux :)

Cheers, Markus

> 
> Cheers,
> Ralf
> 
>> 2008-02-16  Diego Pettenò  <[EMAIL PROTECTED]>
>> 
>>  * libltdl/m4/libtool.m4: Treat Gentoo/FreeBSD shareds libs as Linux.



___
http://lists.gnu.org/mailman/listinfo/libtool

RE: Using libltdl with the Microsoft compiler

[Duft Markus]

> 
[snip]
> 
> Historically (i.e. prior to libtool 2.x), I've found that those shell
> environments have not been up to the task of building my project with
> the Microsoft compiler. So I've maintained a Visual C++ project file
> build for that compiler. I've just recently started using libltdl in
my
> project, though; and I'd like to build it using the same facilities as
> the rest of the software.

Hmm... doesn't sound too easy :) at our company we use MS compilers
through a compiler frontend that mimics GCC/LD, so we can use the same
build system as on all the other platforms (i.e. libtool, autotools,
etc...) - see below.

> 
> Really, I'd be happy to jettison the Visual C++ project file build and
> build the software with the autotools on Windows. But libtool 1.5
> certainly didn't play nicely with the Microsoft compiler; and while I
> haven't tried 2.2, the traffic I've seen on this list suggests that
> patches to improve that situation haven't made it in yet.

Try using parity [1] as frontend fort he microsoft compiler. The
distfile also includes patches for various libtool versions to make is
play nice with parity/ms compiler/ms linker etc. there are some wikis on
how to get started at [2] and [3]. You will want to use MS Interix
(SFU/SUA) as environment. Depending on your windows version you will
have to install SFU 3.5 (Windows 2000, Windows XP, Windows Server 2003),
SUA 5.2 (Windows Server 2003 R2) or SUA 6.0 (Windows Vista, Windows
Server 2008)

Hope that helps :)

[1] http://sourceforge.net/projects/parity
[2] http://parity.wiki.sourceforge.net/Building+parity+from+Interix
[3]
http://parity.wiki.sourceforge.net/HowTo+Use+parity+and+libtool+together

Cheers, Markus

> 
> --
> Braden McDaniel  e-mail: <[EMAIL PROTECTED]>
>    Jabber: <[EMAIL PROTECTED]>
> 
> 
> ___
> http://lists.gnu.org/mailman/listinfo/libtool


___
http://lists.gnu.org/mailman/listinfo/libtool

RE: Using libltdl with the Microsoft compiler

[Duft Markus]

> 
> * Braden McDaniel wrote on Fri, Jun 20, 2008 at 10:20:13PM CEST:
> > Ralf Wildenhues wrote:
> >> * Braden McDaniel wrote on Fri, Jun 20, 2008 at 11:03:04AM CEST:
[snip]
> 
> Yes, unfortunately there is still a ways to go.

Btw. @Ralf: how is integration of the windows patchery going? :) has
there been something moving on? You said there will be branches for it
when libtool has migrated to GIT. How ist he progress there?

Cheers, Markus

> 
> Cheers,
> Ralf
> 
> 
> ___
> http://lists.gnu.org/mailman/listinfo/libtool


___
http://lists.gnu.org/mailman/listinfo/libtool

RE: cccl usage

[Duft Markus]

> 
> Den 2009-01-07 20:24, skrev Peter Rosin:
> > Den 2009-01-07 20:07 skrev Ralf Wildenhues:
> >> Hi Peter,
> >>
> >> * Peter Rosin wrote on Wed, Jan 07, 2009 at 02:09:38PM CET:
> >>> Ralf, I have a vague memory of you mentioning that you knew of a
> >>> project that was using cccl to provide its Windows port, do you
> >>> remember which project that was? Is anyone else aware of any cccl
> >>> users?
> >>
> >> Hmm.  Markus Duft started out with cccl IIRC, but quickly switched
> to
> >> implementing his own program.  Benoit has made some changes to the
[snip]
> 
> Still hunting for cccl+libtool users.

Hm, yeah, I started out using cccl. After a few days of patching I gave
up. I was unable to use it as it was, so I started implementing parity
[1]. Also at that time I was looking for support and other cccl users,
which was somehow unsuccessful.

[1] http://parity.sf.net

Cheers, Markus

> 
> Cheers,
> Peter
> 
> 
> ___
> http://lists.gnu.org/mailman/listinfo/libtool


___
http://lists.gnu.org/mailman/listinfo/libtool

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

[Duft Markus]

> Message: 1
> Date: Sat, 15 Aug 2009 21:41:26 +0200
> Subject: Re: global_symbol_pipe not picking up an initialized global
>   variable with msvc
> Message-ID: <4a870f66.1080...@lysator.liu.se>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Den 2009-08-14 23:41 skrev David Byron:
[snip]
> >
> > 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.

> >
> > What's interesting is that I only get unresolved externs for the
> initialized
> > variables:
> >
> > utils-test.obj : error LNK2001: unresolved external symbol _optopt
> > utils-test.obj : error LNK2001: unresolved external symbol _optind
> > utils-test.obj : error LNK2001: unresolved external symbol _opterr

shouldn't that be looking for __imp_optopt, etc? i guess you do try to
link against a shared lib?

> >
> > Snippets from dumpbin -symbols on the getopt_long.obj look like
this:
> >
[snip]
> >
> > Note that the unitialized variables are marked as "UNDEF" whereas
> optopt,
> > optind and optopt are marked as "SECT4".

thats a typical problem of visual studio i have run into many times
before. uninitialized variables are often simple undefined, and the
linker knows how/where to magically define them. i still haven't
discovered how i can overcome the issue .. :(

Hope that helps,
Cheers, Markus

> >
> > After a bit of digging, I have a feeling that the place to fix this
> is the
> > source file that puts this in the generated libtool script:
> >
> > # Take the output of nm and produce a listing of raw symbols and C
> names.
> > global_symbol_pipe="gawk ' {last_section=section; section=\$ 3};
> > /Section length .*#relocs.*(pick any)/{hide[last_section]=1}; \$
> > 0!~/External *\\|/{next}; / 0+ UNDEF /{next}; / UNDEF
> > \\([^|]\\)*()/{next}; {if(hide[section]) next}; {f=0}; \$
> > 0~/\\(\\).*\\|/{f=1}; {printf f ? \"T \" : \"D \"}; {split(\$ 0,
> a,
> > /\\||\\r/); split(a[2], s)}; s[1]~/^...@?]/{print s[1], s[1];
> next};
> > s[1]~prfx {split(s[1],t,\"@\"); print t[1],
> substr(t[1],length(prfx))} '
> > prfx=^_"
> >
> > My libtool/awk skills are not where they need to be to fix this.  My
> > understanding of symbol resolution/linking in general is not where
it
> needs
> > to be to even know if pulling in everything marked "External" but
not
> > necessarily "UNDEF" is the right thing to do.
> >
> > I could (obviously) use a hand here.
> >
> > Thanks for your help.
> 
> I don't think the awk script is at fault, if I run your dumpbin -
> symbols
> data through that global_symbols_pipe (manually, m4sh-isms stripped
> of course) it produces:
> 
> D _optarg optarg
> D _optreset optreset
> D _opterr opterr
> D _optind optind
> D _optopt optopt
> 
> which seems about right. Sure, the initialized variables *could* have
> been marked with C instead of D, but I think C and D are treated
> equally further down in the processsing.
> 
> However, to be 100% certain and eliminate any doubt you can - if you
> wish - configure with NM=nm (instead of dumpbin -symbols) and see if
> that makes any difference.
> 
> I need to see more of what you are actually trying to do, the real
> libtool invocations and the output they produce etc. Compress the
> output if it is large...
> 
> Cheers,
> Peter
> 
> 
> 
> 
> 
> --
> 
> ___
> Libtool mailing list
> Libtool@gnu.org
> http://lists.gnu.org/mailman/listinfo/libtool
> 
> 
> End of Libtool Digest, Vol 81, Issue 16
> ***


___
http://lists.gnu.org/mailman/listinfo/libtool

RE: global_symbol_pipe not picking up an initialized globalvariable with msvc

[Duft Markus]

> 
> > > 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 checked this once more and the dllimport was missing.
> When I
> jimmy around the definition of UTL_EXPORT, I can make this problem
> disappear.  When UTL_EXPORT is empty I get this error.  When it's
> defined as
> __declspec(dllimport), utils-test links fine.
> 
> > shouldn't that be looking for __imp_optopt, etc? i guess
> > you do try to link against a shared lib?
> 
> When I'm linking against a shared lib, this works.  If I'm linking
> against a
> static lib, UTL_EXPORT needs to be empty or I get errors like this:
> 
> unresolved external symbol __imp__optopt
> 
> There's another thread about how to define UTL_EXPORT properly so I'll
> respond there about how to handle this.  It feels like I want a
> compiler
> flag to depend on the kind of library found at link
time...problematic.

Thats exactly one of the reasons why i started out with parity [1]. it's
sole purpose is to ease building windows binaries using the native
visual studio compiler, but still behaving a little more like gcc/other
unixish compilers/linkers. with parity it's easy: define dllimport
_always_, and the compiler will handle the case where the library is
built static only - so both versions work without the target binary
needing to know which linking it has to use.

parity also has tons of other features, like LD_PRELOAD, lazy loading,
etc. some documentation can be found in it's subversion repo, accessible
through sourceforge. maybe that helps. there is a libtool patch too,
which makes the two work together perfectly... however (harrumph @ ralf
;) ) more than two years of reporting the patch didn't bring it into
libtools repo(s).

[1] http://www.sf.net/projects/parity

Have fun :)
Cheers, Markus

> 
> Thanks for your help.
> 
> -DB



___
http://lists.gnu.org/mailman/listinfo/libtool