bug#45433: 28.0.50; byte/native-compiling ivy and ox-publish possibly miscompiled

[Mauricio Collares]

Andrea Corallo <akrl@sdf.org> writes:
>
> Hi Mauricio,
>
> I had a look, this issue is not native compiler related as I get the
> same behavior byte compiling.
>
> The trouble seems with `ivy-add-face-text-property' being defaliased,
> ATM I'm not sure what is going on tho.
>
>   Andrea

Hi Andrea,

I appreciate you taking a look at this and I apologise for being
insistent, but I am curious to isolate what's causing the difference of
behaviour here. Here's the exact set of steps I am following. In
~/test.el, I have these four lines:

(setq comp-deferred-compilation nil)
(add-to-list 'load-path "/home/collares")
(setq comp-eln-load-path '("/home/collares/"))
(require 'ivy)

I also have ivy's elisp files in my home directory (colir.el,
ivy-autoloads.el, ivy.el, ivy-faces.el, ivy-overlay.el,
ivy-pkg.el). With this, I get the following output:

$ emacs -Q --batch --eval "(add-to-list 'load-path \"/home/collares\")" --eval 
"(setq comp-eln-load-path '(\"/home/collares/\"))" -f batch-byte-compile 
~/ivy.el                                                                        
      
$ emacs -Q --script ~/test.el

$ emacs -Q --batch --eval "(add-to-list 'load-path \"/home/collares\")" --eval 
"(setq comp-eln-load-path '(\"/home/collares/\"))" -f batch-native-compile 
~/ivy.el                                                                        
    
$ emacs -Q --script ~/test.el
Debugger entered--Lisp error: (void-variable fboundp)
  byte-code("\300\301\302\303!\203\f\0\303\202\n\0\304\305#\207" [defalias 
ivy--file-local-name fboundp file-local-name #f(compiled-function (file) 
#<bytecode 0x163b76c1ebc309bd>) "Compatibility shim for `file-local-name'.\nThe 
func..."] 4)
  require(ivy)
  eval-buffer(#<buffer  *load*> nil "/home/collares/test.el" nil t)  ; Reading 
at buffer position 286
  load-with-code-conversion("/home/collares/test.el" "/home/collares/test.el" 
nil t)
  command-line-1(("-scriptload" "/home/collares/test.el"))
  command-line()
  normal-top-level()

Do you know what could be causing this difference in behaviour? I would
be happy to provide any debug information that's helpful.

Best,
Mauricio