Re: regeneration of files

[Peter O'Gorman]

On Oct 28, 2006, at 3:34 AM, Mike Stump wrote:


On Oct 26, 2006, at 6:40 PM, Mike Stump wrote:
The ones that were of particular interest were the libgfortran  
ones, Jack was trying to build on a G4 and had hopes they might  
fix his build.


Jack confirms that a regeneration of libgfortran fixed his build.   
He also reports that boehm-gc has the same problem.


gcc seems to have a few duplicate .m4 files, and has them in a number  
of different directories, thus making maintenance that much harder.  
Why not have just one copy of, e.g lib-link.m4in the tree in a well  
known location, then aclocal could be invoked with similar options  
everywhere.


Having multiple copies of the same files in the tree and using  
different versions of the autotools to generate other files in  
different subdirs is just asking fro trouble, don't you think?


Peter

Re: GCC 4.1: Buildable on GHz machines only?

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marc Espie wrote:
| How about replacing that piece of junk that is called libtool with
| something else ?
|
| Preferably something that works.


I will be happy to see your bug reports and/or patches. Whining on the gcc
list has never been known to fix a libtool bug.
Peter
- --
Peter O'Gorman - http://www.pogma.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)
iQCVAwUBQnY4v7iDAg3OZTLPAQI5wQP8Dwy/k5Oqx0LdWwrz1Yc+CafsVhlZ20sR
QzETUpZPIMyEWniL37/Sw0eu6PIKjOMZaOaHryvORRD9gparbc9fGtKxBWWmWmXX
AM3xUSqT6Uz2g//yzv/Kcly06q+T5n3i3D0esRNTlTrDV7baRp1BzylJx3GZP9Hl
RifpBmEMtko=
=O/yp
-END PGP SIGNATURE-

Re: GCC 4.1: Buildable on GHz machines only?

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Korn wrote:
|   Ok, here's a really *nasty* kludge:  libtool is basically a big script
| that generates command lines for the other tools based on passed-in args and
| local configure settings, yeh?  And a lot of the time it's used for lots and
| lots and lots of library files one after another in exactly the same way,
| yes?
<http://libtool-cache.sourceforge.net/>
Peter
- --
Peter O'Gorman - http://www.pogma.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)
iQCVAwUBQngOnriDAg3OZTLPAQItXAP+NTK3ye0bzQOAWMYlctBfADpVvvTa+cB8
4Ft4AkUwdIQ1hdUjq5aNWF2btksxD33rd3Idse5esLzeTY3zXajkqkFTJWc2HKlM
h9ZM/1lc6Q2mQq/bbzj2kAH+TRfck3jFQlkoOwo7gJB8xrDROMX0LdvpAKeN9DP0
n1hTLfwVweE=
=ZQUv
-END PGP SIGNATURE-

Re: GCC 4.1: Buildable on GHz machines only?

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joe Buck wrote:
| Richard Henderson showed that the libjava build spends 2/3 of its time
| in libtool, and that his hand-hacked (but not portable) modification to
| invoke the appropriate binutils commands directly gave a huge speedup.
| To me, 300% overhead means major breakage, so we need a better libtool.
| However, this better libtool might not yet exist.
Probably doesn't. Ralf has done lots of work on libtool HEAD, making it 20%
faster, but that will not be in a libtool release anytime soon.
Part of the problem here is the use of a convenienve library to hold several
thousand object files and then making a shared library with the convenience
library. On many platforms, those without a --whole-archive flag, libtool
will extract the convenience archive all over again. Linking the shared
library all in one go would be faster.
Peter
- --
Peter O'Gorman - http://www.pogma.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)
iQCVAwUBQngR9riDAg3OZTLPAQLUwwP+I+xq38TklAgu/YSi81QJn4UzbOCOrRro
5SWfj7QM9Os66QxpKp6Ds0l0lREr3p/ytj4OlHtZ4NeAMt33rD4j5KGaK3K83jbj
Qcij/uJHHoSe3KJftnoJg/9/RWAWlxhFTS5oJhgBOSpcdYtrdAdj9m2k1qV+BQum
q2ZuThhgd2c=
=lYSE
-END PGP SIGNATURE-

Re: GCC 3.4.4 RC1

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark Mitchell wrote:
| GCC 3.4.4 RC1 is available here:
|
| ftp://gcc.gnu.org/pub/gcc/prerelease-3.4.4-20050510/
|
| As usual, please test -- by using exactly those tarballs, so that we can
| detect packging errors.  Put problems into Bugzilla, and Cc: me.  At
| this point, the only problems that would block the release would be
| serious regressions from previous 3.4.x compilers.
|
Just noting that because of some changes made to darwin8 libraries:
"ld: Undefined symbols:
_fprintf$LDBLStub"
When trying to use gcc-3.4.4 to build libtool on powerpc-apple-darwin8.0.0
Surprisingly, the compiler actually built on darwin8 and even passed many of
it's tests.
Any @apple person want to backport the necessary bits to the 3.4 branch?
Peter
- --
Peter O'Gorman - http://www.pogma.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)
iQCVAwUBQoQGWLiDAg3OZTLPAQKG8wP+Pnhhg0A1uU5ZolIbaUhyZ7377VgLHqrq
BrXYTIB0m5obP0cQD2oMS5OrYnYZQSGzy8ngOaihygEmB1ySPl94poSA43+tUV48
Hz2jmy6U75FRngcdJ3W2+5JC3MsUOU8lj0ZcZNFHTm2DCJgiWHzo0rXOoN4JkfZl
wtA1J252Jpo=
=uiKy
-END PGP SIGNATURE-

Re: Mac OS X Panther to Tiger Build Changes for GCC 3.3 and 3.4

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mike Stump wrote:

| Anyway, I guess I would just recommend using 4.0 and ignoring the older
| releases if you can..  :-(

I think he has to, as far as I know the changes to use libSystemStubs on
tiger were never backported to 3.4 and 3.3.

Peter
- --
Peter O'Gorman - http://www.pogma.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQp5ojbiDAg3OZTLPAQKy6wQAmASPxSFY7pEFzccjIxOgxzkiLKRRfjC9
Y4uDGapKsdrfI+O+UCC6Q3Gx4hkcgfIMxA0BFLgVwuwfuIhZzPYGwSWTTnwg5GEf
a8gqVhQlrkQSBTGx5plWX9iWovqsfH3C9dWFqGbzRM0t8ePRpeYvlibNd9I6AAvE
l+BW1FC4FD8=
=8HJx
-END PGP SIGNATURE-

Re: Mac OS X Panther to Tiger Build Changes for GCC 3.3 and 3.4

[Peter O'Gorman]

Mike Stump wrote:

On Wednesday, June 1, 2005, at 07:01  PM, Peter O'Gorman wrote:


I think he has to, as far as I know the changes to use libSystemStubs on
tiger were never backported to 3.4 and 3.3.



If one uses fink to install the older compiler, it just works.  :-(


Fink patched their g77 package for tiger. As long as nobody uses assert() 
they'll be fine :/


 peter$ cat foo.c
#include 

int foo(const char * str)
{
  assert(str);
  return 1;
}
imac:~ peter$ /opt/gcc3.4/bin/gcc  -dynamiclib -o libfoo1.dylib foo.c
ld: Undefined symbols:
_fprintf$LDBLStub
/usr/bin/libtool: internal link edit command failed

Peter
--
Peter O'Gorman - http://www.pogma.com

Re: could gfortran be tested on Darwin regress builds of 4.1?

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bill Northcott wrote:
| On 30/07/2005, at 1:06 AM, Jack Howarth wrote:
|
|>Well the gcc4.info for the package containing gfortran in fink  has...
|
| The only thing I needed to add was gmp, which built from the source
| without problems.
|
| The cc-tools in Darwin 8 is 590.  So I think it would be a bad idea  to
| install 576!

Um, xcode-2.1 features cctools-590, darwin8 and Mac OS X 10.4.0, shipped
with cctools-576.

I too think that it would be great if Geoff could install gmp on the gcc
tester, but can understand his reasons for caution.

Peter

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQuquO7iDAg3OZTLPAQIIYwP9Hd2I4B4RFNZTx0KdCWfxYz++WE+d3mn3
LYXN1tV7KqwrMKIkm/Nk+DIFg+71FR4/DphJl8MN6IDrHGnPzYuWnlVbX1QAj6UZ
x/wbPp/q+2/iezfSuTmtRvKmzRnN8sFgb0S1Yit3nVOwt+NsNNh1iD+TWN4QO86M
2cwTzjBPff8=
=rd/3
-END PGP SIGNATURE-

Re: -b vs -bundle

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

James E Wilson wrote:
| Jack Howarth wrote:
|
|>   In compiling xplor-nih under the gcc/g++ of 4.1 branch instead
|> of Apple's gcc/g++ 4.0 compilers from Xcode 2.1, I noticed that the
|> gnu gcc compiler doesn't gracefully handle the -bundle flag. On Apple's
|> compiler I can have a Makefile entry like...
|
|
| This is PR 21366.
|
| You can always work around this by using -Wl,-bundle, which is the FSF
| solution to handling linker flags.  Or don't put -bundle first on the
| command line.

This is based very much on the work done previously by Geoff and Devang.

If this is okay, could the approver please commit, I do not have write access.

"Tested" as follows:
imac% ./xgcc -v
Using built-in specs.
Target: powerpc-apple-darwin8.2.0
Configured with: ../configure --enable-languages=c
Thread model: posix
gcc version 4.1.0 20050804 (experimental)
imac% ./xgcc -V4.0
xgcc: couldn't run './powerpc-apple-darwin8.2.0-gcc-4.0': No such file or
directory
imac% ./xgcc -V4.0 -bhello
xgcc: couldn't run './powerpc-apple-darwin8.2.0-gcc-4.0': No such file or
directory
imac% ./xgcc -V4.0 -bhello-there
xgcc: couldn't run './hello-there-gcc-4.0': No such file or directory
imac% ./xgcc -bhello-there
xgcc: couldn't run './hello-there-gcc-4.1.0': No such file or directory
imac% ./xgcc -bhello-there -V4.0
xgcc: couldn't run './hello-there-gcc-4.0': No such file or directory
imac% ./xgcc -bhello -V4.0
xgcc: '-V' must come at the start of the command line
imac% ./xgcc -V4.0 -bob
xgcc: couldn't run './powerpc-apple-darwin8.2.0-gcc-4.0': No such file or
directory
imac% ./xgcc  -bob
xgcc: unrecognized option '-bob'
xgcc: no input files
imac% ./xgcc  -bob-most
xgcc: couldn't run './ob-most-gcc-4.1.0': No such file or directory
imac% ./xgcc  why -bob-most
xgcc: '-b' must come at the start of the command line


Thanks,
Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQvINDbiDAg3OZTLPAQIkEQP+JNU3mHlOX5ZB0XXXltg7q+N8a9KX8N+o
TOsB3F2iJVjpWKEDWA1waJrmFeWSkdeozgRlcfU4QwAqGe5TiHlqFBSRGS2YPAwa
ag6NWDXdTP+FNyNGSwYud44CBH2+BakdoyPuR95VKP5bLoqu7KDVgKfJmRXyqM+o
R6aj4pthQRc=
=C9Iw
-END PGP SIGNATURE-
2005-08-04  Peter O'Gorman  <[EMAIL PROTECTED]>

PR 21366
* gcc.c (process_command): Check the argument to -b has a dash.

Index: gcc/gcc.c
===
RCS file: /cvs/gcc/gcc/gcc/gcc.c,v
retrieving revision 1.469
diff -u -3 -p -u -r1.469 gcc.c
--- gcc/gcc.c   3 Aug 2005 23:35:06 -   1.469
+++ gcc/gcc.c   4 Aug 2005 12:35:05 -
@@ -3175,9 +3175,12 @@ process_command (int argc, const char **
 }
 
   /* If there is a -V or -b option (or both), process it now, before
- trying to interpret the rest of the command line.  */
+ trying to interpret the rest of the command line. 
+ Use heuristic that all copnfiguration names must have at least
+ one dash '-'. This allows us to pass options starting with -b.  */
   if (argc > 1 && argv[1][0] == '-'
-  && (argv[1][1] == 'V' || argv[1][1] == 'b'))
+  && (argv[1][1] == 'V' || 
+((argv[1][1] == 'b') && (NULL != strchr(argv[1] + 2,'-')
 {
   const char *new_version = DEFAULT_TARGET_VERSION;
   const char *new_machine = DEFAULT_TARGET_MACHINE;
@@ -3187,7 +3190,8 @@ process_command (int argc, const char **
   int baselen;
 
   while (argc > 1 && argv[1][0] == '-'
-&& (argv[1][1] == 'V' || argv[1][1] == 'b'))
+&& (argv[1][1] == 'V' ||
+   ((argv[1][1] == 'b') && ( NULL != strchr(argv[1] + 2,'-')
{
  char opt = argv[1][1];
  const char *arg;
@@ -3608,6 +3612,7 @@ warranty; not even for MERCHANTABILITY o
  switch (c)
{
case 'b':
+ if (NULL == strchr(argv[i] + 2, '-')) break;
case 'V':
  fatal ("'-%c' must come at the start of the command line", c);
  break;

Re: -b vs -bundle

[Peter O'Gorman]

James E Wilson wrote:


This revised patch does appear to fix the only complaint that Geoff had
with the original patch.  I think it is OK with the typo fixed and the
addition of a doc change.


OK, done.
Thank you.

Peter
2005-08-??  Peter O'Gorman  <[EMAIL PROTECTED]>

PR 21366
* gcc.c (process_command): Check the argument to -b has a dash.
* doc/invoke.texi: Update -b and -V docs.

Index: gcc/gcc.c
===
RCS file: /cvs/gcc/gcc/gcc/gcc.c,v
retrieving revision 1.469
diff -u -3 -p -u -r1.469 gcc.c
--- gcc/gcc.c   3 Aug 2005 23:35:06 -   1.469
+++ gcc/gcc.c   5 Aug 2005 03:54:08 -
@@ -3175,9 +3175,12 @@ process_command (int argc, const char **
 }
 
   /* If there is a -V or -b option (or both), process it now, before
- trying to interpret the rest of the command line.  */
+ trying to interpret the rest of the command line. 
+ Use heuristic that all configuration names must have at least
+ one dash '-'. This allows us to pass options starting with -b.  */
   if (argc > 1 && argv[1][0] == '-'
-  && (argv[1][1] == 'V' || argv[1][1] == 'b'))
+  && (argv[1][1] == 'V' || 
+((argv[1][1] == 'b') && (NULL != strchr(argv[1] + 2,'-')
 {
   const char *new_version = DEFAULT_TARGET_VERSION;
   const char *new_machine = DEFAULT_TARGET_MACHINE;
@@ -3187,7 +3190,8 @@ process_command (int argc, const char **
   int baselen;
 
   while (argc > 1 && argv[1][0] == '-'
-&& (argv[1][1] == 'V' || argv[1][1] == 'b'))
+&& (argv[1][1] == 'V' ||
+   ((argv[1][1] == 'b') && ( NULL != strchr(argv[1] + 2,'-')
{
  char opt = argv[1][1];
  const char *arg;
@@ -3608,6 +3612,7 @@ warranty; not even for MERCHANTABILITY o
  switch (c)
{
case 'b':
+ if (NULL == strchr(argv[i] + 2, '-')) break;
case 'V':
  fatal ("'-%c' must come at the start of the command line", c);
  break;
Index: gcc/doc/invoke.texi
===
RCS file: /cvs/gcc/gcc/gcc/doc/invoke.texi,v
retrieving revision 1.664
diff -u -3 -p -u -r1.664 invoke.texi
--- gcc/doc/invoke.texi 3 Aug 2005 16:35:10 -   1.664
+++ gcc/doc/invoke.texi 5 Aug 2005 03:54:14 -
@@ -6943,14 +6943,16 @@ The argument @var{machine} specifies the
 The value to use for @var{machine} is the same as was specified as the
 machine type when configuring GCC as a cross-compiler.  For
 example, if a cross-compiler was configured with @samp{configure
-i386v}, meaning to compile for an 80386 running System V, then you
-would specify @option{-b i386v} to run that cross compiler.
+arm-elf}, meaning to compile for an arm processor with elf binaries,
+then you would specify @option{-b arm-elf} to run that cross compiler.
+Because there are other options beginning with @option{-b}, the
+configuration must contain a hyphen. 
 
 @item -V @var{version}
 @opindex V
 The argument @var{version} specifies which version of GCC to run.
 This is useful when multiple versions are installed.  For example,
[EMAIL PROTECTED] might be @samp{2.0}, meaning to run GCC version 2.0.
[EMAIL PROTECTED] might be @samp{4.0}, meaning to run GCC version 4.0.
 @end table
 
 The @option{-V} and @option{-b} options work by running the

Re: Problem building 3.3.6 (with 3.4.4): xgcc: cannot specify -o with -c or -S and multiple compilations

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andrew Walrond wrote:
| Can anybody explain what this error might mean?
|
| /tmp/gcc-3-3.heretix/work/gcc/xgcc "" -B/tmp/gcc-3-3.heretix/work/gcc/
- -nostdinc++
- -L/tmp/gcc-3-3.heretix/work/x86_64-unknown-linux-gnu/libstdc++-v3/src
- -L/tmp/gcc-3-3.heretix/work/x86
| _64-unknown-linux-gnu/libstdc++-v3/src/.libs
- -B/pkg/gcc-3-3/x86_64-unknown-linux-gnu/bin/
- -B/pkg/gcc-3-3/x86_64-unknown-linux-gnu/lib/ -isystem
/pkg/gcc-3-3/x86_64-unknown-linux-gnu/in
| clude -I../../../../gcc-3.3.6/libstdc++-v3/../gcc
- -I../../../../gcc-3.3.6/libstdc++-v3/../include
- 
-I/tmp/gcc-3-3.heretix/work/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unkno

| wn-linux-gnu
- -I/tmp/gcc-3-3.heretix/work/x86_64-unknown-linux-gnu/libstdc++-v3/include
- -I../../../../gcc-3.3.6/libstdc++-v3/libsupc++ -g -O2 -D_GNU_SOURCE
- -fno-implicit-templates -Wall
|  -Wno-format -W -Wwrite-strings -fdiagnostics-show-location=once
- -ffunction-sections -fdata-sections -c
../../../../gcc-3.3.6/libstdc++-v3/libsupc++/guard.cc  -fPIC -DPIC -o guard.o
| xgcc: cannot specify -o with -c or -S and multiple compilations
| make[4]: *** [guard.lo] Error 1

If you can run the libtool line above this one, with "sh -x" (e.g. sh -x
../libtool ...>& ltlog.txt) and send me the log privately, I should be able
to see if current libtool still has this issue (and maybe find a
workaround). Please don't send the log to this list.

Thanks,
Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQxMPN7iDAg3OZTLPAQIVSAQAjs/PX8FpcaFphCzfjnguP+sofbn/qsiO
ZGyFpx1ut1A+7e6PJ/tlzf9Df+sG43D2zeTjylD2FPG5A7YrypwrGpB+FzTlkRFR
UyKhapIYoGSnZ1cUlUh5jf1l0sM38FKc/fSKuWslT87a93x08oyWII76f2o/bVEz
B/NczxtkoA8=
=lLG3
-END PGP SIGNATURE-

Re: Running ranlib after installation - okay or not?

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Gerald Pfeifer wrote:
|>
|>Except that probably this has to get into libtool somehow or
|>something.  Hmmm.
|
|
| Ouch, now you got me scared.  I already started testing a patch to remove
| the ranlib invocations that are part of the installation, but I'm afraid
| that level of configury work described above execeed what I feel confident
| hacking.
|
| Is anyone else going to give it a try, or should it just file a Bugzilla?

Hi,
The problem is that libtool tries to run ranlib after install and that
ranlib can fail if the library is not writable? Note that on darwin running
ranlib on a 444 lib works and changes permissions to 644, remind me to file
a bug.

I would suggest continuing to run ranlib after install, but not failing if
it does not work. You need to look for the variable old_postinstall_cmds in
libtool.m4 and ltmain.m4sh (ltconfig and ltmain.sh in gcc??) and change
either how it is set or how it is run.

Another alternative would be to set RANLIB=: before configure if your system
does not need to ranlib anything.

Hope this helps,
Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQxZyhriDAg3OZTLPAQIpWgP9Fm5SHXP2X8CnpH7AAMkbSIcviisART3h
r9D4sXo4xLB253Yw8hxPsO1I6lQBTSUGV6cpK9C6eZEzb20u5YlqILe8x1jM/DDN
njjYOeY3Z9u7BQ0azKB8kE9FLzquDlpJ1hzJoBeKYYomFwilt5xXI+e74SPsskGf
I2naJmvC+yA=
=qEgR
-END PGP SIGNATURE-

Re: Running ranlib after installation - okay or not?

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Peter O'Gorman wrote:
| The problem is that libtool tries to run ranlib after install and that
| ranlib can fail if the library is not writable?

[crosspost - beware - for context see
<http://gcc.gnu.org/ml/gcc/2005-08/msg00937.html>]

When I look more closely at this, I see in libtool.m4:
old_postinstall_cmds='chmod 644 $oldlib'

and a little later:
old_postinstall_cmds="\$RANLIB \$oldlib~$old_postinstall_cmds"

Should that be:
old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB \$oldlib"
??

Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQxaND7iDAg3OZTLPAQIenwQAw+FtzccBDNnixZdjK8gdI0Zaxu3xpX0D
9jPOkhPZaGMshTHF77W7h2ZxLmqmNwvWTlGjHCnwZXBuY3nW2Lms+ow0AZ9V+eP3
ADFRfvmlnkmkxl/pDiLKYPyCfJucuae1mAF8DMmWHN6gS3AknP0n4imybOp3GULd
FbSpIRKclJ0=
=COg3
-END PGP SIGNATURE-

Re: Running ranlib after installation - okay or not?

[Peter O'Gorman]

Ralf Wildenhues wrote:

Should that be:
old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB \$oldlib"
??



Yes, I believe so (both CVS HEAD and branch-1-5).
Unless there exists ranlib's that change file mode..


Okay, the attached pathces are applied to libtool HEAD and branch-1-5.

Thank you,
Peter
2005-09-01  Peter O'Gorman  <[EMAIL PROTECTED]>

* libltdl/m4/libtool.m4 (old_postintall_cmds): chmod 644 before
running ranlib.
Reported by Gerald Pfeifer <[EMAIL PROTECTED]>

Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.10
diff -u -3 -p -u -r1.10 libtool.m4
--- libltdl/m4/libtool.m4   1 Sep 2005 14:16:08 -   1.10
+++ libltdl/m4/libtool.m4   1 Sep 2005 16:03:08 -
@@ -1200,10 +1200,10 @@ old_postuninstall_cmds=
 if test -n "$RANLIB"; then
   case $host_os in
   openbsd*)
-old_postinstall_cmds="\$RANLIB -t \$oldlib~$old_postinstall_cmds"
+old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB -t \$oldlib"
 ;;
   *)
-old_postinstall_cmds="\$RANLIB \$oldlib~$old_postinstall_cmds"
+old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB \$oldlib"
 ;;
   esac
   old_archive_cmds="$old_archive_cmds~\$RANLIB \$oldlib"
2005-09-01  Peter O'Gorman  <[EMAIL PROTECTED]>

* libtool.m4 (old_postintall_cmds): chmod 644 before running
ranlib.
Reported by Gerald Pfeifer <[EMAIL PROTECTED]>

Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.105
diff -u -3 -p -u -r1.314.2.105 libtool.m4
--- libtool.m4  31 Aug 2005 18:29:21 -  1.314.2.105
+++ libtool.m4  1 Sep 2005 16:04:15 -
@@ -176,10 +176,10 @@ old_postuninstall_cmds=
 if test -n "$RANLIB"; then
   case $host_os in
   openbsd*)
-old_postinstall_cmds="\$RANLIB -t \$oldlib~$old_postinstall_cmds"
+old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB -t \$oldlib"
 ;;
   *)
-old_postinstall_cmds="\$RANLIB \$oldlib~$old_postinstall_cmds"
+old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB \$oldlib"
 ;;
   esac
   old_archive_cmds="$old_archive_cmds~\$RANLIB \$oldlib"

Re: Running ranlib after installation - okay or not?

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andrew Pinski wrote:
|> Won't you then get warning messages on Darwin every time someone tries
|> to use the installed library (since the symbol table timestamp will be
|> older than the file timestamp)?
|
|
| It will not be a warning on darwin, it will be straight error as
| Darwin's linker does not like the timestamp to be out of date at
| all.

Doesn't matter, the solution I applied to GNU libtool cvs last night is
probably most appropriate, i.e. chmod 644 before ranlib. I guess I'll look
at gcc cvs over the weekend to figure out where that would go in your tree.

Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQxeQrLiDAg3OZTLPAQIZjQP9H3NKZd2r/AMNrqG+0pJ4WEdBgo8J/WUC
JZMY0l3JElo81UugL/2T5OOJvESmO6N5iiZj4blACg3m3cgPIuuFZ+K+UmV6rQW0
ypOauMYu6Un5SLlGV3KHm5qdLYqPPzyOLJfjCDvnNGcdBst0SG/jkfgiSAqq8hDt
c6YrkYmCWq0=
=dRag
-END PGP SIGNATURE-

Re: Running ranlib after installation - okay or not?

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Gerald Pfeifer wrote:
| We currently perform the following sequence of commands as part of the
| installation (-m 444 being the default on current FreeBSD systems).
|

I can not see where freebsd could be getting a -m 444 from. The libraries
are always installed with INSTALL_DATA and gcc's aclocal.m4 always sets that
to INSTALL_DATA='${INSTALL} -m 644' if it is otherwise unset.

Do have an INSTALL_DATA var set in your environment?

Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQxqoQLiDAg3OZTLPAQIZrQP+JbmY0U7m4HIS4MlAG0S58VQi6JUhGDZC
v0Q/qFAfs/aXLxt1MXg9Wlq9/q/Xuo1SUo7rWZgHqNMgYmbGikFo7X8jgX+CXCA6
T+gLGBHeW9k1f2gfr34DQSHCXhJbIg578NX0lSNo6ymktcuJs8h74lijKsaZgS9z
GZ9jRT2uetE=
=h+hN
-END PGP SIGNATURE-

Re: Running ranlib after installation - okay or not?

[Peter O'Gorman]

Gerald Pfeifer wrote:

On Sun, 4 Sep 2005, Peter O'Gorman wrote:


| We currently perform the following sequence of commands as part of the
| installation (-m 444 being the default on current FreeBSD systems).
I can not see where freebsd could be getting a -m 444 from. The libraries
are always installed with INSTALL_DATA and gcc's aclocal.m4 always sets that
to INSTALL_DATA='${INSTALL} -m 644' if it is otherwise unset.

Do have an INSTALL_DATA var set in your environment?



The FreeBSD ports system (/usr/share/mk/bsd.port.mk) indeed sets

  INSTALL_DATA= \
${INSTALL} ${COPY} ${_SHROWNGRP} -m ${SHAREMODE}

and SHAREMODE is set to 444 (in /usr/share/mk/bsd.own.mk).

Which does make sense, in general, but breaks ranlib without your fix.


I posted a patch that nobody has had time to look at for this, even if it is 
not acceptable (it would probably be better if it reset the permissions 
after calling ranlib) I'd appreciate some feedback :)


<http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00201.html>

Peter

Re: Fishy build system: make_exports.pl called on darwin?

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marcin Dalecki wrote:
|
| On 2005-10-03, at 00:26, Andrew Pinski wrote:
|
|>
|> This perl script works just fine for me on powerpc-darwin7.9.0  I  don't
|> see why are we piping the output to nm when it should be piping nm's
|> output to c++filt.
|>
|> Also this perl script works fine on powerpc-darwin7.4.0 also.
|
|
| Turns out it was rpm getting in the middle of the game for me... case
| closed.

I am quite curious as to how rpm got "in the middle of the game" here.
Please explain.

Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQ0CuEriDAg3OZTLPAQIj7gP/efOg0HzUQyg0Cwkf0/+pHPWyvwpLIYMq
PJCzIYikL9C3dn/pgtweMV2zEmwSlLHLl9x5QEgY9WfFdr0TZtInT6p2tiEI+ZQ2
z76JD9a8cYZ3TOLd9jJPzzJhDL8ToKgrXql3BiefZjx+hIonYibfQSmu/LO0IzQh
QbQBnseRW3o=
=8gfR
-END PGP SIGNATURE-

Re: Running ranlib after installation - okay or not?

[Peter O'Gorman]

Alexandre Oliva wrote:

On Sep 29, 2005, "Peter O'Gorman" <[EMAIL PROTECTED]> wrote:



I posted a patch that nobody has had time to look at for this, even if
it is not acceptable (it would probably be better if it reset the
permissions after calling ranlib) I'd appreciate some feedback :)




<http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00201.html>



I'd missed it, sorry.

The patch is ok, but it's not in yet because the format of the
ChangeLog entries will require manual application in every one of the
files, and that takes time.  If you'd repost the patch in a format
that enables it to be installed with say cl2patch, or even with the
raw ChangeLog diffs such that I use clcleanup and cl2patch to apply it
to the current tree, I'll check it in when the mainline policy allows
it.


Attached. Sorry I didn't do this in the first place.

Thank you,
Peter
Index: ChangeLog
2005-10-11  Peter O'Gorman  <[EMAIL PROTECTED]>

* ltconfig: chmod 644 before ranlib during install.

Index: ltconfig
===
RCS file: /cvs/gcc/gcc/ltconfig,v
retrieving revision 1.34
diff -u -3 -p -u -r1.34 ltconfig
--- ltconfig 16 Jul 2005 02:30:52 - 1.34
+++ ltconfig 11 Oct 2005 15:34:41 -
@@ -626,7 +626,7 @@ old_postuninstall_cmds=
 
 if test -n "$RANLIB"; then
   old_archive_cmds="$old_archive_cmds~\$RANLIB \$oldlib"
-  old_postinstall_cmds="\$RANLIB \$oldlib~$old_postinstall_cmds"
+  old_postinstall_cmds="~$old_postinstall_cmds~\$RANLIB \$oldlib"
 fi
 
 # Source the script associated with the $tagname tag configuration.
Index: gcc/ChangeLog
2005-10-11  Peter O'Gorman  <[EMAIL PROTECTED]>

* mklibgcc.in: chmod 644 before ranlib during install.

Index: gcc/mklibgcc.in
===
RCS file: /cvs/gcc/gcc/gcc/mklibgcc.in,v
retrieving revision 1.89
diff -u -3 -p -u -r1.89 mklibgcc.in
--- gcc/mklibgcc.in 2 Jul 2005 08:51:52 - 1.89
+++ gcc/mklibgcc.in 11 Oct 2005 15:34:43 -
@@ -796,12 +796,15 @@ for ml in $MULTILIBS; do
 ldir='$(DESTDIR)$(libsubdir)'
   fi
   echo '   $(INSTALL_DATA)' ${dir}/libgcc.a ${ldir}/
+  echo '   chmod 644'  ${ldir}/libgcc.a
   echo '   $(RANLIB_FOR_TARGET)' ${ldir}/libgcc.a
   echo '   $(INSTALL_DATA)' ${dir}/libgcov.a ${ldir}/
+  echo '   chmod 644'  ${ldir}/libgcov.a
   echo '   $(RANLIB_FOR_TARGET)' ${ldir}/libgcov.a
 
   if [ "$SHLIB_LINK" ]; then
 echo ' $(INSTALL_DATA)' ${dir}/libgcc_eh.a ${ldir}/
+echo ' chmod 644'  ${ldir}/libgcc_eh.a
 echo ' $(RANLIB_FOR_TARGET)' ${ldir}/libgcc_eh.a
 
 shlib_slibdir_qual=
@@ -820,6 +823,7 @@ for ml in $MULTILIBS; do
  -e "[EMAIL PROTECTED]@%$shlib_slibdir_qual%g"
   libunwinddir='$(DESTDIR)$(slibdir)$(shlib_slibdir_qual)/$(shlib_dir)'
   echo '   $(INSTALL_DATA)' ${dir}/libunwind.a ${libunwinddir}/
+  echo '   chmod 644' ${dir}/libunwind.a
   echo '   $(RANLIB_FOR_TARGET)' ${libunwinddir}/libunwind.a
 fi
   fi
Index: libiberty/ChangeLog
2005-10-11  Peter O'Gorman  <[EMAIL PROTECTED]>

* Makefile.in: chmod 644 before ranlib during install.

Index: libiberty/Makefile.in
===
RCS file: /cvs/gcc/gcc/libiberty/Makefile.in,v
retrieving revision 1.117
diff -u -3 -p -u -r1.117 Makefile.in
--- libiberty/Makefile.in 26 Sep 2005 20:55:10 - 1.117
+++ libiberty/Makefile.in 11 Oct 2005 15:34:56 -
@@ -280,7 +280,7 @@ install: install_to_$(INSTALL_DEST) inst
 install_to_libdir: all
${mkinstalldirs} $(DESTDIR)$(libdir)$(MULTISUBDIR)
$(INSTALL_DATA) $(TARGETLIB) 
$(DESTDIR)$(libdir)$(MULTISUBDIR)/$(TARGETLIB)n
-   ( cd $(DESTDIR)$(libdir)$(MULTISUBDIR) ; $(RANLIB) $(TARGETLIB)n )
+   ( cd $(DESTDIR)$(libdir)$(MULTISUBDIR) ; chmod 644 $(TARGETLIB)n 
;$(RANLIB) $(TARGETLIB)n )
mv -f $(DESTDIR)$(libdir)$(MULTISUBDIR)/$(TARGETLIB)n 
$(DESTDIR)$(libdir)$(MULTISUBDIR)/$(TARGETLIB)
if test -n "${target_header_dir}"; then \
  case "${target_header_dir}" in \
@@ -302,7 +302,7 @@ MULTIOSDIR = `$(CC) $(LIBCFLAGS) -print-
 install_to_tooldir: all
${mkinstalldirs} $(DESTDIR)$(tooldir)/lib/$(MULTIOSDIR)
$(INSTALL_DATA) $(TARGETLIB) 
$(DESTDIR)$(tooldir)/lib/$(MULTIOSDIR)/$(TARGETLIB)n
-   ( cd $(DESTDIR)$(tooldir)/lib/$(MULTIOSDIR) ; $(RANLIB) $(TARGETLIB)n )
+   ( cd $(DESTDIR)$(tooldir)/lib/$(MULTIOSDIR) ; chmod 644 $(TARGETLIB)n; 
$(RANLIB) $(TARGETLIB)n )
mv -f $(DESTDIR)$(tooldir)/lib/$(MULTIOSDIR)/$(TARGETLIB)n 
$(DESTDIR)$(tooldir)/lib/$(MULTIOSDIR)/$(TARGETLIB)
@$(MULTIDO) $(FLAGS_TO_PASS)

Re: coding system in ChangeLog text

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

DJ Delorie wrote:
| What coding system are we following in ChangeLogs?  We're starting to
| collect various 8-bit characters in people's names (which is a good
| sign, I suppose) but Emacs complained that it couldn't figure out the
| encoding this last time around.  A quick egrep shows a mix of
| obviously iso-latin-1 characters and things that look like wide
| characters.
|
| For example, just today:
|
| Rafael \201\201vila de Esp\201\201­ndola
<[EMAIL PROTECTED]>
|
| And compare:
|
| 1998: Martin von Lwis  <[EMAIL PROTECTED]>
| 2000: Martin v. Lwis  <[EMAIL PROTECTED]>
|

See this thread:


Or for the summary, Latin-1 should be used.

Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQ8x4XbiDAg3OZTLPAQIQ8QP/WsXxSY2eASwCiG+mA3QV89LBVxstsV5N
4s+5CmnfPAsNA2wGi1IZtTCEBxRtvjpMZ0yP7Os0f4zpCt69KP26ckQukXx0Z89g
hcvjPd+/PusBASddDdo9vSMIhDe5CYYeB2P4XSijImzyjfRwNYUhst/hcQMmSKyi
hTOnQ8Na+rg=
=q9Nz
-END PGP SIGNATURE-

Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Eric Botcazou wrote:
|>Yes the workaround is to add -fexceptions or -shared-libgcc to the
|>command line when linking libgnat but I don't know if that is the correct
|>fix or some hacking to config/darwin.h is needed.
|
|
| Thanks.  However, that's not sufficient because the tools fail to build too:

I'm adding Geoff Keating to the CC, hoping that he'll both shout at me while
explaining why this change to darwin.h is broken, and suggest a real fix.

This change allows gcc to build on powerpc-apple-darwin8.4 with ada.

Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQ8/HhbiDAg3OZTLPAQJpowQAnZLRilL7mE1l9LLwETXKWYFarWC+2DSl
J00YAywB5cDF+J1emf3ET7S4ZFgZ1Wvl9fJVutvgnVTWkvnnBm8nI+hFSHY93dUZ
9jK7/dyzWUQol4kG55bmNJDNjxr0wSx27RHafo6ktxQF0CwXQN+nzGJo9AU6mnaf
foTpzV+E64s=
=NJtm
-END PGP SIGNATURE-
Index: gcc/config/darwin.h
===
--- gcc/config/darwin.h (revision 109965)
+++ gcc/config/darwin.h (working copy)
@@ -324,6 +324,7 @@
-lgcc; \
   :%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= -lgcc_s.10.4) \
%:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5)   \
+   %:version-compare(!> 10.3.9 mmacosx-version-min= -lgcc_eh) \
-lgcc}"
 
 /* We specify crt0.o as -lcrt0.o so that ld will search the library path.  */

Re: Autoconf 2.64 broken on FreeBSD 10.0

[Peter O'Gorman]

On 11/15/2011 04:18 PM, Andreas Tobler wrote:

On 15.11.11 23:08, Andreas Schwab wrote:

Andreas Tobler writes:


libtool.m4 change:
--
case $host_os in
- freebsd[[123]]*) objformat=aout ;;
+ freebsd[[23]].*) objformat=aout ;;


If you match the dot explicitly anyway you can leave the 1 in the set.


Yep. I just took the part which is already in upstream libtool.m4.


Yeah, support for freebsd1 was supposedly removed from libtool some time 
ago, but there were bits that were missed.


The patch to make freebsd10 not break is:

http://git.savannah.gnu.org/cgit/libtool.git/patch/?id=49ae2888b43cad358e2ff60a69722341116e7b40

The change is in the latest released libtool also.

Peter

odcctools-2009-08-08

[Peter O'Gorman]

Hi,

I spent some time a month or so ago bringing odcctools up to the latest
Xcode-3.1.2 source release. I had planned to do more, but got distracted
by work etc. So I thought I had better make some kind of release of what
I had done.

This release is only minimally tested, I built a couple of "hello world"
type programs on my linux/x86 system and ran them on my darwin/x86
machine without problems using both a gcc cross compiler and clang. No
serious testing has been done. I have not tested it at all on darwin,
though it did at least build for me once, a few weeks ago.

Other notable things:
ld64 has a -force_load flag to load all members of specific archives.
(this is a feature from the iphoneos 3.0 source release).
ld64 will use libLTO if configure detects it.
Builds as for all 5 arches.
requires libuuid.

I don't have much time to devote to odcctools, however if you have
problems, please do email me. If you want the problems fixed soon,
sending patches will help.

This release wouldn't have been possible without the previous work of
Shantonu Sen, and Apple's release of the source code for all the
projects that are required to build ld64 and cctools (I hope the sources
for the new projects that are required to build the ld64/cctools for Mac
OS X 10.6 are also made available when that is released).

The tarball is available here (yes, it is just checked in to svn):
http://svn.macosforge.org/repository/odcctools/release/odcctools-20090808.tar.bz2
SHA1 sum is:
8099a75396d5ac1621f04c977212067d97e3c540

The svn repository is hosted at macosforge.org
(http://svn.macosforge.org/repository/odcctools/trunk/).

Thanks,
Peter
-- 
Peter O'Gorman
http://pogma.com

Re: the cause of PR41260 is new additional epilog unwind information

[Peter O'Gorman]

Joseph S. Myers wrote:
> On Fri, 18 Sep 2009, Jack Howarth wrote:
> 
>>I can confirm that the second proposed solution of passing 
>> -Wl,-no_compact_unwind
>> to the linkage of the g++.dg/torture/stackalign/eh-vararg-2.C test cases 
>> eliminates
>> the execution error on x86_64-apple-darwin10 so that option works. This 
>> leads to a
>> dejagnu question. I want to do a quick and dirty test to see that 
>> -Wl,-no_compact_unwind
>> suppresses all of the regressions that appeared at r147995, however I can't 
>> puzzle out
>> how to formulate...
>>
>> make -k check RUNTESTFLAGS="--target_board=unix'{-Wl,-no_compact_unwind}'"
>>
>> such that -Wl,-no_compact_unwind is interpreted as a single run with
>> one flag being passed (ie not one run with -Wl and one run with
>> -no_compact_unwind). Any ideas?
> 
> The -Xlinker spelling may be useful - try 
> "--target_board=unix/-Xlinker/-no_compact_unwind".
> 

Or try building with this patch (it always adds -no_compact_unwind with
-lSystem for 10.6 and later, but beware mailer wrapping). I didn't test
it because mainline fails to build for me, dsymutil crashes so
'configure: error: cannot compute sizeof (long long)'.

Peter


Index: gcc/config/darwin.h
===
--- gcc/config/darwin.h (revision 151878)
+++ gcc/config/darwin.h (working copy)
@@ -372,7 +372,9 @@

 /* Machine dependent libraries.  */

-#define LIB_SPEC "%{!static:-lSystem}"
+#define LIB_SPEC "%{!static:\
+   %:version-compare(>= 10.6 mmacosx-version-min=
-no_compact_unwind)  \
+   -lSystem}"

 /* Support -mmacosx-version-min by supplying different (stub)
libgcc_s.dylib
libraries to link against, and by not linking against libgcc_s on

Re: specs question.

[Peter O'Gorman]

On 04/12/2010 07:01 PM, IainS wrote:

> 
> It clearly depends on something no-obvious.
> 
> gcc hello.c  -g -o hc  => dsymutils gets run  (not expected from the
> syntax, assuming that sources are irrelevant)
> 
> gcc hello.o -g -o hc  => no dsymutils (expected from the absence of '.o'
> in the list)

Hi Iain,

We don't want to run dsymutil if there are .o files, let the developer
do that.

If someone just does gcc -g -o foo foo.c, then any debugging information
will be lost when the temporary .o file is removed, thus, to allow
debugging such a foo, the compiler must run dsymutil.

Of course, it doesn't need to run for stabs, or -g0.

Strange, Apple's gcc-4.2 doesn't have this bug (-lm), yet that portion
of the specs appears identical.

Peter

Re: libstdc++, gdb and darwin

[Peter O'Gorman]

Jack Howarth wrote:
> On Tue, Aug 05, 2008 at 11:31:13AM -0500, Peter O'Gorman wrote:
>> Jack Howarth wrote:
>>> Does anyone know why gdb appears to be unable to find the debug 
>>> information
>>> for libstdc++ in gcc 4.3 and gcc trunk on darwin9? This has been reported 
>>> before
>>> as...
>>>
>>> https://trac.macports.org/ticket/16102
>>>
>>> Under current gcc trunk, using Apple's current Xcode 3.1's gdb reports the
>>> errors of the form...
>>>
>>> warning: Could not find object file
>>> "/sw/src/fink.build/gcc44-4.3.999-20080803/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/libstdc++.lax/libmath.a/signbit.o"
>>> - no debug information available for
>>> "../../../../gcc-4.4-20080803/libstdc++-v3/libmath/signbit.c".
>>>
>>> when I try to run a binary linked to libstdc++ in gdb. My gcc build 
>>> directory doesn't
>>> have a libstdc++.lax directory left in it. Is this a flaw in the .la files 
>>> for gcc?
>>> Thanks in advance for any advice. I am trying to puzzle out if this is a 
>>> gcc bug or
>>> a gdb bug so that I can file a radar report against gdb if it is the later.
>>>  Jack
>>>
>> The debug information is stored in the object files. Libtool uses a
>> convenience library, and, because darwin's linked does not have the
>> equivalent of --whole-archive --no-whole-archive to ensure that all
>> members of specific archives are loaded, it unpacks the archive and adds
>> all the objects. Having created the output, it then deletes these
>> objects, leaving the debugger with no object files.
>>
>> This is "fixed" in recent GNU libtool by calling dsymutil on the newly
>> created shared library. I have not checked if gcc's version of libtool
>> has this change. I'll check when I have time and submit a patch if that
>> is not the case.


> Peter,
>I am still seeing this problem with the current gcc trunk after the
> libtool update. Are we still messing some additional changes for darwin
> to eliminate these problems with Apple's gdb not properly finding the
> object files for libstdc++?
> Jack

Hi Jack,

How are you starting GDB? Is your build tree still around with all the
object files in it?

Peter
-- 
Peter O'Gorman
http://pogma.com

Re: libstdc++, gdb and darwin

[Peter O'Gorman]

Jack Howarth wrote:
> On Fri, Oct 03, 2008 at 08:29:40PM -0500, Peter O'Gorman wrote:
>> Jack Howarth wrote:
>>> On Tue, Aug 05, 2008 at 11:31:13AM -0500, Peter O'Gorman wrote:
>>>> Jack Howarth wrote:
>>>>> Does anyone know why gdb appears to be unable to find the debug 
>>>>> information
>>>>> for libstdc++ in gcc 4.3 and gcc trunk on darwin9? This has been reported 
>>>>> before
>>>>> as...
>>>>>
>>>>> https://trac.macports.org/ticket/16102
>>>>>
>>>>> Under current gcc trunk, using Apple's current Xcode 3.1's gdb reports the
>>>>> errors of the form...
>>>>>
>>>>> warning: Could not find object file
>>>>> "/sw/src/fink.build/gcc44-4.3.999-20080803/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/libstdc++.lax/libmath.a/signbit.o"
>>>>> - no debug information available for
>>>>> "../../../../gcc-4.4-20080803/libstdc++-v3/libmath/signbit.c".
>>>>>
>>>>> when I try to run a binary linked to libstdc++ in gdb. My gcc build 
>>>>> directory doesn't
>>>>> have a libstdc++.lax directory left in it. Is this a flaw in the .la 
>>>>> files for gcc?
>>>>> Thanks in advance for any advice. I am trying to puzzle out if this is a 
>>>>> gcc bug or
>>>>> a gdb bug so that I can file a radar report against gdb if it is the 
>>>>> later.
>>>>>  Jack
>>>>>
>>>> The debug information is stored in the object files. Libtool uses a
>>>> convenience library, and, because darwin's linked does not have the
>>>> equivalent of --whole-archive --no-whole-archive to ensure that all
>>>> members of specific archives are loaded, it unpacks the archive and adds
>>>> all the objects. Having created the output, it then deletes these
>>>> objects, leaving the debugger with no object files.
>>>>
>>>> This is "fixed" in recent GNU libtool by calling dsymutil on the newly
>>>> created shared library. I have not checked if gcc's version of libtool
>>>> has this change. I'll check when I have time and submit a patch if that
>>>> is not the case.
>>
>>> Peter,
>>>I am still seeing this problem with the current gcc trunk after the
>>> libtool update. Are we still messing some additional changes for darwin
>>> to eliminate these problems with Apple's gdb not properly finding the
>>> object files for libstdc++?
>>> Jack
>> Hi Jack,
>>
>> How are you starting GDB? Is your build tree still around with all the
>> object files in it?
>>
>> Peter
>> -- 
>> Peter O'Gorman
>> http://pogma.com
> 
> Peter,
>If I compile a short c++ program like...
> 
> #include 
> using namespace std;
> main()
> {
>   cout << "Hello World!" << endl;   cout << "Welcome to C++ Programming" << 
> endl; }
> 
> with the g++ compiler from gcc trunk and execute...
> 
> gdb a.out
> 
> ...using the Xcode 3.1.1 gdb under MacOS X 10.5.5 on Macintel, I get...
> 
> warning: Could not find object file 
> "/sw/src/fink.build/gcc44-4.3.999-20081001/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/libstdc++.lax/libmath.a/signbit.o"
>  - no debug information available for 
> "../../../../gcc-4.4-20081001/libstdc++-v3/libmath/signbit.c".
> 
> ..etc. The build directory from my fink packaging is still remaining but I 
> get...
> 
> ls -l 
> /sw/src/fink.build/gcc44-4.3.999-20081001/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/libstdc++.lax/libmath.a/signbit.o
> ls: 
> /sw/src/fink.build/gcc44-4.3.999-20081001/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/libstdc++.lax/libmath.a/signbit.o:
>  No such file or directory
> 
> The 
> /sw/src/fink.build/gcc44-4.3.999-20081001/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/
>  directory exists but it
> doesn't contain a libstdc++.lax subdirectory.
> Jack


Jack,

Some libraries are created from GNU libtool convenience archives, on
darwin. Those used to be included in the archive with the -all_load flag
to the static linker, but this was not ideal, as the -all_load flag adds
every member of every archive to the output. So this was changed to the
current system where archives that need all members to be added to the
output are extra

Tru64 non-virtual thunks multiply defined

[Peter O'Gorman]

Hi,

When building qt-3.3.8 and wxGTk on Tru64 UNIX 5.1
(alphaev67-dec-osf5.1) with gcc-4.2.4, we got linker failures about
duplicate non-virtual thunks, e.g. from qt:
/usr/ccs/bin/ld:
.obj/release-shared-mt/qmotifdnd_x11.o: non-virtual thunk to 
QDragMoveEvent::~QDragMoveEvent(): multiply defined
.obj/release-shared-mt/qmotifdnd_x11.o: non-virtual thunk to 
QDragMoveEvent::~QDragMoveEvent(): multiply defined
.obj/release-shared-mt/qmotifdnd_x11.o: non-virtual thunk to 
QDragEnterEvent::~QDragEnterEvent(): multiply defined
.obj/release-shared-mt/qmotifdnd_x11.o: non-virtual thunk to 
QDragEnterEvent::~QDragEnterEvent(): multiply defined

This appears to be because the non-virtual thunks are not output weak on this
platform, so, those that appear in multiple objects will cause linker errors
like this (in the above case, there are _ZThn16_N14QDragMoveEventD0Ev and
_ZThn16_N14QDragMoveEventD1Ev in both qdnd_x11.o and qmotifdnd_x11.o).

Tru64 appears to have some weak symbol support, is there a reason that
these thunks are not weak? 

Peter
-- 
Peter O'Gorman
po...@thewrittenword.com

Re: Tru64 non-virtual thunks multiply defined

[Peter O'Gorman]

On Fri, Dec 19, 2008 at 11:32:22AM -0600, Peter O'Gorman wrote:
> Hi,
> 
> When building qt-3.3.8 and wxGTk on Tru64 UNIX 5.1
> (alphaev67-dec-osf5.1) with gcc-4.2.4, we got linker failures about
> duplicate non-virtual thunks, e.g. from qt:
> /usr/ccs/bin/ld:
> .obj/release-shared-mt/qmotifdnd_x11.o: non-virtual thunk to 
> QDragMoveEvent::~QDragMoveEvent(): multiply defined
> .obj/release-shared-mt/qmotifdnd_x11.o: non-virtual thunk to 
> QDragMoveEvent::~QDragMoveEvent(): multiply defined
> .obj/release-shared-mt/qmotifdnd_x11.o: non-virtual thunk to 
> QDragEnterEvent::~QDragEnterEvent(): multiply defined
> .obj/release-shared-mt/qmotifdnd_x11.o: non-virtual thunk to 
> QDragEnterEvent::~QDragEnterEvent(): multiply defined
> 
> This appears to be because the non-virtual thunks are not output weak on this
> platform, so, those that appear in multiple objects will cause linker errors
> like this (in the above case, there are _ZThn16_N14QDragMoveEventD0Ev and
> _ZThn16_N14QDragMoveEventD1Ev in both qdnd_x11.o and qmotifdnd_x11.o).
>

We did a regression hunt, since we knew it worked in 3.4.3 and failed in
4.2.4.

The problems start with r109149 - this patch:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01905.html

With this patch reverted we can build qt on Tru64 with gcc-4.2.4.

I have not yet built trunk on this platform, when I tired bootstrap
failed, will try again now, but I don't believe this has changed much
from 4.2.4.

Is this patch itself to blame, or does it simply expose a latent bug?

Will reverting this patch in the gcc that we ship cause any real
problems?

Thanks,
Peter
-- 
Peter O'Gorman
po...@thewrittenword.com

Re: Tru64 non-virtual thunks multiply defined

[Peter O'Gorman]

Hi Nathan,

Thanks for replying. I did not manage to get gcc trunk built on the
Tru64 machine to confirm that it is still a problem (out of memory in
stage2 compiling fold-const.c, but that's a whole different issue).

On Mon, Jan 05, 2009 at 06:15:07PM -0800, Nathan Sidwell wrote:
> Peter O'Gorman wrote:
> > Is this patch itself to blame, or does it simply expose a latent bug?
> 
> It is exposing a latent bug.  There was a bug where multiple 
> logically-distinct
> thunks were emitted even though they all had the same effect, and hence the 
> same
> names.
> 

I think I failed to be clear enough. Before this patch, thunks
pointing to weak functions on Tru64 were weak, after it, the functions 
remain weak, but the thunks are not. This is problematic.

For example, after compiling the attachment to PR38581:
% nm -Bw f.o | grep N3MI1D0 | c++filt
0x00 N  $_ZN3MI1D0Ev..ng
0x00 N  $_ZThn8_N3MI1D0Ev..ng
0x00 N  $_ZTv0_n32_N3MI1D0Ev..ng
0x000af8 T* MI1::~MI1()
0x000ae4 T  non-virtual thunk to MI1::~MI1()
0x000ac8 T  virtual thunk to MI1::~MI1()

Since the destructor is weak (the * indicates weak), the thunks should
also be, and when we revert your fix, they are, indeed, all weak.

We don't have this problem with the same compiler version on AIX, HP-UX,
IRIX, Linux or Solaris, and since you say that it's a latent bug, it
does seems likely to be some issue with just the Tru64/alpha target.

> > Will reverting this patch in the gcc that we ship cause any real
> > problems?
> 
> Yes, it may cause the thunks to be placed far from the thunked-to function and
> hence have jump range problems.  Perhaps that's not an issue on Tru64 though

Ok, depends on exactly how far away, I guess :). We haven't run into it,
so we can cross our fingers and hope. Until we can find the real bug
though it seems better for us to have a working compiler than a
semi-working one :/. 

Probably best to leave further discussion to the bug report now.

Thank you,
Peter
-- 
Peter O'Gorman
po...@thewrittenword.com

Re: Parma Polyhedra Library 0.10.1

[Peter O'Gorman]

Jack Howarth wrote:

>However if you look in ppl-0.10.1/src/Makefile.am, you will find...
> 
> #   PPL release -version-info
> #   0.1 -
> #   0.2 -
> #   0.3 0:0:0
> #   0.4 1:0:1
> #   0.5 2:0:0
> #   0.6 3:0:0
> #   0.7 4:0:0
> #   0.8 5:0:0
> #   0.9 6:0:0
> #   0.107:0:0
> #   0.10.1  8:0:1
> 
> So either Roberto meant to bump the soversion and
> forgot or changed his mind and didn't revert all of the
> soversion changes out before release.

I assume that there was some added API that caused the CURRENT version
number to increase. Since the soname did not change (AGE was also
bumped), anything that was built against version 0.10 will continue to
work with 0.10.1 without being rebuilt.

If there was no added API, and none removed, then only the revision
should have been touched, of course.

http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info

Peter

Re: Bootstrap broken on darwin / fink

[Peter O'Gorman]

Tobias Schlüter wrote:

> cc1: warnings being treated as errors
> ../../gcc/pretty-print.c: In function 'identifier_to_locale':
> ../../gcc/pretty-print.c:1016: error: passing argument 2 of 'libiconv'
> from incompatible pointer type
> /sw/include/iconv.h:83: note: expected 'char **' but argument is of type
> 'const char **'

This would probably have been more appropriate on a fink related mailing
list.

As Joseph pointed out, configure is finding a different iconv.h than the
compiler, and they provide different prototypes for iconv(). I suggest
looking at Jack Howarth's gcc package in fink to see what he's doing
with this.

Peter
-- 
Peter O'Gorman
http://pogma.com

gfortran requires input files for linking?

[Peter O'Gorman]

Hi,

The libtool-2.2.8 testsuite fails some tests on darwin10 with gfortran 
because it makes use of Apple ld's -force_load flag to load all members 
of convenience archives. One of the tests creates link lines like:


gfortran -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o 
.libs/liba12.0.dylib   -Wl,-force_load,./.libs/liba1.a 
-Wl,-force_load,./.libs/liba2.a -install_name /notexist/liba12.0.dylib 
-compatibility_version 1 -current_version 1.0 -Wl,-single_module


For which gfortran complains:
gfortran: no input files; unwilling to write output files

and exits with error.

On my linux system, it has a link line that, while similar, passes 
gfortran's test for input files:
gfortran -shared  -Wl,--whole-archive ./.libs/liba1.a ./.libs/liba2.a 
-Wl,--no-whole-archive  -L/usr/lib/gcc/i686-redhat-linux/4.4.4 
-L/usr/lib/gcc/i686-redhat-linux/4.4.4/../../.. -lgfortranbegin 
-lgfortran -lm -lc -lgcc_s-Wl,-soname -Wl,liba12.so.0 -o 
.libs/liba12.so.0.0.0


The only difference being that the archives are not -Wl, quoted.

Would the maintainers accept a patch that either
a) removes any checking for input files
or
b) warns instead of errors if it sees no input files

and which would be preferred?

Thanks,
Peter

HP-UX/PA_RISC gcc-4.4.5 multiple libgomp failures, help please

[Peter O'Gorman]

Hi,

We built gcc-4.4.5 on all our systems, but on hppa2.0w-hp-hpux11.31 (a
32 bit build of gcc) we found that, though the compiler was able to
build perl-5.12.2, the resulting perl did not pass its tests.

So, we ran the gcc testsuite, and it passed nearly everything until it
came to libgomp:
Running /opt/build/gcc-4.4.5/libgomp/testsuite/libgomp.c/c.exp ...
FAIL: libgomp.c/copyin-1.c execution test
FAIL: libgomp.c/copyin-3.c execution test
FAIL: libgomp.c/nested-2.c execution test
FAIL: libgomp.c/pr24455.c execution test
FAIL: libgomp.c/pr29947-2.c execution test
FAIL: libgomp.c/pr42942.c execution test
Running /opt/build/gcc-4.4.5/libgomp/testsuite/libgomp.c++/c++.exp ...
Pid 23693 in trap loop, signal 11
[snip]
Pid 771 in trap loop, signal 11
FAIL: libgomp.c++/ctor-9.C  -O3 -fomit-frame-pointer -funroll-loops
execution test
FAIL: libgomp.c++/for-1.C  -O1  execution test
FAIL: libgomp.c++/for-1.C  -O2  execution test
FAIL: libgomp.c++/for-1.C  -O3 -fomit-frame-pointer  execution test
Pid 930 in trap loop, signal 11
FAIL: libgomp.c++/for-1.C  -O3 -fomit-frame-pointer -funroll-loops
execution test
[snip]
Pid 15005 in trap loop, signal 11
FAIL: libgomp.fortran/task1.f90  -O0  execution test
Pid 15641 in trap loop, signal 11
Test Run By pogma on Thu Dec  2 19:18:38 2010
Native configuration is hppa2.0-hp-hpux11.31
=== libgomp Summary ===

# of expected passes2285
# of unexpected failures173
# of unsupported tests  9

GCC 4.4.5 on hppa-hp-hpux11.23 built with the same options etc, reports:
=== libgomp Summary ===

# of expected passes2458
# of unsupported tests  9

On hpux11.31, running the 11.23 built gcc etc. a lot of libgomp tests
fail again (the same gcc binaries that pass all their tests when run on
11.23).

Perl built with gcc-4.2.4 on hpux11.31 passes all its tests.

Perl built with gcc-4.4.5 and linked with -Wl,-B,immediate (similar
effect to setting LD_BIND_NOW at runtime) passes all its tests.
Similarly, export LDOPTS="-B immediate"; gmake check in libgomp passes
the tests.

Running individual tests does not fail, different tests fail on
different runs of the full libgomp testsuite (same with the perl
testsuite).

I would appreciate any hints etc. for where to look to find the
incompatibility between gcc-4.4 and hppa-hp-hpux11.31. I *think* it's
something to do with pthreads, but that's really just a guess, and I
don't know where to go from here.

Thanks,
Peter
-- 
Peter O'Gorman
po...@thewrittenword.com

Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

[Peter O'Gorman]

Geoff Keating wrote:


On 19/01/2006, at 9:08 AM, Peter O'Gorman wrote:

Eric Botcazou wrote:
|>Yes the workaround is to add -fexceptions or -shared-libgcc to the
|>command line when linking libgnat but I don't know if that is the  
correct

|>fix or some hacking to config/darwin.h is needed.
|
|
| Thanks.  However, that's not sufficient because the tools fail to  
build too:


I'm adding Geoff Keating to the CC, hoping that he'll both shout at  
me while
explaining why this change to darwin.h is broken, and suggest a  real 
fix.



If ADA is going to use exceptions, then it needs to do what G++ does,  
which is pass -shared-libgcc in its driver.


This change allows gcc to build on powerpc-apple-darwin8.4 with ada.


It's not OK because for forwards binary compatibility the shared  libgcc 
must be used for exception handling.


Okay.

The following patch allows the 4.1 branch to build ada on 
powerpc-apple-darwin8.4, okay? If so please apply as I do not have write access.


??-??-2006  Peter O'Gorman  <[EMAIL PROTECTED]>

* Makefile.in: Pass -static-libgcc when building tools,
and -shared-libgcc when building library on darwin.

Peter


Index: gcc/ada/Makefile.in
===
--- gcc/ada/Makefile.in (revision 110022)
+++ gcc/ada/Makefile.in (working copy)
@@ -1308,7 +1308,7 @@
 
   EH_MECHANISM=-gcc
   GNATLIB_SHARED = gnatlib-shared-darwin
-  SO_OPTS = -Wl,-flat_namespace
+  SO_OPTS = -Wl,-flat_namespace -shared-libgcc
   RANLIB = ranlib -c
   GMEM_LIB = gmemlib
   PREFIX_OBJS=$(PREFIX_REAL_OBJS)
@@ -1365,6 +1365,7 @@
 
 LIBGNAT=../rts/libgnat.a 
 GCC_LINK="$(CC) -static-libgcc $(ADA_INCLUDES)"
+TOOL_CC=$(CC) -static-libgcc
 
 # when compiling the tools, the runtime has to be first on the path so that
 # it hides the runtime files lying with the rest of the sources
@@ -1472,15 +1473,15 @@
 
 # Likewise for the tools
 ../../gnatmake$(exeext): $(P) b_gnatm.o link.o $(GNATMAKE_OBJS)
-   $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ b_gnatm.o $(GNATMAKE_OBJS) \
+   $(TOOL_CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ b_gnatm.o $(GNATMAKE_OBJS) \
  $(TOOLS_LIBS)
 
 ../../gnatlink$(exeext): $(P) b_gnatl.o link.o $(GNATLINK_OBJS)
-   $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ b_gnatl.o $(GNATLINK_OBJS) \
+   $(TOOL_CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ b_gnatl.o $(GNATLINK_OBJS) \
  $(TOOLS_LIBS)
 
 ../../gnatbl$(exeext): gnatbl.o
-   $(CC) -o $@ $(ALL_CFLAGS) $(LDFLAGS) gnatbl.o $(TOOLS_LIBS)
+   $(TOOL_CC) -o $@ $(ALL_CFLAGS) $(LDFLAGS) gnatbl.o $(TOOLS_LIBS)
 
 gnatbl.o: gnatbl.c adaint.h
$(CC) $(ALL_CFLAGS) $(INCLUDES) -c $< $(OUTPUT_OPTION)

Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

[Peter O'Gorman]

Arnaud Charlet wrote:
LIBGNAT=../rts/libgnat.a 
GCC_LINK="$(CC) -static-libgcc $(ADA_INCLUDES)"

+TOOL_CC=$(CC) -static-libgcc



I'd rather avoid code duplication and reuse GCC_LINK if possible, or
split GCC_LINK in two if needed.


I thought so too, and indeed tried it this way at first, but got:
"../../xgcc -B../../ -static-libgcc -I- -I../rts -I. 
-I/Users/peter/cvsco.build/gcc-4.1/gcc-4_1-branch/gcc/ada" -DIN_GCC


/bin/sh: line 1: ../../xgcc -B../../ -static-libgcc -I- -I../rts -I. 
-I/Users/peter/cvsco.build/gcc-4.1/gcc-4_1-branch/gcc/ada: No such file or 
directory


The quotes around GCC_LINK could be removed here and instead put in the the 
-GCC=$(GCC_LINK) bits, but it seemed easier to have a new var.


Peter

Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

[Peter O'Gorman]

Arnaud Charlet wrote:

I thought so too, and indeed tried it this way at first, but got:
"../../xgcc -B../../ -static-libgcc -I- -I../rts -I. 
-I/Users/peter/cvsco.build/gcc-4.1/gcc-4_1-branch/gcc/ada" -DIN_GCC


/bin/sh: line 1: ../../xgcc -B../../ -static-libgcc -I- -I../rts -I. 
-I/Users/peter/cvsco.build/gcc-4.1/gcc-4_1-branch/gcc/ada: No such file or 
directory


The quotes around GCC_LINK could be removed here and instead put in the the 
-GCC=$(GCC_LINK) bits,



Right, that seems easy enough to do, and I do prefer to keep a single
variable, used for all tools.



but it seemed easier to have a new var.



easier for who ? The person who writes the code or all the people who
have to read, understand and maintain it afterwards ?


Attached is a patch to the 4.1 branch, I think it will apply to mainline 
too. Branch built fine on powerpc-apple-darwin8.4.0 with c,ada enabled.


Peter
Index: gcc/ada/Makefile.in
===
--- gcc/ada/Makefile.in (revision 110115)
+++ gcc/ada/Makefile.in (working copy)
@@ -1308,7 +1308,7 @@
 
   EH_MECHANISM=-gcc
   GNATLIB_SHARED = gnatlib-shared-darwin
-  SO_OPTS = -Wl,-flat_namespace
+  SO_OPTS = -Wl,-flat_namespace -shared-libgcc
   RANLIB = ranlib -c
   GMEM_LIB = gmemlib
   PREFIX_OBJS=$(PREFIX_REAL_OBJS)
@@ -1364,7 +1364,7 @@
  s-[a-o]*.adb s-[p-z]*.adb s-[a-o]*.ads s-[p-z]*.ads  
 
 LIBGNAT=../rts/libgnat.a 
-GCC_LINK="$(CC) -static-libgcc $(ADA_INCLUDES)"
+GCC_LINK=$(CC) -static-libgcc $(ADA_INCLUDES)
 
 # when compiling the tools, the runtime has to be first on the path so that
 # it hides the runtime files lying with the rest of the sources
@@ -1388,74 +1388,74 @@
 ../../gnatchop$(exeext): 
$(GNATMAKE) -c $(ADA_INCLUDES) gnatchop --GCC="$(CC) $(ALL_ADAFLAGS)"
$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gnatchop 
-   $(GNATLINK) -v gnatchop -o $@ --GCC=$(GCC_LINK) $(TOOLS_LIBS)
+   $(GNATLINK) -v gnatchop -o $@ --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
 
 ../../gnat$(exeext): 
$(GNATMAKE) -c $(ADA_INCLUDES) gnatcmd --GCC="$(CC) $(ALL_ADAFLAGS)"
$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gnatcmd 
-   $(GNATLINK) -v gnatcmd -o $@ --GCC=$(GCC_LINK) $(TOOLS_LIBS)
+   $(GNATLINK) -v gnatcmd -o $@ --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
 
 ../../gnatkr$(exeext): 
$(GNATMAKE) -c $(ADA_INCLUDES) gnatkr --GCC="$(CC) $(ALL_ADAFLAGS)"
$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gnatkr 
-   $(GNATLINK) -v gnatkr -o $@ --GCC=$(GCC_LINK) $(TOOLS_LIBS)
+   $(GNATLINK) -v gnatkr -o $@ --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
 
 ../../gnatls$(exeext): 
$(GNATMAKE) -c $(ADA_INCLUDES) gnatls --GCC="$(CC) $(ALL_ADAFLAGS)"
$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gnatls 
-   $(GNATLINK) -v gnatls -o $@ --GCC=$(GCC_LINK) $(TOOLS_LIBS)
+   $(GNATLINK) -v gnatls -o $@ --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
 
 ../../gnatname$(exeext): 
$(GNATMAKE) -c $(ADA_INCLUDES) gnatname --GCC="$(CC) $(ALL_ADAFLAGS)"
$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gnatname 
-   $(GNATLINK) -v gnatname -o $@ --GCC=$(GCC_LINK) $(TOOLS_LIBS)
+   $(GNATLINK) -v gnatname -o $@ --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
 
 ../../gprmake$(exeext): 
$(GNATMAKE) -c $(ADA_INCLUDES) gprmake --GCC="$(CC) $(ALL_ADAFLAGS)"
$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gprmake
-   $(GNATLINK) -v gprmake -o $@ --GCC=$(GCC_LINK) $(TOOLS_LIBS)
+   $(GNATLINK) -v gprmake -o $@ --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
 
 ../../gnatprep$(exeext): 
$(GNATMAKE) -c $(ADA_INCLUDES) gnatprep --GCC="$(CC) $(ALL_ADAFLAGS)"
$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gnatprep 
-   $(GNATLINK) -v gnatprep -o $@ --GCC=$(GCC_LINK) $(TOOLS_LIBS)
+   $(GNATLINK) -v gnatprep -o $@ --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
 
 ../../gnatxref$(exeext): 
$(GNATMAKE) -c $(ADA_INCLUDES) gnatxref --GCC="$(CC) $(ALL_ADAFLAGS)"
$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gnatxref 
-   $(GNATLINK) -v gnatxref -o $@ --GCC=$(GCC_LINK) $(TOOLS_LIBS)
+   $(GNATLINK) -v gnatxref -o $@ --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
 
 ../../gnatfind$(exeext): 
$(GNATMAKE) -c $(ADA_INCLUDES) gnatfind --GCC="$(CC) $(ALL_ADAFLAGS)"
$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gnatfind 
-   $(GNATLINK) -v gnatfind -o $@ --GCC=$(GCC_LINK) $(TOOLS_LIBS)
+   $(GNATLINK) -v gnatfind -o $@ --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
 
 ../../gnatclean$(exeext): 
$(GNATMAKE) -c $(ADA_INCLUDES) gnatclean --GCC="$(CC) $(ALL_ADAFLAGS)"
$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gnatclean
-   $(GNATLINK) -v gnatclean -o $@ --GCC=$(GCC_LINK) $(TOOLS_LIBS)
+   $(GNATLINK) -v gnatclean -o $@ --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
 
 ../../gnatsym$(exeext): 
$(GNATMAKE) -c $(ADA_INCLUDES) gnatsym --GCC="$(CC) $(ALL_ADAFLAGS)"
$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gnatsym
-   $(GNATLINK) -v gnatsym 

Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Eric Botcazou wrote:
|>Attached is a patch to the 4.1 branch, I think it will apply to mainline
|>too. Branch built fine on powerpc-apple-darwin8.4.0 with c,ada enabled.
|
|
| That's not sufficient: the compiler bootstraps fine, but all the ACATS tests
| fail to link:
|
| collect2: ld returned 1 exit status
|
| So, on Darwin, unlike any other platforms, you need to explicitly pass either
| -static-libgcc or -shared-libgcc to link the EH machinery.  That seems weird.
|
| Geoff, any chance to bring Darwin back on par with the other platforms?
|

Since Geoff is worried about future binary compatibility apparently, it
would probably be easier to modify gnatlink.adb to emit -static-libgcc or
- -shared-libgcc depending on whether static or shared gnatlib is used.

Sorry, I know nothing about ada or I'd help.

Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQ9TvHLiDAg3OZTLPAQK3dgP/azit2VsBNmWlufxp4PZpbWtO28uZNO15
Zmp0Vh+/439x7dhx8sF3JpD4ryyKg40LiLHe2Qtdx4NyYYrD5rrjabJZ03TmVOV1
9p27Zo0ze/jcXuQvuvmu9Xcu3YDZ87AS1aPyuhIHRJIy/097yQN6yubd/t9WqZMN
AyCMVCKi6gY=
=Hkol
-END PGP SIGNATURE-

Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

[Peter O'Gorman]

Eric Botcazou wrote:

Since Geoff is worried about future binary compatibility apparently, it
would probably be easier to modify gnatlink.adb to emit -static-libgcc or
-shared-libgcc depending on whether static or shared gnatlib is used.



The problem is that passing -static-libgcc unconditionally can theoritically 
cause problems on Linux when C code using POSIX threads is linked.  So we 
would need to do that only on Darwin.




Then set a var in link.c for darwin and use that as the conditional?

#elif defined(__APPLE__)
const char *__gnat_run_path_option = "-Wl,-filelist";
const char *__gnat_object_file_option = "";
char __gnat_shared_libgnat_default = STATIC;
int __gnat_link_max = 262144;
unsigned char __gnat_objlist_file_supported = 1;
unsigned char __gnat_using_gnu_linker = 0;
const char *__gnat_object_library_extension = ".a";
unsigned char __gnat_darwin_idiocy = 1;
#else
...

You'd have to add the idiocy flag elsewhere too and default to 0.

Peter

Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

[Peter O'Gorman]

Arnaud Charlet wrote:

Then set a var in link.c for darwin and use that as the conditional?

#elif defined(__APPLE__)
const char *__gnat_run_path_option = "-Wl,-filelist";
const char *__gnat_object_file_option = "";
char __gnat_shared_libgnat_default = STATIC;
int __gnat_link_max = 262144;
unsigned char __gnat_objlist_file_supported = 1;
unsigned char __gnat_using_gnu_linker = 0;
const char *__gnat_object_library_extension = ".a";
unsigned char __gnat_darwin_idiocy = 1;
#else



Well, the name certainly cannot be called __gnat_darwin_idiocy.
Instead, these flags should be tailored by capability, not by platforms.

That would be e.g. "unsigned char __gnat_force_libgcc_option = 1;"


Aw! :)

Also, I missed a comma after -filelist.

Peter

Re: question about -print-search-dirs

[Peter O'Gorman]

On Sep 13, 2006, at 3:57 AM, Kate Minola wrote:


The reason I ask is that libtool (or more precisely the m4 macro
AC_LIBTOOL_SYS_DYNAMIC_LINKER in libtool.m4) uses
"gcc -print-search-dirs" to set  sys_lib_search_path_spec.  But
if gcc is in -m64 mode but -print-search-dirs is only listing -m32
libraries, then bad things happen later on.


Yes, -print-search-dirs is not appropriate for the multilib case,  
please bring this up (again) on the libtool or bug-libtool lists.


Peter

Re: automatic --disable-multilib

[Peter O'Gorman]

On Oct 9, 2006, at 2:24 PM, Geoffrey Keating wrote:


Jack Howarth <[EMAIL PROTECTED]> writes:


   Shouldn't configure in gcc be made to
automatically test if -m64 is working on
the build machine in question and automatically
invoke --disable-multilib if not? Currently
on Darwin for example we have to explicitly
invoke --disable-multilib when building on
G4's or non-EMT64 Macintel machines. It would
much better if configure would automatically
handle this.


I believe trying to disable the multilib is fundamentally the wrong
approach.  I have posted a patch which I believe is the correct
approach to the automake list, where it is awaiting review.


You might want to ping it, it's been awaiting review for a while.

Peter

Re: automatic --disable-multilib

[Peter O'Gorman]

On Oct 9, 2006, at 9:27 PM, Jack Howarth wrote:


Geoff,
Can you point me to the proposed patch in the gcc-patches
mailing list archives? I can't seem to find it.


http://lists.gnu.org/archive/html/automake-patches/2006-09/msg00027.html

It's automake -patches.

Peter

Re: Regenerating configure scripts

[Peter O'Gorman]

Michael Eager wrote:

> I've noticed a problem with the patch:
>   if test "${with_newlib+set}" = set; then
> AC_LIBTOOL_DLOPEN
>   fi
> 
> The test always succeeds.  When $with_newlib is "yes",
> ${with_newlib+set} is "set".
> 
> If I change this to the old style test
>   if test "x$with_newlib" = x; then
> AC_LIBTOOL_DLOPEN
>   fi
> then it works as expected.

In the message you gave a url to at the start of this thread I see:

if test "x${with_newlib}" != "xyes"; then
AC_LIBTOOL_DLOPEN
fi

Which would seem to be correct.

If you are unsure of what ${var+set} does, see
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_02

Peter
-- 
Peter O'Gorman
http://pogma.com

Re: [RFC, Patch, gfortran] make -static-libgfortran work on darwin.

[Peter O'Gorman]

Ralf Wildenhues wrote:

>>> Independently, does anybody know whether odcctools is dead (homepage
>>> seems to be down ATM)?

odcctools is currently seeking a maintainer.

Peter
-- 
Peter O'Gorman
http://pogma.com

Re: libstdc++, gdb and darwin

[Peter O'Gorman]

Jack Howarth wrote:
> Does anyone know why gdb appears to be unable to find the debug 
> information
> for libstdc++ in gcc 4.3 and gcc trunk on darwin9? This has been reported 
> before
> as...
> 
> https://trac.macports.org/ticket/16102
> 
> Under current gcc trunk, using Apple's current Xcode 3.1's gdb reports the
> errors of the form...
> 
> warning: Could not find object file
> "/sw/src/fink.build/gcc44-4.3.999-20080803/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/libstdc++.lax/libmath.a/signbit.o"
> - no debug information available for
> "../../../../gcc-4.4-20080803/libstdc++-v3/libmath/signbit.c".
> 
> when I try to run a binary linked to libstdc++ in gdb. My gcc build directory 
> doesn't
> have a libstdc++.lax directory left in it. Is this a flaw in the .la files 
> for gcc?
> Thanks in advance for any advice. I am trying to puzzle out if this is a gcc 
> bug or
> a gdb bug so that I can file a radar report against gdb if it is the later.
>  Jack
> 

The debug information is stored in the object files. Libtool uses a
convenience library, and, because darwin's linked does not have the
equivalent of --whole-archive --no-whole-archive to ensure that all
members of specific archives are loaded, it unpacks the archive and adds
all the objects. Having created the output, it then deletes these
objects, leaving the debugger with no object files.

This is "fixed" in recent GNU libtool by calling dsymutil on the newly
created shared library. I have not checked if gcc's version of libtool
has this change. I'll check when I have time and submit a patch if that
is not the case.

Peter
-- 
Peter O'Gorman
http://pogma.com

Update libtool? (was: Re: libstdc++, gdb and darwin)

[Peter O'Gorman]

Jack Howarth wrote:
> Peter,
> Thanks. If gcc's libtool is missing this dsymutil workaround, it would
> be nice if this could be fixed for both gcc trunk and 4.3.2.
> Jack

I went and looked for the patches that added dsymutil to libtool, looks
like I took the opportunity to rewrite all the darwin bits at the same
time, then had a couple of follow-up patches to fix bugs that I
introduced. It is not a small patch.

I wonder what the chances are of moving mainline gcc to a newer libtool
version? Introducing the darwin bits piecemeal would not be particularly
fun.

Peter
-- 
Peter O'Gorman
http://pogma.com

Re: Update libtool?

[Peter O'Gorman]

Jack Howarth wrote:
> Peter,
> You are going to fix this on gcc trunk in any case, right?

If there is a consensus that now is not the time to update libtool in
trunk, then I will have to :)

>  Jack
> 
> On Wed, Aug 06, 2008 at 11:17:03AM -0500, Peter O'Gorman wrote:
>> Jack Howarth wrote:
>>> Peter,
>>> Thanks. If gcc's libtool is missing this dsymutil workaround, it would
>>> be nice if this could be fixed for both gcc trunk and 4.3.2.
>>> Jack
>> I went and looked for the patches that added dsymutil to libtool, looks
>> like I took the opportunity to rewrite all the darwin bits at the same
>> time, then had a couple of follow-up patches to fix bugs that I
>> introduced. It is not a small patch.
>>
>> I wonder what the chances are of moving mainline gcc to a newer libtool
>> version? Introducing the darwin bits piecemeal would not be particularly
>> fun.
>>
>> Peter
>> -- 
>> Peter O'Gorman
>> http://pogma.com


-- 
Peter O'Gorman
http://pogma.com

Re: Update libtool?

[Peter O'Gorman]

Hi Ralf,

Ralf Wildenhues wrote:
> * Peter O'Gorman wrote on Wed, Aug 06, 2008 at 06:26:15PM CEST:
>> Jack Howarth wrote:
>>> On Wed, Aug 06, 2008 at 11:17:03AM -0500, Peter O'Gorman wrote:
>>>> I wonder what the chances are of moving mainline gcc to a newer libtool
>>>> version? Introducing the darwin bits piecemeal would not be particularly
>>>> fun.
>>> You are going to fix this on gcc trunk in any case, right?
>> If there is a consensus that now is not the time to update libtool in
>> trunk, then I will have to :)
> 
> First off, I am not in a position to decide anything here, so the
> following is just my two cents:
> 
> I would be a bit concerned to update libtool in branch-4_3.  Is this
> issue a regression?

I have no intention of asking that libtool be updated in the 4.3 branch.

I do not consider it a regression, it has always been broken on Mac OS X
when using dwarf2.

> I haven't tried GCC trunk with libtool 2.2.4 yet, but I guess that
> should be reasonably smooth.  (Of course I'd be willing to try.)

I am also willing to try.

> 
> AFAICS there are no GCC-specific changes in these files:
> libtool.m4 ltmain.sh lt~obsolete.m4 ltoptions.m4 ltsugar.m4 ltversion.m4
> (there has been a patch to libtool.m4 but it was subsequently backed out
> again.)

Good to know. Thanks.

Peter
-- 
Peter O'Gorman
http://pogma.com

Re: Update libtool?

[Peter O'Gorman]

Paolo Bonzini wrote:
> 
>> That said, updating in trunk is a different matter.  There, the question
>> IMHO is mostly which libtool version to update to.  The git version may
>> still have a regression or two, but 2.2.4 doesn't have the -fPIC on
>> HP/IA patch from Steve (which would be trivial to backport of course).
>> Alternatively GCC can wait for 2.2.6 (hopefully in the "couple of weeks
>> at most" time frame).
> 
> Updating to 2.2.6 would be okay for me.

Thanks. I'll test quickly with current libtool git now, and will test
more thoroughly and submit a patch when libtool-2.2.6 is released.

Peter
-- 
Peter O'Gorman
http://pogma.com

Re: Update libtool?

[Peter O'Gorman]

Ralf Wildenhues wrote:
> * Peter O'Gorman wrote on Thu, Aug 07, 2008 at 07:01:48PM CEST:
>> Paolo Bonzini wrote:
>>>> That said, updating in trunk is a different matter.  There, the question
>>>> IMHO is mostly which libtool version to update to.  The git version may
>>>> still have a regression or two, but 2.2.4 doesn't have the -fPIC on
>>>> HP/IA patch from Steve (which would be trivial to backport of course).
>>>> Alternatively GCC can wait for 2.2.6 (hopefully in the "couple of weeks
>>>> at most" time frame).
>>> Updating to 2.2.6 would be okay for me.
>> Thanks. I'll test quickly with current libtool git now, and will test
>> more thoroughly and submit a patch when libtool-2.2.6 is released.
> 
> FWIW, a quick test with current git Libtool shows no problems on
> GNU/Linux.

Yes, I tried it also -
http://pogma.com/misc/gcc-libtool-git20080810.patch (Slight change to
ltgcc.m4, otherwise git libtool + generated files).

I plan on testing more widely next weekend and proposing a patch the
following week, regardless of whether libtool-2.2.6 is released. (Unless
Ralph would prefer to do it?)

I'll try lighting a fire under Gary too :-)

Peter
-- 
Peter O'Gorman
http://pogma.com

Re: [PATCH] Update libtool to latest git tip

[Peter O'Gorman]

Hi Paolo,

On Thu, Aug 21, 2008 at 04:29:26PM +0200, Paolo Bonzini wrote:
> Peter O'Gorman wrote:
>> On Mon, Aug 11, 2008 at 03:02:05PM -0500, Peter O'Gorman wrote:
>>> Yes, I tried it also -
>>> http://pogma.com/misc/gcc-libtool-git20080810.patch (Slight change to
>>> ltgcc.m4, otherwise git libtool + generated files).
>>>
>>> I plan on testing more widely next weekend and proposing a patch the
>>> following week, regardless of whether libtool-2.2.6 is released. (Unless
>>> Ralph would prefer to do it?)
>>>
>>
>> Hi,
>> Does not look much like there will be a libtool 2.2.6 release this month.
>
> Why?  Regressions, or just no time?

Well, libtool-2.2.6 is finally released (twice even).

>
> Actual approval depends on your answer to this question, but the patch is 
> technically okay.  Can you commit it to the src repository too? There is 
> some regeneration to do there too.

I know that GCC is now in stage 3, and that we missed the end of stage 1
by a week, but I would still like to update gcc's libtool to 2.2.6.

Peter
-- 
Peter O'Gorman
[EMAIL PROTECTED]

Re: [PATCH] Update libtool to latest git tip

[Peter O'Gorman]

On Mon, Sep 08, 2008 at 08:29:37PM +0200, Paolo Bonzini wrote:
> 
> > Well, libtool-2.2.6 is finally released (twice even).
> > 
> >> Actual approval depends on your answer to this question, but the patch is 
> >> technically okay.  Can you commit it to the src repository too? There is 
> >> some regeneration to do there too.
> > 
> > I know that GCC is now in stage 3, and that we missed the end of stage 1
> > by a week, but I would still like to update gcc's libtool to 2.2.6.
> 
> It fixed a Darwin bug, right?
> 

Yes, though I do not know if Jack actually filed a PR for it, it was
about debugging libstdc++ on darwin.

Lots of other fixes in libtool-2.2.6 too, of course.

Peter
-- 
Peter O'Gorman
[EMAIL PROTECTED]

Re: Apple, iPhone, and GPLv3 troubles

[Peter O'Gorman]

Yuhong Bao wrote:
> and Apple uses GCC (which is now under GPLv3) and Mac OS X on it.
> Unfortunately, the iPhone is incompatible with GPLv3, if you want more see
> the link I mentioned.

Apple does not use a GPLv3 version of GCC. All GPL sources used in the
iPhone, are, as far as I know, available at
http://www.opensource.apple.com/darwinsource/iPhone2.1/ (perhaps also
other locations at http://www.opensource.apple.com/darwinsource).

If there are sources that you feel are missing, filing a bug at
http://bugreporter.apple.com is probably your best bet.

And, yes, I feel bad for replying to the list on this when it has
already been stated that it is off-topic.

Peter
--
Peter O'Gorman
http://pogma.com

Re: libjava regressions in r140713

[Peter O'Gorman]

Andreas Tobler wrote:
> Jack Howarth wrote:
>>On i686-apple-darwin9, I am seeing massive regressions in the libjava
>> testsuite in revision 140713 compared to my previous test on 20080925.
>> Since the libtool updates went in (which would see the likely culprit),
>> we went from zero to 835 unexpected failures.
>>
>> http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg02174.html
>> http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg02291.html
> 
> I'll send a patch later today.

Thanks Andreas, libtool prints this warning for:
*-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2* | *-*-darwin* | *-cegcc*

So, the libjava testsuite's libjava.exp should probably avoid adding
-no-install for a similar set of targets.

Peter
-- 
Peter O'Gorman
http://pogma.com