bugGNUstep - Bugs: bug #23262, sudo -E gmake install tries to run...

Group
 
 

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

Submitter:  Quentin Mathé <qmathe>
Submitted:  Thu 15 May 2008 10:16:53 PM UTC
   
 
Category:  Makefiles Severity:  3 - Normal
Item Group:  Bug Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Sun 25 May 2008 09:28:20 AM UTC, comment #5: 

Everything builds and installs perfectly fine on FreeBSD now. That's really great to have these issues fixed. Thanks a lot, Nicola.

I just have a last question about the right inclusion of aggregate.make when combined when another makefile. Should aggregate.make be included before or after framework.make (or application.make)? For example, with the following GNUmakefile: <http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Frameworks/EtoileFoundation/GNUmakefile?rev=3098&view=auto>, the compilation may fail if I change the order (probably also related to subtle interactions with the position of etoile.make include).

Quentin Mathé <qmathe>
Group Member
Sat 24 May 2008 02:49:31 PM UTC, comment #4: 

Quentin ... thanks for your log files - they were very helpful

With a bit of crafting I managed to recreate spurious rebuilds
very similar to the ones you were having, and fixed them :-)

I commited to trunk my fixes

Let me know if it works any better

Thanks

Nicola Pero <nico>
Group Member
Thu 22 May 2008 08:28:20 PM UTC, comment #3: 


> Do you have a reproducible test case ?


I can reproduce the problem with one framework and three applications (aggregate project with plugins) from the Etoile tree on FreeBSD. I don't know if I can reproduce the issue on Linux though. Some subtle interaction with sudo may be involved because sudo version on FreeBSD 7 comes with the flag -E. My Ubuntu install comes with an older version where this flag isn't needed to preserve the environment. However the latest Ubuntu release (Hardy Heron) comes with an updated sudo versions that needs the -E flag. There is a mail from Rubens_Septimus on gnustep-discuss<http://lists.gnu.org/archive/html/discuss-gnustep/2008-05/msg00090.html> where he detailed the same sort of error on that latest Ubuntu release. Not sure it's the same though (could be caused by root owned files) but I thought it was worth to mention.

Thanks for the explanation about make vs make && make install, I wasn't aware of that and I would suggest to add a note in gnustep-make documentation. Usually I always type 'make && sudo make install' since typing only 'sudo make install' create root owned files in my working copy and force me to later type 'sudo make' for a simple compilation.

As you suggested in your first post, I ran gmake distclean in  the projects I have trouble with (without warnings about files owned by root). Then I rebuilt each project like that :
gmake
sudo -E gmake install

By doing that, I got the same issues I reported.

So I put in attachment the logs for gmake and gmake install for a framework and an application where sudo -E gmake install still fail:
- http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Frameworks/IconKit
- http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Services/Private/MenuServer/

Before running these commands, I built the whole Etoile tree by typing :
- gmake in http://svn.gna.org/viewcvs/etoile/trunk/Etoile/ for satisfying the dependencies of the two projects (the dependencies are exported in an Etoile/Build directory created by etoile.make which is included by the main GNUmakefile of each project in the source tree)
You can find etoile.make here: http://svn.gna.org/viewcvs/etoile/trunk/Etoile/etoile.make

then I cleaned the projects for which I was going to collect the logs:
- gmake distclean in IconKit and MenuServer directory
My revision of Etoile tree is 3107, no changes have been done since then to either IconKit, MenuServer or etoile.make.

What you describe in your last post reminds me that I have observed such spurious rebuilds of some frameworks when typing: sudo make install. However I don't have the issue presently on FreeBSD unlike on my Ubuntu install. In the past, I have also observed that these issues (spurious rebuild, plmerge not found) were also varying with the level in the source tree where you run make. For example, running 'make' in etoile/Etoile/Frameworks would succeed when it would fail if you run in the parent directory etoile/Etoile/. I haven't tested for a while whether that still holds. It's quite possible this problem has been solved by past year gnustep-make releases.

>> 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
>
>
 as far as I know the two commands are completely identical.
>
> Did you try them in sequence ? Then maybe the first one


> failed because it detected that a rebuilt was needed, 


> did the rebuilt and failed trying to run plmerge 

