FYI: SCO/bugfix patch 5 of 10: ltmain.in: exclude -lc on SCO platforms
Hi Tim, Albert, Kean, * Albert Chin wrote on Fri, Nov 04, 2005 at 06:07:48PM CET: > > Well, Tim said we do it for other platforms so I say we accept the > patch: > *-*-os2*) > # These systems don't actually have a C library (as such) > test "X$arg" = "X-lc" && continue > ;; Yes, agreed. * Tim Rice wrote on Fri, Nov 04, 2005 at 07:00:23PM CET: > On Fri, 4 Nov 2005, Ralf Wildenhues wrote: > > > Is gettext the only package that exposes this? Could you be bothered > > to write a bug report (or have already done so)? > > I don't know if gettext is the only one or not. > I just sent a patch to [EMAIL PROTECTED] Thank you. If you could post the outcome here, that would be nice. Since we need to check for the -lc part further down (where we've worked our way through all the deplibs), I've added the cases down there as well. While doing so, I noted that just copy-n-pasting is pretty much nonsense: $arg has no meaning when we're not in the argument parsing loop any more. Guess I messed that up last time as well. :-/ In any case, these are the patches I've added to CVS HEAD and branch-1-5. Please test that everything works as expected. Thanks, Ralf 2005-11-05 Kean Johnston <[EMAIL PROTECTED]>, Ralf Wildenhues <[EMAIL PROTECTED]> * libltdl/config/ltmain.m4sh (func_mode_link) [*-*-sco3.2v5*]: Don't pass through -lc, nor add it to deplibs. [*-*-sysv5*]: Ditto. [*-*-openbsd*, *-*-freebsd*, *-*-dragonfly*]: Remove bogus `$arg'. 2005-11-05 Kean Johnston <[EMAIL PROTECTED]>, Ralf Wildenhues <[EMAIL PROTECTED]> * libltdl/config/ltmain.m4sh (func_mode_link) [*-*-sco3.2v5*]: Don't pass through -lc, nor add it to deplibs. [*-*-sysv5*]: Ditto. [*-*-openbsd*, *-*-freebsd*, *-*-dragonfly*]: Remove bogus `$arg'. Index: libltdl/config/ltmain.m4sh === RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v retrieving revision 1.15 diff -u -r1.15 ltmain.m4sh --- libltdl/config/ltmain.m4sh 29 Oct 2005 14:21:02 - 1.15 +++ libltdl/config/ltmain.m4sh 5 Nov 2005 11:17:56 - @@ -2613,6 +2613,15 @@ # Rhapsody C and math libraries are in the System framework deplibs="$deplibs System.ltframework" continue + ;; + *-*-sco3.2v5* | *-*-sco5v6*) + # Causes problems with __ctype + test "X$arg" = "X-lc" && continue + ;; + *-*-sysv4.2uw2* | *-*-sysv5* | *-*-unixware* | *-*-OpenUNIX*) + # Compiler inserts libc in the correct place for threads to work + test "X$arg" = "X-lc" && continue + ;; esac elif test "X$arg" = "X-lc_r"; then case $host in @@ -4502,8 +4511,13 @@ ;; *-*-openbsd* | *-*-freebsd* | *-*-dragonfly*) # Do not include libc due to us having libc/libc_r. - test "X$arg" = "X-lc" && continue ;; + *-*-sco3.2v5* | *-*-sco5v6*) + # Causes problems with __ctype + ;; + *-*-sysv4.2uw2* | *-*-sysv5* | *-*-unixware* | *-*-OpenUNIX*) + # Compiler inserts libc in the correct place for threads to work + ;; *) # Add libc to deplibs on all other systems if necessary. if test "$build_libtool_need_lc" = "yes"; then 2005-11-05 Kean Johnston <[EMAIL PROTECTED]>, Ralf Wildenhues <[EMAIL PROTECTED]> * ltmain.in (link mode) [*-*-sco3.2v5*]: Don't pass through -lc, nor add it to deplibs. [*-*-sysv5*]: Ditto. [*-*-openbsd*, *-*-freebsd*, *-*-dragonfly*]: Remove bogus `$arg'. Index: ltmain.in === RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v retrieving revision 1.334.2.92 diff -u -r1.334.2.92 ltmain.in --- ltmain.in 29 Oct 2005 14:21:45 - 1.334.2.92 +++ ltmain.in 5 Nov 2005 11:18:13 - @@ -1495,6 +1495,15 @@ # Rhapsody C and math libraries are in the System framework deplibs="$deplibs -framework System" continue + ;; + *-*-sco3.2v5* | *-*-sco5v6*) + # Causes problems with __ctype + test "X$arg" = "X-lc" && continue + ;; + *-*-sysv4.2uw2* | *-*-sysv5* | *-*-unixware* | *-*-OpenUNIX*) + # Compiler inserts libc in the correct place for threads to work + test "X$arg" = "X-lc" && continue + ;; esac elif test "X$arg" = "X-lc_r"; then case $host in @@ -3375,7 +3384,12 @@ ;; *-*-openbsd* | *-*-freebsd* | *-*-dragonfly*) # Do not include libc due to us having libc/libc_r. - test "X$arg" = "X-lc" && continue + ;; + *-*-sco3.2v5* | *-*-sco5v6*) + # Causes problems with __c
Re: SCO/bugfix patch 5 of 10: ltmain.in: exclude -lc on SCO platforms
On Fri, 4 Nov 2005, Ralf Wildenhues wrote: > Is gettext the only package that exposes this? Could you be bothered > to write a bug report (or have already done so)? I don't know if gettext is the only one or not. I just sent a patch to [EMAIL PROTECTED] > > > Any reason this patch has not been added to CVS yet? > > Except above reasons, time for review is finite. ;) ^ That reason is always acceptable to me on volunteer projects. :-) > > Cheers, > Ralf > > -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
Re: SCO/bugfix patch 5 of 10: ltmain.in: exclude -lc on SCO platforms
On Fri, Nov 04, 2005 at 05:56:24PM +0100, Ralf Wildenhues wrote: > Hi Tim, Kean, > > * Tim Rice wrote on Thu, Nov 03, 2005 at 05:25:02PM CET: > > On Sun, 30 Oct 2005, Kean Johnston wrote: > > >Kean Johnston wrote: > > >> Patch 5 of 10 attached ... > > > > > >Tim caught a small ommission. A corrected patch is attached. > > Hmm. We're pretty wary of adding system-specifics to ltmain, and I do > agree with Albert that this ugly. OTOH, I do see the given negative > consequences, too. They are rather unacceptable. > > Is gettext the only package that exposes this? Could you be bothered > to write a bug report (or have already done so)? Well, Tim said we do it for other platforms so I say we accept the patch: *-*-os2*) # These systems don't actually have a C library (as such) test "X$arg" = "X-lc" && continue ;; -- albert chin ([EMAIL PROTECTED])
Re: SCO/bugfix patch 5 of 10: ltmain.in: exclude -lc on SCO platforms
Hi Tim, Kean, * Tim Rice wrote on Thu, Nov 03, 2005 at 05:25:02PM CET: > On Sun, 30 Oct 2005, Kean Johnston wrote: > >Kean Johnston wrote: > >> Patch 5 of 10 attached ... > > > >Tim caught a small ommission. A corrected patch is attached. Hmm. We're pretty wary of adding system-specifics to ltmain, and I do agree with Albert that this ugly. OTOH, I do see the given negative consequences, too. They are rather unacceptable. Is gettext the only package that exposes this? Could you be bothered to write a bug report (or have already done so)? > Any reason this patch has not been added to CVS yet? Except above reasons, time for review is finite. ;) Cheers, Ralf
Re: SCO/bugfix patch 5 of 10: ltmain.in: exclude -lc on SCO platforms
On Sun, 30 Oct 2005, Kean Johnston wrote: Kean Johnston wrote: > Patch 5 of 10 attached ... Tim caught a small ommission. A corrected patch is attached. Any reason this patch has not been added to CVS yet? -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] Rationale: On some releases of OpenServer 5, libc was poorly constructed and had static versions of __ctype. Due to a bug with copy relocations, linking a shared library with -lc would result in a shared library having one notion of __ctype, and the a.out having another. Thus, things like atoi() would behave differently inside the shared library versus the a.out. This is really bad. Also, there is no need to link in -lc, as it is always loaded by definition, as that is the RTLD and you cant have any form of dynamic ELF program without it. On OpenServer 6 and UnixWare, explicitly linking with -lc is even worse. The threads library is constructed in such a way that it provides several of the same functions that appear in libc. The version for libthread.so are the real, threads-safe versions. The versions that are in libc are stub versions that are present to allow programs to link, while still using simpler versions of things like mutexes and condition variables. In order for threads to work correctly, libc *must* be the very last library in the load order, so that those symbols that need it are resolved out of the threads library. If you explicitly link with -lc when creating a shared library, then libc is processed as a dependency when the shared library is loaded, and appears too early in the dependency chain. 2005-10-24 Kean Johnston <[EMAIL PROTECTED]> * ltmain.in(*-*-sco3.2v5*): Dont pass through -lc. (*-*-sysv5*): Ditto. Index: ltmain.in === RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v retrieving revision 1.334.2.91 diff -u -3 -p -r1.334.2.91 ltmain.in --- ltmain.in 18 Oct 2005 07:26:05 - 1.334.2.91 +++ ltmain.in 30 Oct 2005 21:22:25 - @@ -1494,6 +1495,15 @@ EOF # Rhapsody C and math libraries are in the System framework deplibs="$deplibs -framework System" continue + ;; + *-*-sco3.2v5* | *-*-sco5v6*) + # Causes problems with __ctype + test "X$arg" = "X-lc" && continue + ;; + *-*-sysv4.2uw2* | *-*-sysv5* | *-*-unixware* | *-*-OpenUNIX*) + # Compiler inserts libc in the correct place for threads to work + test "X$arg" = "X-lc" && continue + ;; esac elif test "X$arg" = "X-lc_r"; then case $host in
Re: SCO/bugfix patch 5 of 10: ltmain.in: exclude -lc on SCO platforms
Kean Johnston wrote: Patch 5 of 10 attached ... Tim caught a small ommission. A corrected patch is attached. Rationale: On some releases of OpenServer 5, libc was poorly constructed and had static versions of __ctype. Due to a bug with copy relocations, linking a shared library with -lc would result in a shared library having one notion of __ctype, and the a.out having another. Thus, things like atoi() would behave differently inside the shared library versus the a.out. This is really bad. Also, there is no need to link in -lc, as it is always loaded by definition, as that is the RTLD and you cant have any form of dynamic ELF program without it. On OpenServer 6 and UnixWare, explicitly linking with -lc is even worse. The threads library is constructed in such a way that it provides several of the same functions that appear in libc. The version for libthread.so are the real, threads-safe versions. The versions that are in libc are stub versions that are present to allow programs to link, while still using simpler versions of things like mutexes and condition variables. In order for threads to work correctly, libc *must* be the very last library in the load order, so that those symbols that need it are resolved out of the threads library. If you explicitly link with -lc when creating a shared library, then libc is processed as a dependency when the shared library is loaded, and appears too early in the dependency chain. 2005-10-24 Kean Johnston <[EMAIL PROTECTED]> * ltmain.in(*-*-sco3.2v5*): Dont pass through -lc. (*-*-sysv5*): Ditto. Index: ltmain.in === RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v retrieving revision 1.334.2.91 diff -u -3 -p -r1.334.2.91 ltmain.in --- ltmain.in 18 Oct 2005 07:26:05 - 1.334.2.91 +++ ltmain.in 30 Oct 2005 21:22:25 - @@ -1494,6 +1495,15 @@ EOF # Rhapsody C and math libraries are in the System framework deplibs="$deplibs -framework System" continue + ;; + *-*-sco3.2v5* | *-*-sco5v6*) + # Causes problems with __ctype + test "X$arg" = "X-lc" && continue + ;; + *-*-sysv4.2uw2* | *-*-sysv5* | *-*-unixware* | *-*-OpenUNIX*) + # Compiler inserts libc in the correct place for threads to work + test "X$arg" = "X-lc" && continue + ;; esac elif test "X$arg" = "X-lc_r"; then case $host in
SCO/bugfix patch 5 of 10: ltmain.in: exclude -lc on SCO platforms
Patch 5 of 10 attached ... Rationale: On some releases of OpenServer 5, libc was poorly constructed and had static versions of __ctype. Due to a bug with copy relocations, linking a shared library with -lc would result in a shared library having one notion of __ctype, and the a.out having another. Thus, things like atoi() would behave differently inside the shared library versus the a.out. This is really bad. Also, there is no need to link in -lc, as it is always loaded by definition, as that is the RTLD and you cant have any form of dynamic ELF program without it. On OpenServer 6 and UnixWare, explicitly linking with -lc is even worse. The threads library is constructed in such a way that it provides several of the same functions that appear in libc. The version for libthread.so are the real, threads-safe versions. The versions that are in libc are stub versions that are present to allow programs to link, while still using simpler versions of things like mutexes and condition variables. In order for threads to work correctly, libc *must* be the very last library in the load order, so that those symbols that need it are resolved out of the threads library. If you explicitly link with -lc when creating a shared library, then libc is processed as a dependency when the shared library is loaded, and appears too early in the dependency chain. 2005-10-24 Kean Johnston <[EMAIL PROTECTED]> * ltmain.in(*-*-sco3.2v5*): Dont pass through -lc. (*-*-sysv5*): Ditto. Index: ltmain.in === RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v retrieving revision 1.334.2.91 diff -u -3 -p -r1.334.2.91 ltmain.in --- ltmain.in 18 Oct 2005 07:26:05 - 1.334.2.91 +++ ltmain.in 30 Oct 2005 21:22:25 - @@ -1494,6 +1495,15 @@ EOF # Rhapsody C and math libraries are in the System framework deplibs="$deplibs -framework System" continue + ;; + *-*-sco3.2v5*) + # Causes problems with __ctype + test "X$arg" = "X-lc" && continue + ;; + *-*-sysv4.2uw2* | *-*-sysv5* | *-*-unixware* | *-*-OpenUNIX*) + # Compiler inserts libc in the correct place for threads to work + test "X$arg" = "X-lc" && continue + ;; esac elif test "X$arg" = "X-lc_r"; then case $host in
