[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

2.2.6: -ofoo.exe creates foo

From: Akim Demaille
Subject: 2.2.6: -ofoo.exe creates foo
Date: Mon, 24 Nov 2008 17:06:17 +0100


I suppose our setup is quite unusual. We use a GNU/Linux machine and Wine to compile and link using VC++. Our configure computes that EXEEXT=.exe, which is fine. But then libtool 2.2.6, when linking an executable with dependencies on dynamic libraries, discards the extension.

For instance:

$ ./libtool --mode=link --tag=CXX g++ -o foo.exe foo.lo sdk-remote/ src/libuobject/libuobject.la libtool: link: g++ -o .libs/foo.exe .libs/foo.o -Wl,-bind_at_load sdk-remote/src/libuobject/.libs/libuobject.dylib /Users/akim/src/ urbi/2.0/kernel/_build/i386-apple-darwin9.5.0/sdk-remote/src/ liburbi/.libs/liburbi.dylib /Users/akim/src/urbi/2.0/kernel/_build/ i386-apple-darwin9.5.0/sdk-remote/lib/libport/.libs/libport.dylib / Users/akim/src/urbi/2.0/kernel/_build/i386-apple-darwin9.5.0/sdk- remote/jpeg-6b/.libs/libjpeg.dylib
$ ls -ltr
-rw-r--r--   1 akim  akim      28 Nov 24 16:58 foo.cc
-rw-r--r--   1 akim  akim     260 Nov 24 16:59 foo.lo
-rwxr-xr-x   1 akim  akim    4819 Nov 24 17:00 foo
$ head foo
#! /bin/sh

# foo - temporary wrapper script for .libs/foo.exe
# Generated by ltmain.sh (GNU libtool) 2.2.6
# The foo program cannot be directly executed until all the libtool
# libraries that it depends on are installed.
# This wrapper script should never be moved out of the build directory.
# If it is, it will not operate correctly.

(this is under osx, hence the extensions, but it's unfortunately the same on the GNU/Linux box using VC++ as a compiler).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]