> (which is the last command), but managed to rebuild enough 

> that the second one thought things were built and it didn't 

> need to build again, so it didn't fail.


Yes, I tried them in sequence. After trying to run them in a random manner, I think your explanation is correct.

Thanks Nicola for your very detailed replies. Let me know if you need any extra informations.


(file #15703, file #15704, file #15705, file #15706)

Quentin Mathé <qmathe>
Group Member
Sun 18 May 2008 08:45:45 PM UTC, comment #2: 

Actually, there might be a problem here - not as described,
but I can now see a case where you could have spurious rebuilds
of applications in the Etoile tree.

I had a quick look since it was reported by someone else as well,
and I can't reproduce it.

But while looking for spurious rebuilds I found a very
interesting problem with the current code for framework headers -
which could cause spurious rebuilds of frameworks. (see bug
#23286).

Now if you're building a big source tree with frameworks, if you
happen to trigger the bug for some of them you may get into a
situation where the framework is rebuilt every time you type
'make'.  If now you have an application in the source tree that
is using the framework, the application might also get rebuilt
every time you type 'make'.  Well, depending on which headers
it is including, it might be rebuilt all the times, or exactly
half of the times (every other time).

That spurious rebuild of the application would trigger the
behaviour you're seeing, and trigger it randomly in a way
that is difficult to reproduce.

I'll get bug #23286 fixed; in the meanwhile if you find it
prevents you from developing, as a quick fix you can put
plmerge in your root PATH (either by changing root's PATH,
or by putting plmerge in /usr/bin).

Actually, I wonder if the problem you're having is not something
else entirely.

Can I recommend when you have a building problem you just
report as much detailed information as you can ?  Ie, which
source tree, and exactly what the output of 'make messages=yes',
'make install messages=yes' etc is.  There are so many
different problems you may be having.

Thanks

Nicola Pero <nico>
Group Member
Sun 18 May 2008 11:06:51 AM UTC, comment #1: 

Do you have a reproducible test case ?

Else it's very difficult to say. :-(

My guess is that the problem you are having is due to the
fact that your 'sudo -E make install' is actually building
some software as root; not just installing it.

That's almost certainly due to the fact that you didn't do
a 'make' first - maybe you forgot in that specific case.

The correct procedure is:

  • type 'make' to compile.  This will run plmerge as your local

user, which should work.

  • type 'sudo -E make install' to install.  This will not plmerge because everything is already built.  It will only install things as root.  If you invoke this (by mistake) when things are not already built, it will try building them (it can't install without building) - running plmerge as root, which seems to fail in your setup. [a few years ago I tried convincing people to

change 'make install' so that it wouldn't automatically build,
which I think it's confusing, but was voted down big time because
the standard Unix way of doing things is that 'make install' both
builds (if needed) and installs, so we're stuck with that and
you need to be aware of it]

I suspect that that is the case, also because you report that

> 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


as far as I know the two commands are completely identical.

Did you try them in sequence ?  Then maybe the first one
failed because it detected that a rebuilt was needed,
did the rebuilt and failed trying to run plmerge
(which is the last command), but managed to rebuild enough
that the second one thought things were built and it didn't
need to build again, so it didn't fail.

Anyway, if you have the problem again, you should:

  • type 'make distclean'.  If you have local files owned by root,

it would suggest that the 'sudo -E make install' was building,
not just installing, which is either due to yourself having
forgotten to do a plain 'make' first, or due to sloppy custom
code in your makefiles (which maybe you don't care about though)

  • type 'make messages=yes'


  • type 'sudo -E make install messages=yes'.  This should never fail.  If it fails, it could be a real problem; please send me

the detailed logs.

Thanks

Nicola Pero <nico>
Group Member
Thu 15 May 2008 10:16:53 PM UTC, original submission:  

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.


Quentin Mathé <qmathe>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nico (Posted a comment)
  • -email is unavailable- added by qmathe (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-05-24 nico Open/ClosedOpen Closed
    2008-05-22 qmathe Attached File- Added gmake-iconkit.log, #15703
        Attached File- Added gmake-install-menuserver.log, #15704
        Attached File- Added gmake-install-iconkit.log, #15705
        Attached File- Added gmake-menuserver.log, #15706

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code