Closed Bug 1713741 Opened 3 years ago Closed 3 years ago

error compiling source v2.53.8.b1 / FreeBSD 13

Categories

(SeaMonkey :: General, defect)

SeaMonkey 2.53 Branch
x86_64
FreeBSD
defect

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: tonne01, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.7.1

Steps to reproduce:

Run the build process, and that entered the file "client.mk" which failed.

Actual results:

"client.mk" includes "$(OBJDIR)/.mozconfig-client-mk", which is not available:

client.mk:40: /.mozconfig-client-mk: No such file or directory
gmake[2]: *** No rule to make target '/.mozconfig-client-mk'. Stop.

I have no clue which step should create the missing file - anything before worked just fine. There's no problem on version 2.53.7.1, so something must differ related to this step. (Sidenote: If the build process wouldn't make use of the deprecated Python version 2.7 SeaMonkey could get back into FreeBSDs ports tree…)

The change came in with Bug 1416052 part 6.

Are you using mach build or mach configure.

Getting rid of python 2 is a goal. Unfortunately need to go thru all the build bugs. Not one of the devs is using Free BSD so new breakage might pop up over time.

I'm trying to be prepared to update my FreeBSD port for the next stable version, so there's no "mach build" or "mach configure", instead I'm using a port build process leaned on the Firefox port already available in FreeBSD: It uses "gmake -f client.mk" directly (after creating a mozconfig file). I need to build a whole port, and not just an executable (a "port" means you type in "make install", and all dependencies are solved, FreeBSD specific patches are applied, you'll get the source donwloaded and compiled, a package will be build and installed on your machine - and that package takes care that you f.e. don't deinstall a needed other packages, you can use it for a package repository etc.).

I found out that even "mach configure" fails ("Could not find gconf-2.0"), while starting up my ports build process until it crashes, and then going on with with "mach build" works. And so I was able to take a look inside the missed file ".mozconfig-client-mk". So I need to find out which step creates that file; There must be something before ".mozconfig-client-mk" is not found.

Before anyone else spends time on this: I myself has the invest some more time on this topic.

BTW: https://forums.freebsd.org/threads/disaster-strikes-seamonkey-removed-from-ports-tree.71335/ resulted in my port: https://jmos.net/software/freebsd.rvt - so you can see there are some people wanting SeaMonkey on FreeBSD (also in the german BSD forum, the official mailing list etc.). The stable version works perfect on FreeBSD.

…so I decided to switch over to a "mach" based build process, and finally I got SeaMonkey back compiled by the ports build process. But now the problem is to set up a file list to pack into the package: My compiled SeaMonkey is in "obj-x86_64-unknown-freebsd13.0/dist/bin/", that's all I need to add to my package. But: How do I get the folder name "obj-x86_64-unknown-freebsd13.0"? I assume "dist/bin" to be hardcoded, but "obj-x86_64-unknown-freebsd13.0" is dynamically… Or can I assume that "obj-*/dist/bin/" would do the trick as there's always just one "obj-" directory?

Finally made it - got a working FreeBSD port & package from SeaMonkey 2.53.8b1 :) I'm now using "obj-*/dist/bin/" to identify the builded files, and so far it seems to works (writing this with that build).

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
OS: Unspecified → FreeBSD
Hardware: Unspecified → x86_64
Resolution: --- → INVALID

Great. If you have problems you can also ask on ircs://libera.chat/seamonkey-dev
Some Linux distribution maintainers there too which might have run into this before.

As for the object dir. Don't you specify it in the mozconfig file?
My linux CentOS 7 config e.g. has
mk_add_options MOZ_OBJDIR=/mnt/linuxdata/seabuild/release/comm-release56cl/x86_64-pc-linux-gnu

You need to log in before you can comment on or make changes to this bug.