Synth: Introducing new custom package repository builder for FreeBSD and DragonFly

loki2012 said:
Thanks Marino. As I said, python used to compile fine with synth on my system.
Click to expand...

This fact could not be more irrelevant.
edited: sorry, I misread it thinking you were still saying it built fine outside of synth.

Shared object "libintl.so.8" not found, required by "conftest"
Click to expand...

That's the problem.

What could I try?
Click to expand...

I would try deleting all packages in the synth package directory and rebuild everything.
added: and when you install it, use pkg update -f to force reinstallation of everything.
 
So I tried to delete all the packages in the synth package directory, and also rebuild everything in synth, and still get the same issue and error message. I then tried to uninstall all packages, delete again all packages in the synth package directory, start from scratch with a new /usr/local directory, and installed synth with pkg, then I upgrade synth with synth and now trying again to build python still leads to the same issue. I guess at some point I will have to reinstall the system from scratch, which I would like to avoid.
 
Loki, you don't have the "download from official packages if available" option set do you?
Are you sure you're building *everything* from scratch?

Another question, is your system is some kind of weird state, like a partial upgrade from an earlier release?
 
Hi,

I also started getting failures from a few packages:

ftp/curl with
“
checking run-time libs availability... failed
configure: error: one or more libs available at link-time are not available run-time. Libs used at link-time: -lnghttp2 -lssl -lcrypto -L/usr/lib -lgssapi -lgssapi_krb5 -lheimntlm -lkrb5 -lhx509 -lcom_err -lcrypto -lasn1 -lwind -lheimbase -lroken -lcrypt -pthread -lz -lkrb5 -lgssapi -lgssapi_krb5 -lkrb5 -lgssapi -lgssapi_krb5 -L/usr/local/lib
“

