reproduce-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[task #15686] Removing original software URLs from Maneage?


From: Mohammad Akhlaghi
Subject: [task #15686] Removing original software URLs from Maneage?
Date: Thu, 25 Jun 2020 22:17:59 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0

Follow-up Comment #15, task #15686 (project reproduce):

Great! Thanks a lot for the checks Raul! 

Thanks also for the nice catch on the incorrect removal of the backslash! I
have pushed your commit over mine in that branch, so it will be rebased in the
final commit later ;-).

About ATLAS, I just defined bug #58655. Let's continue this discussion there.
But just one thing, by "it actually got installed", do you mean that you have
'.local/version-info/proglib/atlas'? If so, then there is actually no problem!
Because as I later found in that bug, all those errors have been ignored!

After ATLAS, apparently three software failed: 'boost', 'libtirpc' and
'rpcsvc-proto'. 

* I searched for the problem in Boost and found that it was a known issue
<https://lists.boost.org/Archives/boost/2019/11/247380.php> in November 2019.
I then noticed that the most recent version came just about two months ago
<https://www.boost.org/users/history/version_1_73_0.html>. So can you please
try updating the version number to 1.73.0 to see if this particular problem is
already fixed? You can just uncomment the "boost-url" variable in the new
'urls.conf'.

* About the 'libtirpc' errors, they all seem to be related to the  pthreads
library.

* About the 'rpcsvc-proto' problem, it seems to be related to Gettext's
internationalization library, in particular the lines below. You should have a
'.local/lib/libintl*' since we now install Gettext on macOS. So as a test, can
you try adding '-lintl' to the LDFLAGS before building rpcsvc-proto? This
line: 'export LDFLAGS="-lintl $$LDFLAGS"'


Undefined symbols for architecture x86_64:
  "_libintl_gettext", referenced from:
      _main in rpc_main.o
      _usage in rpc_main.o
      _checkfiles in rpc_main.o
      _c_output in rpc_main.o
      _h_output in rpc_main.o
      _l_output in rpc_main.o
      _s_output in rpc_main.o
      ...
  "_libintl_setlocale", referenced from:
      _main in rpc_main.o
  "_libintl_textdomain", referenced from:
      _main in rpc_main.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)


If these proposals don't fix the problem, can you define new bugs for these
software on macOS? Since no one needs them seriously now, we can leave the
bugs open until we either randomly find a solution or someone is motivated
enough to look into them ;-).

Generally, to (temporarily) remove a package from '--all-highlevel', you can
simply comment the "atlast-version" line in 'versions.conf'). But this just
lead me to an idea: Since such known problems can be very annoying in a
general check (with '--all-highlevel'), one option is to add an automatic step
to remove such known problematic software (for specific OSs, citing the
particular bug) from the list of packages that are installed with
'--all-highlevel'. 

What do you think? 

    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/task/?15686>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]