problems in libtool
Hi I have downloaded libtool 1.5.22 to my freebsd system.Everything went nice.I issued ./configure;make;make install. My problem is that i downloaded libtool since it is necessary for Guile(necessary for SDL).when i run ./configure for guile still it says checking for lt_dlinit in -lltdl...no configure:error: libltdl not found.see README any help? regards gopi - Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates.___ http://lists.gnu.org/mailman/listinfo/libtool
[Bug-spacechart] perpsective business
Es usted una persona responsable y esta buscando un trabajo de medio tiempo muy bien pagado? Somos una compania familiar especializados en varias operaciones con antiguedades y joyeria Antigua, somos “ROYAL CROWN ltd” , y estamos buscando gente honesta y responsable para que se nos una.. No te pierdas esta oportunidad – somos exactamente lo que estas buscando! Ganaras mas de EUR 1500 por mes, utilizando solo 3-4 horas de tu tiempo. Es real con nosotros!. Nosotros no hacemos conversacion de venta que requiera que pagues cargos de inscripcion o inscribirte a una lista de correo. No queremos que inviertas dinero. Este trabajo requiere solo un monto limitado de tu tiempo.. Te pagaremos en la primera semana de trabajo No requerimos ninguna experiencia ni habilidad especial. Trabajaras como un contratado independiente desde tu hogar. Si estas interesado, por favor sientete libre de pedir informacion adicional y las provisiones generales. Escribenos ahora, te responderemos al instante. Por favor responde a este mail: [EMAIL PROTECTED] any sword steady long enough to fall on it." Naturally, the younghe stood sweating in the square, too hot to feel as hungry or thirstyCarrhae that he was a witness to nefas, the unspeakable,intensified-and then, as a man drew his dagger with a scream of rageRoads and Shadows and Imperial Lady (written with Andre Norton)-I havescreamed like a woman in childbirth," Lucilius reported. "Wept. ___ Bug-spacechart mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-spacechart
wgcc 2.0.5 released
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.)
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 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 wou
RE: Support for VC++ toolchain (was Re: Absolute paths generatedby libtool.)
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
Re: problems in libtool
Hello Gopi, * Gopi kumaran wrote on Wed, Nov 29, 2006 at 10:39:09AM CET: > I have downloaded libtool 1.5.22 to my freebsd system.Everything > went nice.I issued ./configure;make;make install. > My problem is that i downloaded libtool since it is necessary for > Guile(necessary for SDL).when i run ./configure for guile still it > says > checking for lt_dlinit in -lltdl...no > configure:error: libltdl not found.see README Look in config.log, where you may find more information about the error. I assume you simply need ./configure CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib in order to find the installed library (and the header files as well). Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
