Hi David, others,
* David Edelsohn wrote on Thu, Apr 14, 2005 at 02:20:13AM CEST:
> Peter> Look for $with_gnu_ld in ltmain.m4sh.
>
> Okay, sorry that I missed that. I can move my change to that
> block, but the GNU ld linker script syntax is just different enough that I
> cannot reuse the
> Peter O'Gorman writes:
Peter> Look for $with_gnu_ld in ltmain.m4sh.
Okay, sorry that I missed that. I can move my change to that
block, but the GNU ld linker script syntax is just different enough that I
cannot reuse the file. GNU ld wants a file containing
INPUT (
"filename1"
"
David Edelsohn wrote:
Peter O'Gorman writes:
The patch is relative to libtool HEAD. Can you point me to the
location of the existing linker script support?
Sorry, can't pay close attention with a three year old sitting on lap
shouting :)
Peter> can't you just do this?
Peter> output=$file
> Peter O'Gorman writes:
Peter> This looks like a good idea, but could you please supply a patch against
Peter> libtool HEAD where there is already a section to use a linker script if
Peter> usign gnu ld.
The patch is relative to libtool HEAD. Can you point me to the
location of the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Edelsohn wrote:
| If a link command is longer than $max_cmd_len, libtool currently
| breaks up the link command into shorter subcommands by creating
| intermediate reloadable object files. Because of assumptions by libtool,
| this does not
If a link command is longer than $max_cmd_len, libtool currently
breaks up the link command into shorter subcommands by creating
intermediate reloadable object files. Because of assumptions by libtool,
this does not work on all targets. Additionally, some targets have the
ability to speci
Ralf Wildenhues wrote:
* Peter O'Gorman wrote on Mon, Apr 11, 2005 at 03:50:03PM CEST:
Ralf Wildenhues wrote:
| - *) deplibs="$deplibs $path" ;;
| + *) deplibs="$path $deplibs" ;;
This is different to the patch for Zachary's bug which was:
- - *) deplibs="$deplibs $d
