[bug #23262] sudo -E gmake install tries to run plmerge for aggregate project on FreeBSD

[Quentin Mathé]

URL:
  <http://savannah.gnu.org/bugs/?23262>

                 Summary: sudo -E gmake install tries to run plmerge for
aggregate project on FreeBSD
                 Project: GNUstep
            Submitted by: qmathe
            Submitted on: jeudi 15.05.2008 à 22:16
                Category: Makefiles
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

FreeBSD 7
GCC 4.2.1
make, base, gui and back from trunk r26455

When I try to install applications whose projects consist of several plugins
that get packaged in the app bundle, I get the following error:
/libexec/ld-elf.so.1: Shared object "libgnustep-base.so.1.15" not found,
required by plmerge

To install the app I type: sudo -E gmake install
In the GNUmakefile, each plugin is declared as a subproject with SUBPROJECTS
var and the application project includes both aggregate.make and
application.make. See below for links to such projects.

It seems to me that plmerge shouldn't be run at this time since sudo discards
linker related environment variables on somes OS (from sudo man page). In this
precise case, the -E flag probably preserve other environment variables but
not LD_LIBRARY_PATH for example.

For this project
<http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Services/Private/MenuServer/>,
the following line fails by trying to run plmerge:
sudo -E gmake messages=yes install
when the following line succeeds (plmerge isn't run):
sudo -E gmake install messages=yes 

Here are the other projects that fail to install in all cases unlike the
previous one:
<http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Services/User/LookAndBehavior/>
<http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Services/User/Hardware/>

iirc, I have experimented similar issues with plmerge in the past on Linux
but they have been fixed in the meantime. However time to time, for complex
aggregate projects I have to play a bit with the order in which gnustep-make
makefiles are included to avoid similar plmerge problems. I don't have a
proper example right now though, I just add this extra comment because I think
the underlying problem with plmerge may not be specific to FreeBSD.

Thanks,
Quentin.






    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?23262>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.gnu.org/