Re: binutils powerpc problems (fwd)

Re: binutils powerpc problems (fwd)

[joel]

Bummer... upgrading did not solve this one for Ralf.  :(

Here is what he sent me.

--joel


---------- Forwarded message ----------
Date: Sat, 03 Apr 1999 05:40:41 +0200
From: Ralf Corsepius <corsepiu@faw.uni-ulm.de>
To: joel@oarcorp.com
Subject: Re: binutils powerpc problems

joel@oarcorp.com wrote:

> I know Ralf ran into this.  Just in case someone else did, here is the
> response.   Let me know if this fixes it for you.

No, it doesn't.

The situation is the same with binutils-2.9.1.0.22b, binutils-2.9.1.0.23
and gas-990324

But now I think I've found the problem:

/usr/bin/install -c -m 0644
../../../../../../../../rtems-rc-19990401-0/c/src/lib/libbsp/powerpc/dmv177/wrapup/../bsp_specs
/lfs/poseidon/users/rtems/src/multi/build/./eth_comm/lib/bsp_specs

==>The wrong bsp_specs file gets installed to the build-tree.

This happens during processing the preinstall rule in c/Makefile.

This is an excerpt of: c/make_src_makefiles

> [..]
> ./src/lib/libbsp/shmdr/Makefile
> ./src/lib/libbsp/powerpc/dmv177/wrapup/Makefile
> ./src/lib/libbsp/powerpc/eth_comm/wrapup/Makefile
> ./src/lib/libbsp/powerpc/helas403/wrapup/Makefile
> ./src/lib/libbsp/powerpc/papyrus/wrapup/Makefile
> ./src/lib/libbsp/powerpc/ppcn_60x/wrapup/Makefile
> ./src/lib/libbsp/powerpc/psim/wrapup/Makefile
> ./src/lib/libbsp/powerpc/score603e/wrapup/Makefile
> ./src/lib/libc/Makefile
> [..]
>
Each of these lines is read in and the Makefile contained in this line is
called with RTEMS_BSP=${RTEMS_BSP} passed through the environment.

Each of the wrapup/Makefile's contains a rule of this kind:

> $(PROJECT_ROOT)/${RTEMS_BSP}/bsp_specs: ../bsp_specs
>     $(INSTALL_DATA) $< $@
>
> preinstall: $(PROJECT_ROOT)/${RTEMS_BSP}/bsp_specs
>

With "make RTEMS_BSP=eth_comm" invoked in src/lib/libbsp/powerpc/dmv177,
the dmv177 bsp_specs gets installed for eth_comm and no other bsp_specs
will get installed afterwards.

<rant> That preinstall crap interfers with one of my "towards automake"
patches again </rant>

------
This would also explain why I am not able to build most of the m68k BSPs
(Not yet cross-checked)

------
Now I don't understand why you don't seem to be effected by this problem.
AFAIS, it must be present for all cpus with more than one BSP !

I assume the cause for you not getting this problem is the order of inodes
on our disks, because c/Makefile.in applies "find", which by lucky chance
installs a bsp_specs to the build-tree which presumably is compatible to
all powerpc BSPs in your case and only to some BSPs in my case.

------
I don't have a work-around or fix for this problem yet (It's 5:30am and I
urgently need to get some sleep), but this bug is severe enough to be fixed
pretty soon, if not to release a new snapshot.

I can imagine half a dozen of find/sed/grep/make trickery to work around
this problem in c/Makefile.in, so I can probably come up with a work-around
tomorrow, however I didn't find anything convincing yet.

Ralf

--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung (FAW)
Helmholtzstr. 16, 89081 Ulm, Germany     Tel: +49/731/501-8690
mailto:corsepiu@faw.uni-ulm.de           FAX: +49/731/501-999
http://www.faw.uni-ulm.de

Re: binutils powerpc problems (fwd)

[H.J. Lu]

