Re: AWARD NOTIFICATION
> You have therefore been approved for a lump sum pay > out of US$1,500,000.00 in cash credited to file REF > NO. REF: WBL/67-B773524441. This is from total As far as I remember, within the last ?month? a French court forced a company who promised a prize of XXX to actually pay it. (Was one of these free prize scams) (I think it was a paper leaflet rather than an email...) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
[ 101415 ] libtool + C++ + gcc on solaris
Support Request #101415, was updated on 2002-Oct-18 08:55 You can respond by visiting: http://savannah.gnu.org/support/?func=detailsupport&support_id=101415&group_id=25 Category: None Status: Open Priority: 5 Summary: libtool + C++ + gcc on solaris By: rboehne Date: 2002-Oct-22 08:28 Logged In: YES user_id=148 Browser: Mozilla/4.76 [en] (X11; U; OSF1 V4.0 alpha) This is a canned response from the Libtool maintainers regarding your support inquiry. Your inquiry left out the crucial detail of which version of Libtool you are having trouble with. Please read http://www.gnu.org/software/libtool/libtool.html where it concerns posting to the bug-libtool mailing list: If you think you have found a bug in libtool, then you should, in the first instance send as complete a report as possible to this list, including the version of Libtool that you are using. Ideally, you should include the text you get by running config.guess, the text you see when you run configure, and if you can, a patch made with diff -u5 which fixes the problem. If you can send a small script, modelled after the scripts in the tests directory of the distribution which fails with the unpatched distribution, but passes with your patch applied we can add the test to the distribution to make sure the bug doesn't reappear. -- By: David.Decotigny Date: 2002-Oct-18 08:55 Logged In: NO Browser: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1) Gecko/20020827 We have gcc-3.2 here compiled using: --enable-shared --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld When configure runs libtool, it discovers that gcc does not use a GNU ld, which is just the case. So, when creating a shared library, it will be the case that libtool will "manually" invoke the ld (/usr/ccs/bin/ld here). Why not... BUT... The library works fine as long as there are no C++ global objects that are expected to be constructed before main() (ie global objects declared in a c++ source as "MyClass object(init_parameters)). If there are such objects, the behavior any program dynamically linked against the library is to simply ignore them, or to crash in the middle of the objects instanciations... I noticed that building the library manually with "gcc-3.2 -shared" instead of the "ld" command line set by libtool, will result in a correct behavior: everything will be correctly initialized before main(). If I add the crtbegin/crti/crtend objects in the library, it actually seems to work fine too. So the question: why try to guess a (apparently broken) ld command line, since gcc -shared seems to do the job right? -- You can respond by visiting: http://savannah.gnu.org/support/?func=detailsupport&support_id=101415&group_id=25 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool on darwin #2
uhmm... sorry for the resend. I forgot to mention to CC me, as I am NOT subscribed on this list. Hi! I have found yet another libtool bug. I am using autoconf 2.52, automake 1.6.1 and libtool (latest CVS version of branch-1-4). Short bug description: I can't link against a framework, because libtool throughs the needed -framework param away. Long description: /bin/sh ../../libtool --mode=link gcc -g -O2 -I/Users/christop/devel/ggiroot/include -D_REENTRANT -D_THREAD_SAFE -g -Wall -framework ApplicationServices -L/Users/christop/devel/ggiroot/lib -o quartz.la -rpath /Users/christop/devel/ggiroot/lib/ggi/display -module -no-undefined -avoid-version -export-symbols ./EXPSYMS mode.lo visual.lo ../../ggi/libggi.la -lgii -lgg mkdir .libs rm -fr .libs/quartz.la .libs/quartz.* .libs/quartz.* (cd . && ln -s mode.lo mode.o) (cd . && ln -s visual.lo visual.o) Up to here, everything is correct. Note the present -framework ApplicationServices here. gcc -r -keep_private_externs -nostdlib -o .libs/quartz.so-master.o mode.lo visual.lo && gcc -bundle -o .libs/quartz.so .libs/quartz.so-master.o -L/Users/christop/devel/ggiroot/lib -L../../ggi/.libs -lggi -lgii -lgg -lc And here it is away! That leads to the following linking breakage: ld: Undefined symbols: _CGDisplayAvailableModes _CGDisplayBestModeForParameters _CGDisplayCurrentMode _CGDisplayRelease _CGDisplaySwitchToMode _CGMainDisplayID _CGPaletteCreateDefaultColorPalette _CGPaletteRelease Has anyone an idea, what's going wrong in libtool? -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Add hppa*64* support to libtool (HEAD branch)
Ross,
This patch seems to be pretty significant. Do you have paperwork
filed with the FSF which supports significant contributions to
libtool?
Bob
On Tue, 22 Oct 2002 [EMAIL PROTECTED] wrote:
>
> This patch was made against libtool.m4 version 1.268.
>
>
> ChangeLog
>
> 2002-10-22 Ross Alexander <[EMAIL PROTECTED]>
>
> * libtool.m4: Major reorganisation of the HPUX code to add support
> for
> the 64bit PA-RISC HPUX environment. The 64bit PA environment is
> based
> on the ELF-64 standard and is very similar to the IA64 HPUX system.
> From binutils-2.13 the GNU ld works with elf64hppa for both shared
> libraries and executables. The HPUX9 specific code has been
> seperated
> its own case in AC_LIBTOOL_LANG_CXX_CONFIG and
> AC_LIBTOOL_PROG_LD_SHLIBS.
>
>
>
> *** libtool.m4-head-1.268 Tue Oct 22 15:11:16 2002
> --- libtool.m4Tue Oct 22 13:10:45 2002
> ***
> *** 1248,1279
> hpux9* | hpux10* | hpux11*)
> # Give a soname corresponding to the major version so that dld.sl refuses to
> # link against other versions.
> version_type=sunos
> need_lib_prefix=no
> need_version=no
> ! if test "$host_cpu" = ia64; then
> hardcode_into_libs=yes
> dynamic_linker="$host_os dld.so"
> shlibpath_var=LD_LIBRARY_PATH
> shlibpath_overrides_runpath=yes # Unless +noenvvar is specified.
> library_names_spec='${libname}${release}.so$versuffix
>${libname}${release}.so$major $libname.so'
> soname_spec='${libname}${release}.so$major'
> if test "X$HPUX_IA64_MODE" = X32; then
> sys_lib_search_path_spec="/usr/lib/hpux32 /usr/local/lib/hpux32
>/usr/local/lib"
> else
> sys_lib_search_path_spec="/usr/lib/hpux64 /usr/local/lib/hpux64"
> fi
> sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
> ! else
> dynamic_linker="$host_os dld.sl"
> shlibpath_var=SHLIB_PATH
> shlibpath_overrides_runpath=no # +s is required to enable SHLIB_PATH
> library_names_spec='${libname}${release}.sl$versuffix
>${libname}${release}.sl$major $libname.sl'
> soname_spec='${libname}${release}.sl$major'
> ! fi
> # HP-UX runs *really* slowly unless shared libraries are mode 555.
> postinstall_cmds='chmod 555 $lib'
> ;;
>
> irix5* | irix6* | nonstopux*)
> case $host_os in
> --- 1248,1294
> hpux9* | hpux10* | hpux11*)
> # Give a soname corresponding to the major version so that dld.sl refuses to
> # link against other versions.
> version_type=sunos
> need_lib_prefix=no
> need_version=no
> ! case "$host_cpu" in
> ! ia64*)
> hardcode_into_libs=yes
> dynamic_linker="$host_os dld.so"
> shlibpath_var=LD_LIBRARY_PATH
> shlibpath_overrides_runpath=yes # Unless +noenvvar is specified.
> library_names_spec='${libname}${release}.so$versuffix
>${libname}${release}.so$major $libname.so'
> soname_spec='${libname}${release}.so$major'
> if test "X$HPUX_IA64_MODE" = X32; then
> sys_lib_search_path_spec="/usr/lib/hpux32 /usr/local/lib/hpux32
>/usr/local/lib"
> else
> sys_lib_search_path_spec="/usr/lib/hpux64 /usr/local/lib/hpux64"
> fi
> sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
> ! ;;
> ! hppa*64*)
> ! hardcode_into_libs=yes
> ! dynamic_linker="$host_os dld.sl"
> ! shlibpath_var=LD_LIBRARY_PATH # How should we handle SHLIB_PATH
> ! shlibpath_overrides_runpath=yes # Unless +noenvvar is specified.
> ! library_names_spec='${libname}${release}.sl$versuffix
>${libname}${release}.sl$major $libname.sl'
> ! soname_spec='${libname}${release}.sl$major'
> ! sys_lib_search_path_spec="/usr/lib/pa20_64 /usr/ccs/lib/pa20_64"
> ! sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
> ! ;;
> ! *)
> dynamic_linker="$host_os dld.sl"
> shlibpath_var=SHLIB_PATH
> shlibpath_overrides_runpath=no # +s is required to enable SHLIB_PATH
> library_names_spec='${libname}${release}.sl$versuffix
>${libname}${release}.sl$major $libname.sl'
> soname_spec='${libname}${release}.sl$major'
> ! sys_lib_search_path_spec="/lib /usr/lib /usr/ccs/lib"
> ! sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
> ! ;;
> ! esac
> # HP-UX runs *really* slowly unless shared libraries are mode 555.
> postinstall_cmds='chmod 555 $lib'
> ;;
>
> irix5* | irix6* | nonstopux*)
> case $host_os in
> ***
> *** 1978,1996
> gnu*)
> lt_cv_deplibs_check_method=pass_all
> ;;
>
> hpux10.20* | hpux11*)
> lt_cv_file_magic_cmd=/usr/bin/file
> ! if test "$host_cpu" = ia64; then
> lt_cv_deplibs_check_method='file_magic
>(s[[0-9]][[0-9]][[0-9]]|ELF-[[0-9]][[0-9]]) shared object file - IA64'
> lt_cv_file_magic_test_file=/usr/lib/hpux32/libc.so
> ! else
> lt_cv_deplibs_check_method='file_magic
>(s[[0-9]][[0-9]][[0-9]]|PA-RISC[[0-9]].[[0-9]]) shared library'
>
Re: Add hppa*64* support to libtool (HEAD branch)
Bob,
No, but I am aware of the requirements. I've looked at the copyright
notice but I access the form. Can you please email me one.
Cheers,
Ross
-
Ross Alexander "We demand clearly defined
MIS - NEC Europe Limitedboundaries of uncertainty and
Work ph: +44 20 8752 3394 doubt."
Bob Friesenhahn
<[EMAIL PROTECTED]To:
[EMAIL PROTECTED]
llas.tx.us>cc: [EMAIL PROTECTED]
Subject: Re: Add hppa*64* support to
libtool (HEAD branch)
22/10/2002 17:01
Ross,
This patch seems to be pretty significant. Do you have paperwork
filed with the FSF which supports significant contributions to
libtool?
Bob
On Tue, 22 Oct 2002 [EMAIL PROTECTED] wrote:
>
> This patch was made against libtool.m4 version 1.268.
>
>
> ChangeLog
>
> 2002-10-22 Ross Alexander <[EMAIL PROTECTED]>
>
> * libtool.m4: Major reorganisation of the HPUX code to add support
> for
> the 64bit PA-RISC HPUX environment. The 64bit PA environment is
> based
> on the ELF-64 standard and is very similar to the IA64 HPUX system.
> From binutils-2.13 the GNU ld works with elf64hppa for both shared
> libraries and executables. The HPUX9 specific code has been
> seperated
> its own case in AC_LIBTOOL_LANG_CXX_CONFIG and
> AC_LIBTOOL_PROG_LD_SHLIBS.
>
>
>
> *** libtool.m4-head-1.268 Tue Oct 22 15:11:16 2002
> --- libtool.m4Tue Oct 22 13:10:45 2002
> ***
> *** 1248,1279
> hpux9* | hpux10* | hpux11*)
> # Give a soname corresponding to the major version so that dld.sl
refuses to
> # link against other versions.
> version_type=sunos
> need_lib_prefix=no
> need_version=no
> ! if test "$host_cpu" = ia64; then
> hardcode_into_libs=yes
> dynamic_linker="$host_os dld.so"
> shlibpath_var=LD_LIBRARY_PATH
> shlibpath_overrides_runpath=yes # Unless +noenvvar is specified.
> library_names_spec='${libname}${release}.so$versuffix ${libname}
${release}.so$major $libname.so'
> soname_spec='${libname}${release}.so$major'
> if test "X$HPUX_IA64_MODE" = X32; then
> sys_lib_search_path_spec="/usr/lib/hpux32 /usr/local/lib/hpux32
/usr/local/lib"
> else
> sys_lib_search_path_spec="/usr/lib/hpux64 /usr/local/lib/hpux64"
> fi
> sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
> ! else
> dynamic_linker="$host_os dld.sl"
> shlibpath_var=SHLIB_PATH
> shlibpath_overrides_runpath=no # +s is required to enable
SHLIB_PATH
> library_names_spec='${libname}${release}.sl$versuffix ${libname}
${release}.sl$major $libname.sl'
> soname_spec='${libname}${release}.sl$major'
> ! fi
> # HP-UX runs *really* slowly unless shared libraries are mode 555.
> postinstall_cmds='chmod 555 $lib'
> ;;
>
> irix5* | irix6* | nonstopux*)
> case $host_os in
> --- 1248,1294
> hpux9* | hpux10* | hpux11*)
> # Give a soname corresponding to the major version so that dld.sl
refuses to
> # link against other versions.
> version_type=sunos
> need_lib_prefix=no
> need_version=no
> ! case "$host_cpu" in
> ! ia64*)
> hardcode_into_libs=yes
> dynamic_linker="$host_os dld.so"
> shlibpath_var=LD_LIBRARY_PATH
> shlibpath_overrides_runpath=yes # Unless +noenvvar is specified.
> library_names_spec='${libname}${release}.so$versuffix ${libname}
${release}.so$major $libname.so'
> soname_spec='${libname}${release}.so$major'
> if test "X$HPUX_IA64_MODE" = X32; then
> sys_lib_search_path_spec="/usr/lib/hpux32 /usr/local/lib/hpux32
/usr/local/lib"
> else
> sys_lib_search_path_spec="/usr/lib/hpux64 /usr/local/lib/hpux64"
> fi
> sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
> ! ;;
> ! hppa*64*)
> ! hardcode_into_libs=yes
> ! dynamic_linker="$host_os dld.sl"
> ! shlibpath_var=LD_LIBRARY_PATH # How should we handle SHLIB_PATH
> ! shl
(no subject)
> From: Christoph Egger <[EMAIL PROTECTED]> > > Short bug description: I can't link against a framework, because libtool > throughs the needed -framework param away. I hit this problem once and created a patch for it, but it's non-trivial. Even if libtool recognizes it as a LDFLAG, libtool does this deplibs reversal to sort order or dependent libs and you start getting things like gcc -o this.dylib ... Cocoa -framework ... but it is possible. But is there a better solution maybe? CVS libtool (not sure about 1.4) has a handy -Xlinker escape for linker flags. Maybe try: libThis_la_LDFLAGS = -Xlinker -framework -Xlinker Cocoa Curious, Frank Francis James Franklin [EMAIL PROTECTED] `Medium atomic weights are available: Gold, Lead, Copper, Jet, Diamond, Radium, Sapphire, Silver and Steel. `Sapphire and Steel have been assigned...' ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool support for MSVC++ on WinNT
Is the MSVC++ compiler on WinNT supported? Can't seem to find any documents, except for a reference in libtool.m4. regards, jerry ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool support for MSVC++ on WinNT
On Tue, 22 Oct 2002, Iseri, Jerry wrote: > Is the MSVC++ compiler on WinNT supported? > Can't seem to find any documents, except for a reference > in libtool.m4. I expect that it used to work but that since support has not been maintained, maintenance is required before it will work again. Libltdl can't be built as a DLL using MSVC++ because the dllimport/export decorations were removed. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool on darwin #2
> > From: Christoph Egger <[EMAIL PROTECTED]> > > > > Short bug description: I can't link against a framework, because libtool > > throughs the needed -framework param away. > > I hit this problem once and created a patch for it, but it's non-trivial. > Even if libtool recognizes it as a LDFLAG, libtool does this deplibs > reversal to sort order or dependent libs and you start getting things like > > gcc -o this.dylib ... Cocoa -framework ... > > but it is possible. > > But is there a better solution maybe? CVS libtool (not sure about 1.4) has > a handy -Xlinker escape for linker flags. Maybe try: > > libThis_la_LDFLAGS = -Xlinker -framework -Xlinker Cocoa hey - That works! Thanks very much! -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Cygwin/MinGW patch applied to CVS head
2002-10-15 Charles Wilson <[EMAIL PROTECTED]> * libtool.m4 (AC_LIBTOOL_SYS_MAX_CMD_LEN): avoid long delay on cygwin/Win9x when computing commandline length. (AC_LIBTOOL_SYS_DYNAMIC_LINKER): fix postinstall_cmds when sources are in a subdirectory * ltdl.m4 (AC_LTDL_SYSSEARCHPATH): use $PATH_SEPARATOR, not $ac_path_separator * configure.ac: move depdemo-specific stuff. You must configure libtool before you can try './libtool --features'. * mdemo-inst.test: set $PATH to include the directory in which the modules are installed (on cygwin, DLL search path is the $PATH) == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [FIXED] cygwin: duplicate .o's in static libs
Charles, I think this fix was accidentally piggybacked on top of another patch I checked in. I knew it happened after the check in, but I thought I'd see if it fixed the problem rather than back it out or add a ChangeLog entry. I'll try to be more careful. ;) Rob -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: rboehne AT ricardo-us DOT com ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: About win32 impgen.c patch
Robert, Naofumi,
One of the things I am curious about is whether or not impgen.c is
going to be used very often in the future. I had been of the notion
that the latest set of patches more or less did away with the use of
that particular piece of code, although the code for impgen.c itself
has not been removed.
From what I understand, the newer gcc (and/or gnu ld) on win32 uses
an "auto import" feature, and the old way of importing symbols (via
compiling impgen.c) is no longer needed, although there was some
platform that still uses the older method (pc32 or something like
that; right under mingw in the C compiler case/select).
I personally would like to see impgen.c done away with altogether
eventually if possible, because it seems out of place - compiling a
bit of code to pull symbols out of a library. When cross-compiling,
this makes the job a little more difficult (difficult in the sense
that one must be a little more knowledgeable about what is happening
during the build [read: set HOST_CC to the native {build} compiler]).
If Bob is out there, Bob, when you build IM on MSYS using your
latest set of mingw-specific patches, is it using impgen.c any longer?
Regards, Elizabeth
Robert Boehne <[EMAIL PROTECTED]> writes:
> Naofumi,
>
> Your patch has not been approved, but it hasn't been
> rejected either. If you could briefly explain what
> the problem is and how your patch fixes it, I'd be
> glad to approve it. I'm reluctant to commit patches
> that I don't understand, and I'm not familiar with the
> reason you'd need to quote the string if it has the .
> character in it.
>
> Thanks,
>
> Robert
>
> Naofumi Yasufuku wrote:
> >
> > Hi,
> >
> > Can anybody tell me whether this impgen.c patch was approved?
> >
> > http://mail.gnu.org/pipermail/libtool-patches/2002-August/002073.html
> >
> > In gtkmm2 for win32, impgen cannot generate the correct import library
> > which contains a special symbol name includes '.' character.
> >
> > This patch fixes the problem.
> >
> > Regards,
> > --Naofumi
> >
> > ___
> > Libtool-patches mailing list
> > [EMAIL PROTECTED]
> > http://mail.gnu.org/mailman/listinfo/libtool-patches
>
>
> ___
> Libtool-patches mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/libtool-patches
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: About win32 impgen.c patch
On 22 Oct 2002, Elizabeth Barham wrote: >From what I understand, the newer gcc (and/or gnu ld) on win32 uses > an "auto import" feature, and the old way of importing symbols (via > compiling impgen.c) is no longer needed, although there was some > platform that still uses the older method (pc32 or something like > that; right under mingw in the C compiler case/select). Right. The impgen stuff is totally removed for MinGW and Cygwin but remains for 'pw32'. >If Bob is out there, Bob, when you build IM on MSYS using your > latest set of mingw-specific patches, is it using impgen.c any longer? Nope. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: About win32 impgen.c patch
I suppose that leaves one question (in my mind at least), and that is, What is pw32? Robert Bob Friesenhahn wrote: > > On 22 Oct 2002, Elizabeth Barham wrote: > > >From what I understand, the newer gcc (and/or gnu ld) on win32 uses > > an "auto import" feature, and the old way of importing symbols (via > > compiling impgen.c) is no longer needed, although there was some > > platform that still uses the older method (pc32 or something like > > that; right under mingw in the C compiler case/select). > > Right. The impgen stuff is totally removed for MinGW and Cygwin but > remains for 'pw32'. > > >If Bob is out there, Bob, when you build IM on MSYS using your > > latest set of mingw-specific patches, is it using impgen.c any longer? > > Nope. > > Bob > == > Bob Friesenhahn > [EMAIL PROTECTED] > http://www.simplesystems.org/users/bfriesen > > ___ > Libtool mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
