ftp/wget using make instead of gmake?

ShelLuser

ShelLuser

Hi gang,

I've been using FreeBSD 9.1-RELEASE for some time now and recently tried to upgrade ftp/wget which unfortunately resulted in an error:

Code: 
config.status: creating po/POTFILES
config.status: creating po/Makefile
===>  Building for wget-1.14_2
/usr/bin/make  all-recursive
*** [do-build] Error code 1

Stop in /usr/ports/ftp/wget.
*** [build] Error code 1

Stop in /usr/ports/ftp/wget.
I somewhat let this slip for a while because wget currently works and I simply had no time to look into it.

Try to picture my surprise: today I had to provision a backup server, needless to say this is also FreeBSD 9.1-RELEASE, and I just finished with the ports. This is what happens when I install ftp/wget:

Code: 
config.status: creating po/POTFILES
config.status: creating po/Makefile
===>  Building for wget-1.14_2
gmake  all-recursive
gmake[1]: Entering directory `/usr/ports/ftp/wget/work/wget-1.14'
Making all in lib
gmake[2]: Entering directory `/usr/ports/ftp/wget/work/wget-1.14/lib'
rm -f alloca.h-t alloca.h && \
And it cleanly compiles and installs. Needless to say, but this triggered my curiosity.

I'm pretty sure it has to be the environment. On both servers the ports collection is the same, when looking at ftp/wget and devel/gmake I'm positive that both servers use exactly the same ports collection.

But I can't get my fingers behind it. The dependencies are met, on both servers the common tools such as gmake and automake are installed. Also the direct dependency of devel/gettext is met.

The only thing which could be of influence is make.conf but even that is completely equal on both servers:

Code: 
# added by use.perl 2013-04-18 13:38:56
PERL_VERSION=5.14.2
# Pre-define Apache's suexec root directory
#SUEXEC_DOCROOT=/home
I commented SUEXEC_DOCROOT out for the moment, just to be sure.