> 
> 
> 
> Bummer... upgrading did not solve this one for Ralf.  :(
> 
> Here is what he sent me.
> 
> --joel
> 
> 
> ---------- Forwarded message ----------
> Date: Sat, 03 Apr 1999 05:40:41 +0200
> From: Ralf Corsepius <corsepiu@faw.uni-ulm.de>
> To: joel@oarcorp.com
> Subject: Re: binutils powerpc problems
> 
> joel@oarcorp.com wrote:
> 
> > I know Ralf ran into this.  Just in case someone else did, here is the
> > response.   Let me know if this fixes it for you.
> 
> No, it doesn't.
> 
> The situation is the same with binutils-2.9.1.0.22b, binutils-2.9.1.0.23
> and gas-990324
> 
> But now I think I've found the problem:
> 
> /usr/bin/install -c -m 0644
> ../../../../../../../../rtems-rc-19990401-0/c/src/lib/libbsp/powerpc/dmv177/wrapup/../bsp_specs
> /lfs/poseidon/users/rtems/src/multi/build/./eth_comm/lib/bsp_specs
> 
> ==>The wrong bsp_specs file gets installed to the build-tree.
> 
> This happens during processing the preinstall rule in c/Makefile.
> 
> This is an excerpt of: c/make_src_makefiles
> 
> > [..]
> > ./src/lib/libbsp/shmdr/Makefile
> > ./src/lib/libbsp/powerpc/dmv177/wrapup/Makefile
> > ./src/lib/libbsp/powerpc/eth_comm/wrapup/Makefile
> > ./src/lib/libbsp/powerpc/helas403/wrapup/Makefile
> > ./src/lib/libbsp/powerpc/papyrus/wrapup/Makefile
> > ./src/lib/libbsp/powerpc/ppcn_60x/wrapup/Makefile
> > ./src/lib/libbsp/powerpc/psim/wrapup/Makefile
> > ./src/lib/libbsp/powerpc/score603e/wrapup/Makefile
> > ./src/lib/libc/Makefile
> > [..]
> >
> Each of these lines is read in and the Makefile contained in this line is
> called with RTEMS_BSP=${RTEMS_BSP} passed through the environment.
> 
> Each of the wrapup/Makefile's contains a rule of this kind:
> 
> > $(PROJECT_ROOT)/${RTEMS_BSP}/bsp_specs: ../bsp_specs
> >     $(INSTALL_DATA) $< $@
> >
> > preinstall: $(PROJECT_ROOT)/${RTEMS_BSP}/bsp_specs
> >
> 
> With "make RTEMS_BSP=eth_comm" invoked in src/lib/libbsp/powerpc/dmv177,
> the dmv177 bsp_specs gets installed for eth_comm and no other bsp_specs
> will get installed afterwards.
> 
> <rant> That preinstall crap interfers with one of my "towards automake"
> patches again </rant>
> 
> ------
> This would also explain why I am not able to build most of the m68k BSPs
> (Not yet cross-checked)
> 
> ------
> Now I don't understand why you don't seem to be effected by this problem.
> AFAIS, it must be present for all cpus with more than one BSP !
> 
> I assume the cause for you not getting this problem is the order of inodes
> on our disks, because c/Makefile.in applies "find", which by lucky chance
> installs a bsp_specs to the build-tree which presumably is compatible to
> all powerpc BSPs in your case and only to some BSPs in my case.
> 
> ------
> I don't have a work-around or fix for this problem yet (It's 5:30am and I
> urgently need to get some sleep), but this bug is severe enough to be fixed
> pretty soon, if not to release a new snapshot.
> 
> I can imagine half a dozen of find/sed/grep/make trickery to work around
> this problem in c/Makefile.in, so I can probably come up with a work-around
> tomorrow, however I didn't find anything convincing yet.
> 
> Ralf
> 
> 

I added

	--multilib-dir PATH         Specify a target directory

to ld to solve the similar problem of one of my clients. They have
more one one BSP for one CPU. If you use binutils 2.9.1.0.2x, it
is in there. Here is the whole ChangeLog:

Wed Sep 16 07:32:44 1998  H.J. Lu  (hjl@gnu.org)

        * ld.h (args_type): Add one field, multilib_dir.

        * ldfile.c (ldfile_add_library_path): Add one argument, append.
        * ldfile.h (ldfile_add_library_path): Likewise.

        * ldgram.y: Calling ldfile_add_library_path with one more
        argument, true.
        * ldmain.c: Likewise.
        * lexsup.c: Likewise.

        * ldmain.c (check_for_scripts_dir): Add one argument, append.
        (main): Initialize command_line.multilib_dir to NULL.
        (set_scripts_dir): If command_line.multilib_dir is not NULL,
        prepend it to search path.

        * lexsup.c (OPTION_MULTILIB_DIR): New.
        (parse_args): Handle OPTION_MULTILIB_DIR.

        * emultempl/elf32.em (gld${EMULATION_NAME}_get_script): If
        command_line.multilib_dir != NULL, get linker scripts from
        files.

It may be useful to solve your problem.


-- 
H.J. Lu (hjl@gnu.org)