security/sudo, lang/python27 and lang/python36 with
“
checking whether we are cross compiling... configure: error: in `/construction/xports/lang/python27/work/Python-2.7.15':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
“

The environment: Server with FreeBSD on metal, months ago synth built all tools including virtualbox without any hiccup. The learning, testing and writing of documentation happens in FreeBSD VMs so I can start from scratch and branch at will.

The setup:
FreeBSD 11.1-RELEASE
ZFS (I do not care about data loss in these VMs, I want to learn/document setup- and maintenance steps for using it on the final metal)
portsnap auto
svnlite checkout https://svn.freebsd.org/base/release/11.1.0/ /usr/src/
freebsd-update fetch&install
Make ccache (the fails also happen without)
Make synth
Synth configured with defaults (except ccache when installed)
synth status/prepare-system/upgrade-system

Many other ports build without problems.

If memory servers correct, these builds inside VMs worked during the last weeks, but I can’t pin it on something that changed.
I can’t believe that it’s a general problem, as John already pointed out. But seeing Loki’s message, I feel good that it’s not something that only I fritzed up.

I test with setenv ENTERAFTER stage, and I also see libintl.so.8 ‘missing’ messages in config.log. But why only for these ports?
Inside the interactive mode, I see the file:
# ls -l /usr/local/lib/libintl.so.8.1.5
-rw-r--r-- 1 root wheel 55114 May 22 11:58 /usr/local/lib/libintl.so.8.1.5

Right before the libintl message, I also see the following:
“
configure:3486: cc -V >&5
cc: error: argument to '-V' is missing (expected 1 value)
cc: error: no input files
configure:3497: $? = 1
configure:3486: cc -qversion >&5
cc: error: unknown argument: '-qversion'
cc: error: no input files
“

I don’t know if this is “bad things” or to be expected.

As this is a built from scratch, the hints with deleting, rebuilding or partial upgrades seem moot to me.

By now I’m a little bit out of my league. To my (freebsd-)untrained eye, it looks like somethings is wrong with a library path or so, but why would other ports build flawlessly?
What information should I gather to point me in the right direction?

Thanks a lot
And
Best regards

Simon

PS: renamed config.log so it is accepted by the uploader
 

Attachments

Since this is the 3rd report on python (caused by missing libintl.so.8) I would say somebody broke the ports tree but it only affects freebsd.
For some reason, people seem to blame synth whenever the ports tree get broken.
In other words, none of this are synth bugs.
The person that last changed gettext a few days should definitely be involved via email or bug report.
 
I booted in FreeBSD 11.1 and was able to build python36 without issue. Gettext was built correctly.
Somebody is going to have to break into the build (e.g. env ENTERAFTER=stage synth test lang/python36 or env ENTERAFTER=install synth test devel/gettext-devel) and go over and inspect libintl.so. Look at symlinks, look at readelf -a (e.g. Library soname) and see why python configure script is failing.

It's working for me. I can't reproduce any of this on freebsd hardware.


added: Are you guys on FreeBSD 12.0-CURRENT? If so, I would suspect a bleeding edge bug in the rtld.
 
Hello John,
Not blaming synth (sorry if it came across like that), but working the onion from the outside. First I have to figure out how to parse synth output to find out where to look next.
And I'm back to square one because the last change I see in gettext would be from 2016. And python27 from 2017. While I absolutely agree with you, I have no clue about what to do next.
But I also do not expect you to lecture me, I'll just wait by the sidelines and see how this develops. Perhaps someone will post back here so 'we' know in the future how to chase synth error messages and catch the real culprit.

Grabbing the popcorn
simon

PS:
Someone found a bug in ftp/curl that looks familiar, but they claim that dns/libpsl is to blame. I would read the error message differently as gettext being the bad guy, but that's just me.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227909
 
That bug report says "rebuild all packages" which was the very first thing I suggested.
But to confirm, you are not on FreeBSD 12.0 ?
Oh, you're right on gettext. I thought it was updated 2 weeks ago, but it was 2016.

added: if rebuilding all packages is needed, it means somebody failed to bump downstream libraries when a dep library was updated. It's a maintainer error.
added2: we posted at same time, did you see the comment before?
 
So I have some finding now.
The building of python started to fail after I switch from libressl back to openssl by commenting this line in my /usr/local/etc/synth/LiveSystem-make.conf
Code: 
#DEFAULT_VERSIONS+= ssl=libressl
So with this line commented, python27 doesn't build. If I uncomment this line, libressl is being built and python is building as well.

The reason why I tried to come back to openssl rather than libressl was because since the update to libressl 2.7, py-cryptography is not building any more and apparantly it is a known bug.
I am under Freebsd 11.1
 
loki2012@, with a change like that, you have to remove all packages from synth package directory and rebuild everything. You also cannot have configuration item [N] Fetch prebuilt packages set to "true".

Check your configuration and make sure [N] is set to false, and remove *ALL* packages from the directory indicated by [ B ] packages directory.
I built python just fine with default settings, which is openssl.
 
root@zfs-default:~ # freebsd-version
11.1-RELEASE

No 12 here ;-)

John, I'll try the enterafter digging tomorrow at the office, let's see how far I get. Perhaps I'll shove another SSD into the server and do a vanilla install there to rule out virtualisation (with thorough protocol to enable replay by other parties).

Loki, can you build security/sudo and ftp/curl without errors? Perhaps better to tackle it with a 'lesser' tool than python...
 
Zirias said:
And in the corresponding PR, there's a patch attached -- worked fine for me, so, no reason to switch back to openssl.
Click to expand...
Thanks for that, indeed that works.

marino said:
loki2012@, with a change like that, you have to remove all packages from synth package directory and rebuild everything. You also cannot have configuration item [N] Fetch prebuilt packages set to "true".

Check your configuration and make sure [N] is set to false, and remove *ALL* packages from the directory indicated by [ B ] packages directory.
I built python just fine with default settings, which is openssl.
Click to expand...
I did as you suggested. [N] was always set to false since the begining. But the issue was still there. Using libressl instead of openssl, python is building but l had issues building other ports, such as glib20, postfix (once I sorted-out the py-cryptography issue). So I guess something is still wrong with my system. I will go on trying to understand what could be wrong, but I don't remember having a special setup. Just a 11.1-RELEASE updated from previous releases, and the issues appeared a few months after I upgraded to 11.1. I will post if I can find what was the issue. Thanks for you help Marino anyway, I learned a few things in the process.
 
Could you please add a changelog to your GitHub repo so we know what's been updated?

It's hard to tell what's new in 2.05 by looking at the code.
 
I am happy to report that my issues are gone with synth-2.05. Looking at GitHub there was probably some patch on the way ldconfig was called in the jail, in order to address a recent change in the Makefile in ports, if I read it correctly.
 
Does synth's action 'upgrade-system' respect 'pkg lock's?
I locked my firefox-esr, but I fear that synth upgrade-system will update it anyways.
 
"upgrade-system" just calls the pkg command, so yes, it has to respect locks.
(the use of locks is another topic entirely. be prepared for issues because of it)
 
marino said:
"upgrade-system" just calls the pkg command, so yes, it has to respect locks.
(the use of locks is another topic entirely. be prepared for issues because of it)
Click to expand...
Thanks for the answer.
Could you name those issues, please?
It's just I'm on the edge with FreeBSD already and if it will update firefox-esr irregardless of my wish not to do so - I'll just finally end my experience with FreeBSD for good.
 
it's an unreasonable expectation. If you use binary packages, those packages are going to update from time to time. All the dependencies will update. If you lock a package but allow everything else to update, the library linkages will get broken. Basically locking doesn't really work, certainly not like a newbie user might expect.

Somebody that wants to freeze package versions needs to build from source. They either freeze the entire source tree at some point, or they manually keep a port at a specific version and use poudriere/synth to keep the local package repository working together.
 
You must log in or register to reply here.
Back
Top