Just to rule out any weird oddities with the PATH or something I logged onto the console as root (I haven't made any changes to that account, apart from the password) but even that doesn't resolve the error.

When looking at the Makefile I can see that gmake is being used since USE_GMAKE is specifically set to "YES". And gmake is present in the current search path:

Code: 
root@smtp2:/usr/ports/ftp/wget # which gmake
/usr/local/bin/gmake
Can any of you guys come up with a suggestion as to what could be wrong here?
 
Some changes were committed in r314556.

Please, read /usr/ports/UPDATING:
Code: 
20130316:
  AFFECTS: users of converters/libiconv and devel/gettext
  AUTHOR: [email]bapt@FreeBSD.org[/email]

  libiconv now handles the lib/charset.alias file instead of devel/gettext.
  If you are using pkgng 'and' upgrading from source with portupgrade or
  portmaster, first delete gettext, upgrade libiconv, then reinstall gettext.

  This will break sudo, so you *must* do this in a root shell (sudo -i)
  if you use sudo.

  # pkg delete -f devel/gettext
  # portmaster converters/libiconv devel/gettext
    or
  # pkg delete -f devel/gettext
  # portupgrade converters/libiconv devel/gettext
 
Thanks for the tip, but unfortunately I had followed up on this. Just to rule everything out I just re-installed both converters/libiconv and devel/gettext in that same order but no go.

In the mean time I noticed the exact same problem occurring with devel/glib20 so I'm now looking for similarities between these two.

I'm fully convinced this is because I somehow managed to create an inconsistency in my environment, and right now I think it's related to my continued usage of portmanager while it had already been deemed unsafe (or unusable).

Even so, it's still a little bit puzzling for me. I discovered that even though the build will always fail (when using # make build) doing this manually in the source tree actually works. And it doesn't matter if I'm executing make or gmake.

That leads me to believe the problem can be traced back to something specific for the FreeBSD Ports collection.
 
cpu82 said:
Some changes was committed in r314556.

Please, read /usr/ports/UPDATING:
Code: 
20130316:
  AFFECTS: users of converters/libiconv and devel/gettext
  AUTHOR: [email]bapt@FreeBSD.org[/email]

  libiconv now handles the lib/charset.alias file instead of devel/gettext.
  [color="Red"]If you are using pkgng 'and' upgrading from source with portupgrade or
  portmaster[/color], first delete gettext, upgrade libiconv, then reinstall gettext.

  This will break sudo, so you *must* do this in a root shell (sudo -i)
  if you use sudo.

  # pkg delete -f devel/gettext
  # portmaster converters/libiconv devel/gettext
    or
  # pkg delete -f devel/gettext
  # portupgrade converters/libiconv devel/gettext
Click to expand...

Those only apply if you are using pkgng.
 
Check your shell configuration file, I suspect that you have a typo, or something similar, like an erroneous path.
 
First; apologies because I just noticed that I somewhat copied a previous thread even though I blamed portmaster in there. Not my intention to start cross posting or whatever.

In the mean time I started checking the behaviour on both servers and so far I discovered two things which puzzle me. On my new FreeBSD server (FreeBSD 9.1-RELEASE-P3) I noticed that the Ports collection included a file which isn't present on my current one, namely /usr/ports/Mk/bsd.ncurses.mk. Most likely totally irrelevant, but it surprised me.

Second; I managed to re-produce the error. The very moment I go into the source directory (/usr/ports/ftp/wget/work/wget-1.14) and issue # make --all-recursive I get the same error message.

It has to be the environment, but so far I can't figure it out. Even tried to logon to the main console as root to rule out anything with regards to environment variables but so far no luck.

I also generated a list of all Ports on which both ftp/wget and devel/glib20 rely and used portmaster to recompile those and their own dependencies (using the -t option), but no go.

Very, very weird.
 
Yes, I'm using portsnap. However, I don't really concern myself yet with making sure that the ports tree is the same across all my servers. I have svn installed and I'm familiar with some of the basic functionality.

However, I think that I can fully rule out any problem with the ports tree itself because both ftp/wget as well as the Mk directories are completely identical (save 1 file).

It gets better; if I look at the configure.log file then the only differences are basically the hostname and some of the temporary filenames. The rest is completely identical.

One advantage is that I'm learning a lot about the port system right now, I only wish this particular behaviour would make more sense to me.
 
Going back to the original post, the real error is not shown. It happened somewhere above that. script(1) can be used to capture that output. On a real console, use the Scroll Lock and cursor keys to scroll backwards.

On make(1) versus gmake(1): that's fine. The ports Makefiles are written for BSD make(1). Some ports need gmake(1) for their own builds. When configured for that, they'll use the right one.
 
wblock@ said:
Going back to the original post, the real error is not shown. It happened somewhere above that.
Click to expand...
The error is in the first code block. Above this part it simply runs the configure script which doesn't generate any errors. I even compared the configure.log file from both servers with minimal results.

But as soon as it starts building wget I get the error above.

Edit: Ok, I was logged in as root so I ran # make build >& build_wget.log and I've put that logfile fully online right here using my synth blog.

You can see for yourself (if you're willing to) that there are no errors being mentioned.
 
Right, learned something new. I wasn't familiar with the script command yet, looks quite useful indeed. I ran # script /root/temp/script_wget.log make build and put that file online as well.
 
All right, that helps. I see what you are saying. On my 9.1-STABLE system, I see this:
Code: 
===>  Building for wget-1.14_2
[B]gmake[/B]  all-recursive
gmake[1]: Entering directory `/usr/ports/ftp/wget/work/wget-1.14'

And of course it builds without problem. Since yours says /usr/bin/make there, I'd guess something is messing with variables. If it's not in make.conf, maybe somewhere in /usr/ports/Mk?

Although that problem needs to be fixed, fetch(1) is a native utility that may do enough to make ftp/wget unnecessary.
 
wblock@ said:
And of course it builds without problem. Since yours says /usr/bin/make there, I'd guess something is messing with variables. If it's not in make.conf, maybe somewhere in /usr/ports/Mk?
Click to expand...
Right, it took me way too long (this actually made me lose some sleep) but I've also learned quite a bit with regards to the Ports here. To be honest; I've become quite impressed with the sheer flexibility of it all.

And I solved my problem.

After going over my entire Port collection and checking (and re-installing) several "logical" targets I ended up concluding that it could absolutely be nothing else than my own environment.

Because I don't use stuff like sudo on my FreeBSD servers I started going through all the profile and rc files in /root. And what do you know, I discovered this in /root/.cshrc:

Code: 
## Set port environment

setenv PORTSDIR        /usr/ports
setenv DIALOG4PORTS    `which dialog4ports`
setenv MAKE            `which make`
I have no idea where this came from, but it's probably my own "brilliant" doing. I'm also having a hard time understanding where I got this stupid idea from in the first place.

Anyway, removing these three environment variables solved all my problems. ftp/wget cleanly compiles, misc/mc no longer stalls during building and devel/glib20 also cleanly upgraded.

Of course now I feel pretty stupid, but oh well...

Thanks for all the help you guys, that's really appreciated!
 
You must log in or register to reply here.
Back
Top