Re: support of the cegcc compiler
Hey,
In order to reasonably support this target, we need a volunteer who will
faithfully test libtool on that target and work to resolve issues. Are you
able to find a volunteer to support the cegcc compiler?
I am volunteer :-)
It seems that the cegcc compiler must work almost the same as the MinGW
compiler. I think that the main issue will be that libtool has a very
sophisticated test suite which may currently depend on some features which
are not in Windows CE. The test suite would need to be adapted to work
reasonably well for this target. Even now, there are still some test
failures with the MinGW compiler.
Here are some patch for supporting the cegcc. I know that i should send
them to [EMAIL PROTECTED] I put them here in case someone see
something wrong in them, and also because i would like to ask some
questions before:
1) how can I check libtool when doing cross compiling ? make check will
check libtool on my platform (say linux), right ? So i don't know what to
do to check libtool with cegcc
2) With those patches, libtool can now create dll's with cegcc. But I have
that message when it tries to create the dll of my lib:
*** Warning: linker path does not have real file for library -lws2.
etc... saying it can not create the shared lib of my lib because the
shared version of libws2 does not exist. Usually, there are 2 things to
do:
a) provide the dll associated to that static lib
b) pass -no-undefined (specific to Windows platform, not necessary on
linux) to libtool (add it in *_la_LDFLAGS in Makefile.am's, for example).
Of course, i added -no-undefined but there is no dll for libws2.
The only exception i found was with mingw and those static libraries. From
libtool version 1.5.24, it can create the dll of my lib, even if the dll
of those libraries (lwsock2, libiberty, etc...) do not exist. I recall
that with previous version (1.5.22 or maybe the one below), it can not.
Do you have some suggestions to fix this ?
thank you
Vincent Torri--- libltdl/m4/ltoptions.m4 2008-04-01 20:23:20.0 +0200
+++ ../libtool-2.2.3a/libltdl/m4/ltoptions.m4 2008-04-12 08:38:20.0
+0200
@@ -125,7 +125,7 @@
[enable_win32_dll=yes
case $host in
-*-*-cygwin* | *-*-mingw* | *-*-pw32*)
+*-*-cygwin* | *-*-mingw* | *-*-pw32* | *-cegcc*)
AC_CHECK_TOOL(AS, as, false)
AC_CHECK_TOOL(DLLTOOL, dlltool, false)
AC_CHECK_TOOL(OBJDUMP, objdump, false)
--- libltdl/m4/libtool.m4 2008-04-10 23:18:02.0 +0200
+++ ../libtool-2.2.3a/libltdl/m4/libtool.m4 2008-04-12 08:52:40.0
+0200
@@ -1503,7 +1503,7 @@
lt_cv_sys_max_cmd_len=-1;
;;
- cygwin* | mingw*)
+ cygwin* | mingw* | cegcc*)
# On Win9x/ME, this test blows up -- it succeeds, but takes
# about 5 minutes as the teststring grows exponentially.
# Worse, since 9x/ME are not pre-emptively multitasking,
@@ -1729,7 +1729,7 @@
lt_cv_dlopen_self=yes
;;
- mingw* | pw32*)
+ mingw* | pw32* | cegcc*)
lt_cv_dlopen=LoadLibrary
lt_cv_dlopen_libs=
;;
@@ -2190,14 +2190,14 @@
# libtool to hard-code these into programs
;;
-cygwin* | mingw* | pw32*)
+cygwin* | mingw* | pw32* | cegcc*)
version_type=windows
shrext_cmds=.dll
need_version=no
need_lib_prefix=no
case $GCC,$host_os in
- yes,cygwin* | yes,mingw* | yes,pw32*)
+ yes,cygwin* | yes,mingw* | yes,pw32* | yes,cegcc*)
library_names_spec='$libname.dll.a'
# DLL is installed to $(libdir)/../bin by postinstall_cmds
postinstall_cmds='base_file=`basename \${file}`~
@@ -2220,7 +2220,7 @@
soname_spec='`echo ${libname} | sed -e 's/^lib/cyg/'``echo ${release} |
$SED -e 's/[[.]]/-/g'`${versuffix}${shared_ext}'
sys_lib_search_path_spec=/usr/lib /lib/w32api /lib /usr/local/lib
;;
-mingw*)
+mingw* | cegcc*)
# MinGW DLLs use traditional 'lib' prefix
soname_spec='${libname}`echo ${release} | $SED -e
's/[[.]]/-/g'`${versuffix}${shared_ext}'
sys_lib_search_path_spec=`$CC -print-search-dirs | $GREP ^libraries: |
$SED -e s/^libraries:// -e s,=/,/,g`
@@ -2997,6 +2997,13 @@
fi
;;
+cegcc*)
+ # ?? shouldn't this be based no build_os, not host_os?
+ # use the weaker test based on 'objdump'. See mingw*.
+ lt_cv_deplibs_check_method='file_magic file format
pei*-arm-little(.*architecture: arm)?'
+ lt_cv_file_magic_cmd='$OBJDUMP -f'
+ ;;
+
darwin* | rhapsody*)
lt_cv_deplibs_check_method=pass_all
;;
@@ -3308,7 +3315,7 @@
aix*)
symcode='[[BCDT]]'
;;
-cygwin* | mingw* | pw32*)
+cygwin* | mingw* | pw32* | cegcc*)
symcode='[[ABCDGISTW]]'
;;
hpux*)
@@ -3554,7 +3561,7 @@
beos* | irix5* | irix6* | nonstopux* | osf3* | osf4* | osf5*)
# PIC is the default for these OSes.
;;
-mingw* | cygwin* | os2* | pw32*)
+mingw* | cygwin* | os2* | pw32* | cegcc*)
# This hack is so that the source file can tell whether it is being
# built for inclusion in a dll (and should export
Re: support of the cegcc compiler
2) With those patches, libtool can now create dll's with cegcc. But I have that message when it tries to create the dll of my lib: *** Warning: linker path does not have real file for library -lws2. etc... saying it can not create the shared lib of my lib because the shared version of libws2 does not exist. Usually, there are 2 things to do: a) provide the dll associated to that static lib b) pass -no-undefined (specific to Windows platform, not necessary on linux) to libtool (add it in *_la_LDFLAGS in Makefile.am's, for example). Of course, i added -no-undefined but there is no dll for libws2. The only exception i found was with mingw and those static libraries. From libtool version 1.5.24, it can create the dll of my lib, even if the dll of those libraries (lwsock2, libiberty, etc...) do not exist. I recall that with previous version (1.5.22 or maybe the one below), it can not. i've just found that page: http://home.wanadoo.nl/meilof/2004/12/index.html in the blog of the 13 december, a hack is given. I don't know if it is good or not at all, but maybe it can give some ideas Note that if I indeed comment the if statement, the dll is built regards Vincent ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: support of the cegcc compiler
On Sat, 12 Apr 2008, Vincent Torri wrote: 2) With those patches, libtool can now create dll's with cegcc. But I have that message when it tries to create the dll of my lib: *** Warning: linker path does not have real file for library -lws2. etc... saying it can not create the shared lib of my lib because the shared version of libws2 does not exist. Usually, there are 2 things to do: Generally it is demanded that any built DLLs only depend on DLLs (for obvious reasons such as duplicate symbols and intermixing of code types) but in the past there have been certain exceptions. For example, in the MinGW build, the C++ standard library did not support throwing exceptions out of a DLL so it was built as static. In that case libstdc++ was treated as a special case. At least that is how I remember it. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: support of the cegcc compiler
On Sat, 12 Apr 2008, Bob Friesenhahn wrote: On Sat, 12 Apr 2008, Vincent Torri wrote: 2) With those patches, libtool can now create dll's with cegcc. But I have that message when it tries to create the dll of my lib: *** Warning: linker path does not have real file for library -lws2. etc... saying it can not create the shared lib of my lib because the shared version of libws2 does not exist. Usually, there are 2 things to do: Generally it is demanded that any built DLLs only depend on DLLs (for obvious reasons such as duplicate symbols and intermixing of code types) but in the past there have been certain exceptions. For example, in the MinGW build, the C++ standard library did not support throwing exceptions out of a DLL so it was built as static. In that case libstdc++ was treated as a special case. At least that is how I remember it. But it's not the only case. All the static lib in mingw have no corresponding dll. And one can nevertheless build dll's when linking against them. Maybe I should ask that on the mingw mailing list too :) Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
_lt_libltdl_LTX_preloaded_symbols in consistence.
Hi, On MacOS X, 10.5.2, intel machine, the symbol _lt_libltdl_LTX_preloaded_symbols libraries (from the generated file libltdlS.o) is inconsistent with the symbol defined in ltdl.h, where the symbol is declared as _lt__PROGRAM__LTX_preloaded_symbols. This causes link time error. I fixed this problem by changing the name in the ltdl.h file to match the symbol in the libraries. Do you guys have a long term fix for that? steve ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: _lt_libltdl_LTX_preloaded_symbols in consistence.
Steven Wu wrote: Hi, On MacOS X, 10.5.2, intel machine, the symbol _lt_libltdl_LTX_preloaded_symbols libraries (from the generated file libltdlS.o) is inconsistent with the symbol defined in ltdl.h, where the symbol is declared as _lt__PROGRAM__LTX_preloaded_symbols. This causes link time error. I fixed this problem by changing the name in the ltdl.h file to match the symbol in the libraries. When linking libltdl? What are the errors that you saw? And what changes did you have to make? Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: _lt_libltdl_LTX_preloaded_symbols in consistence.
Here is the message: | I was building guile-1.8.4 on my macbook pro, and I found the linking | problem. Here is the configure command I typed: | ./configure --prefix=/usr --with-threads --enable-shared | | and here is the make.log tail: | | (cd .libs gcc -g -O2 -c -fno-builtin guileS.c) | rm -f .libs/guileS.c .libs/guile.nm .libs/guile.nmS .libs/guile.nmT | gcc -D_THREAD_SAFE -g -O2 -Wall -Wmissing-prototypes -Werror | .libs/guileS.o -D_THREAD_SAFE -o .libs/guile guile-guile.o | ./.libs/libguile.dylib -lintl -lgmp -lm -lltdl | Undefined symbols: | _lt__PROGRAM__LTX_preloaded_symbols, referenced from: | _lt__PROGRAM__LTX_preloaded_symbols$non_lazy_ptr in guile- guile.o | ld: symbol(s) not found | collect2: ld returned 1 exit status | make[3]: *** [guile] Error 1 | make[2]: *** [all] Error 2 | make[1]: *** [all-recursive] Error 1 | make: *** [all] Error 2 | I fixed it by changing the macro in ltdl.h from _lt__PROGRAM__LTX_preloaded_symbols to _lt_libltdl_LTX_preloaded_symbols. I found this symbol using nm on the libltdl.a and the shared library. steve On Apr 12, 2008, at 9:53 PM, Peter O'Gorman wrote: Steven Wu wrote: Hi, On MacOS X, 10.5.2, intel machine, the symbol _lt_libltdl_LTX_preloaded_symbols libraries (from the generated file libltdlS.o) is inconsistent with the symbol defined in ltdl.h, where the symbol is declared as _lt__PROGRAM__LTX_preloaded_symbols. This causes link time error. I fixed this problem by changing the name in the ltdl.h file to match the symbol in the libraries. When linking libltdl? What are the errors that you saw? And what changes did you have to make? Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: No need for object file removal before compilation
OK, this issue is much more intricate than it looked like at first.
First, the existing code had some bugs:
- it removed files too often. After the first compile, we *know* that
there are no files to stumble over; if the compiler doesn't know -c
-o, then we have moved away $output_obj ourselves.
- if the compiler doesn't grok '-c -o', it removed files when it may not
remove them: the lockfile and the $output_obj may only be removed with
a trap once we've obtained the lock. Further, if $obj = $output_obj,
then of course the same holds for $obj. Yuck.
OTOH, once we've obtained the lock, we should install that trap ASAP,
so that we don't leave a lockfile when interrupted.
Then, while I have some doubts about the practical applicability of
Bob's scenario, I left the code so that it would be supported: all
files we cause to be created are unlinked beforehand, except for the
eventual lock file of course.
I found another very tiny race: At the very end of func_mode_compile,
we remove the eventual lockfile before exiting. If the user happens to
interrupt libtool after that, but before exiting, our trap will remove,
among others, $output_obj. But that file may already be used by another
libtool instance, it could've grabbed the lock already. Fixed by
updating $removlist before removing the lockfile.
I would have been inclined to ok this one.
OK for the updated one? It makes for 5% faster
libtool --mode=compile gcc -c a.c
Thanks,
Ralf
2008-04-12 Ralf Wildenhues [EMAIL PROTECTED]
* libltdl/config/ltmain.m4sh (func_mode_compile): Avoid
redundant removal of old output files before compilation.
Do not remove $obj until we have successfully grabbed the
lockfile (in case the compiler doesn't grok `-c -o'), because
it might be identical to $output_obj.
At the end of the function, before we remove the lockfile,
update $removelist so that if the trap hits after the lockfile
has been removed, we do not accidentally remove $output_obj that
does not belong to us.
(func_write_libtool_object): Use $MV instead of mv.
Index: libltdl/config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.106
diff -u -r1.106 ltmain.m4sh
--- libltdl/config/ltmain.m4sh 11 Apr 2008 17:21:55 - 1.106
+++ libltdl/config/ltmain.m4sh 12 Apr 2008 06:55:46 -
@@ -650,7 +650,7 @@
non_pic_object=$write_oldobj
EOF
- mv -f ${write_libobj}T ${write_libobj}
+ $MV ${write_libobj}T ${write_libobj}
}
}
@@ -831,9 +831,6 @@
removelist=$lobj $libobj ${libobj}T
fi
-$opt_dry_run || $RM $removelist
-trap $opt_dry_run || $RM $removelist; exit $EXIT_FAILURE 1 2 15
-
# On Cygwin there's no real PIC flag so we must build both object types
case $host_os in
cygwin* | mingw* | pw32* | os2*)
@@ -850,8 +847,6 @@
if test $compiler_c_o = no; then
output_obj=`$ECHO X$srcfile | $Xsed -e 's%^.*/%%' -e
's%\.[^.]*$%%'`.${objext}
lockfile=$output_obj.lock
- removelist=$removelist $output_obj $lockfile
- trap $opt_dry_run || $RM $removelist; exit $EXIT_FAILURE 1 2 15
else
output_obj=
need_locks=no
@@ -881,17 +876,20 @@
$opt_dry_run || $RM $removelist
exit $EXIT_FAILURE
fi
+ removelist=$removelist $output_obj
$ECHO $srcfile $lockfile
fi
+$opt_dry_run || $RM $removelist
+removelist=$removelist $lockfile
+trap '$opt_dry_run || $RM $removelist; exit $EXIT_FAILURE' 1 2 15
+
if test -n $fix_srcfile_path; then
eval srcfile=\$fix_srcfile_path\
fi
func_quote_for_eval $srcfile
qsrcfile=$func_quote_for_eval_result
-$opt_dry_run || $RM $libobj ${libobj}T
-
# Only build a PIC object if we are building libtool libraries.
if test $build_libtool_libs = yes; then
# Without this assignment, base_compile gets emptied.
@@ -911,8 +909,6 @@
command=$command -o $lobj
fi
- $opt_dry_run || $RM $lobj $output_obj
-
func_show_eval_locale $command \
'test -n $output_obj $RM $removelist; exit $EXIT_FAILURE'
@@ -962,7 +958,6 @@
# Suppress compiler output if we already did a PIC compilation.
command=$command$suppress_output
- $opt_dry_run || $RM $obj $output_obj
func_show_eval_locale $command \
'$opt_dry_run || $RM $removelist; exit $EXIT_FAILURE'
@@ -998,6 +993,7 @@
# Unlock the critical section if it was locked
if test $need_locks != no; then
+ removelist=$lockfile
$RM $lockfile
fi
}
Re: No need for object file removal before compilation
* Ralf Wildenhues wrote on Sat, Apr 12, 2008 at 08:56:24AM CEST: OK for the updated one? It makes for 5% faster libtool --mode=compile gcc -c a.c I should be more precise: the above holds for an empty file a.c, measured using a script that calls the above 50 times, pre and post patch. I should also note that this patch introduces an inevitable race (of course all dealing with the no -c -o case): After we grabbed the lockfile, but before we install the trap to remove it, if the user interrupts libtool in between, we have a leftover lockfile. The next compile will barf out, but the error message will point the user towards the lockfile. This is benign, and IMNSHO unavoidable. Cheers, Ralf 2008-04-12 Ralf Wildenhues [EMAIL PROTECTED] * libltdl/config/ltmain.m4sh (func_mode_compile): Avoid redundant removal of old output files before compilation. Do not remove $obj until we have successfully grabbed the lockfile (in case the compiler doesn't grok `-c -o'), because it might be identical to $output_obj. At the end of the function, before we remove the lockfile, update $removelist so that if the trap hits after the lockfile has been removed, we do not accidentally remove $output_obj that does not belong to us. (func_write_libtool_object): Use $MV instead of mv.
Re: No need for object file removal before compilation
On Sat, 12 Apr 2008, Ralf Wildenhues wrote:
Then, while I have some doubts about the practical applicability of
Bob's scenario, I left the code so that it would be supported: all
Bob's scenarios are rarely practical.
I would have been inclined to ok this one.
OK for the updated one? It makes for 5% faster
libtool --mode=compile gcc -c a.c
The patch looks ok to me. We shall see about the actual performance
improvement.
Bob
Thanks,
Ralf
2008-04-12 Ralf Wildenhues [EMAIL PROTECTED]
* libltdl/config/ltmain.m4sh (func_mode_compile): Avoid
redundant removal of old output files before compilation.
Do not remove $obj until we have successfully grabbed the
lockfile (in case the compiler doesn't grok `-c -o'), because
it might be identical to $output_obj.
At the end of the function, before we remove the lockfile,
update $removelist so that if the trap hits after the lockfile
has been removed, we do not accidentally remove $output_obj that
does not belong to us.
(func_write_libtool_object): Use $MV instead of mv.
Index: libltdl/config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.106
diff -u -r1.106 ltmain.m4sh
--- libltdl/config/ltmain.m4sh 11 Apr 2008 17:21:55 - 1.106
+++ libltdl/config/ltmain.m4sh 12 Apr 2008 06:55:46 -
@@ -650,7 +650,7 @@
non_pic_object=$write_oldobj
EOF
- mv -f ${write_libobj}T ${write_libobj}
+ $MV ${write_libobj}T ${write_libobj}
}
}
@@ -831,9 +831,6 @@
removelist=$lobj $libobj ${libobj}T
fi
-$opt_dry_run || $RM $removelist
-trap $opt_dry_run || $RM $removelist; exit $EXIT_FAILURE 1 2 15
-
# On Cygwin there's no real PIC flag so we must build both object types
case $host_os in
cygwin* | mingw* | pw32* | os2*)
@@ -850,8 +847,6 @@
if test $compiler_c_o = no; then
output_obj=`$ECHO X$srcfile | $Xsed -e 's%^.*/%%' -e
's%\.[^.]*$%%'`.${objext}
lockfile=$output_obj.lock
- removelist=$removelist $output_obj $lockfile
- trap $opt_dry_run || $RM $removelist; exit $EXIT_FAILURE 1 2 15
else
output_obj=
need_locks=no
@@ -881,17 +876,20 @@
$opt_dry_run || $RM $removelist
exit $EXIT_FAILURE
fi
+ removelist=$removelist $output_obj
$ECHO $srcfile $lockfile
fi
+$opt_dry_run || $RM $removelist
+removelist=$removelist $lockfile
+trap '$opt_dry_run || $RM $removelist; exit $EXIT_FAILURE' 1 2 15
+
if test -n $fix_srcfile_path; then
eval srcfile=\$fix_srcfile_path\
fi
func_quote_for_eval $srcfile
qsrcfile=$func_quote_for_eval_result
-$opt_dry_run || $RM $libobj ${libobj}T
-
# Only build a PIC object if we are building libtool libraries.
if test $build_libtool_libs = yes; then
# Without this assignment, base_compile gets emptied.
@@ -911,8 +909,6 @@
command=$command -o $lobj
fi
- $opt_dry_run || $RM $lobj $output_obj
-
func_show_eval_locale $command\
'test -n $output_obj $RM $removelist; exit $EXIT_FAILURE'
@@ -962,7 +958,6 @@
# Suppress compiler output if we already did a PIC compilation.
command=$command$suppress_output
- $opt_dry_run || $RM $obj $output_obj
func_show_eval_locale $command \
'$opt_dry_run || $RM $removelist; exit $EXIT_FAILURE'
@@ -998,6 +993,7 @@
# Unlock the critical section if it was locked
if test $need_locks != no; then
+ removelist=$lockfile
$RM $lockfile
fi
}
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
switching to git, please no more CVS commits
Hello, please do not commit to CVS for now, until further notification. Thanks, Ralf
