Jump to content
IGNORED

RMAC/RLN


Orion_

Recommended Posts

  • 2 months later...

Just a heads up, the git repos for rmac and rln seem to have been down for hours, and the gitlab mirrors:

 

https://gitlab.com/ggnkua/rmac-mirror

https://gitlab.com/ggnkua/rln-mirror

 

Seem woefully out of date. Pointed out by a user trying to build my SDK, which fetches the rmac and rln repos as git submodules.

  • Like 1
Link to comment
Share on other sites

Hi,

16 hours ago, cubanismo said:

Just a heads up, the git repos for rmac and rln seem to have been down for hours

@Shamus pinged, I'm sure we'll have everything back to normal in a bit.

16 hours ago, cubanismo said:

 

and the gitlab mirrors:

 

https://gitlab.com/ggnkua/rmac-mirror

https://gitlab.com/ggnkua/rln-mirror

 

Seem woefully out of date. Pointed out by a user trying to build my SDK, which fetches the rmac and rln repos as git submodules.

Aw c'mon, it's only 2 releases behind ;). But thanks for letting me know, gitlab was kind enough to upgrade its UI and wipe all the auto mirroring I've set up for both repositories. I've re-added the mirror hooks, but we'll have to wait till the server is up again.

In the meantime, if it's not a huge convenience for your lovely user, the rmac/rln homepage has statically linked binaries for Windows/Mac(x86 and M1)/Linux(x64). I hope that's a valid alternative until we get things back to normal.

 

And apologies for the downtime!

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Agreed, thanks for all the work, it's much appreciated. Just bringing issues to your attention in case you guys weren't aware of them.

 

For advanced users like myself, yes, I know how to edit scripts and do a little git heroics to drop in the Linux binaries when setting up the SDK environment, but for average users, the source repositories being down breaks things right at the initial "git clone" step of SDK setup, because rmac and rln are included as submodules that get recursively cloned if you're following the instructions in the README.md.

  • Like 3
Link to comment
Share on other sites

A small update on this:

 

So far I haven't been able to get in touch with @Shamus so I can't do much on that front. At least I have pushed what I believe are the latest commits for both rmac and rln on the gitlab mirrors. So if anyone wants to build from source, the gitlab repos are the "official" ones for now. (Of course there are also the prebuilt binaries on the official website)

 

That is all for now.

 

[Edit] I have also set up some contigency repos at the website, so you can "git clone http://rmac.is-slick.com/git/rmac" and "git clone http://rmac.is-slick.com/git/rln" respectively.

Edited by ggn
  • Like 3
  • Thanks 1
Link to comment
Share on other sites

gitlab will *never* be the official repos; at least as long as I'm still alive.  ;)  Seems that my ISP is fucking around with my IP (which has been stable for the last umpteen years or so).  So I'll be keeping a closer eye on it until I can get figure out what my ISP is doing and keeping the DNS updated.  BTW, the DNS has been updated, and the repos should be reachable now.  :)

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

  • 6 months later...
1 hour ago, ggn said:

Small update, since there have been outages at the official repo addresses, I have gone and set up a mirror here: http://tiddly.mooo.com:5000/explore/repos, so hopefully there will be some redundancy! (also announced in the official page) 

Thank you @ggn for taking the time to make sure this repository maintained and is available! It means allot to me and I'm sure to the rest of us that rely on these tools.

  • Like 2
Link to comment
Share on other sites

  • 3 months later...

Hi. Apologies if this is the wrong place to ask. Is it possible to get rln to output an object file which it can then take as input later in the build process? If so, what's the command line incantation please? None of the switches listed through -h seem relevant and trying multiple combinations have not produced anything which the later rln has liked (or I keep meeting the "TO DO: Relocatable linking" message). Using v1.7.4.

 

For my particular use case the archive would be built from .o files containing data only (no code) and incbin'd (-ii) data.

 

This thread mentions rln supporting .a archive files, but it's unclear whether that's as producer or consumer.

 

Thanks.

Link to comment
Share on other sites

Hmm, and archive is something different from an intermediate link.

Files in an archive are the same as before and intermediate link will combine the different .o files into a single one which can't be split later.

 

What kind of symbols do you need? Only the start of eachs data chunk? Do you have dependecies from outside?

Link to comment
Share on other sites

35 minutes ago, 42bs said:

What kind of symbols do you need? Only the start of eachs data chunk? Do you have dependecies from outside?

Yes, just the symbols for the start of each data chunk should be sufficient. And no external dependencies.

 

For context, I'm playing with Atari's 3D example code, via the Docker version of the jaguar-sdk. The (lack of) file organisation annoys me, so I've rearranged things, moving each model into its own directory. It's these files (models compiled to .o and optional .cry textures) which I'd like to combine and pass to the final link stage, one file per model directory.

 

Thinking about it, I might be better using ar to build an archive. I'll give that a try and see if it works.

Link to comment
Share on other sites

43 minutes ago, 42bs said:

why not just make a "assets.S" file and .incbin the data?

Yes, I think that's going to be the most compatible answer. (The alternative would be to patch rln to include the non-.o parts of archives, using the same method as when it includes other binaries. I might still do that, but it's getting further away from what I'm actually trying to do...)

 

Thanks for your help!

Link to comment
Share on other sites

Hello,

 

I guess everything is resolved now (thanks to @42bs for the quick response!) but just to be perfectly clear: rln is a linker, it produces only binaties as output. Yes, it can parse .a libraries (aout format only) and pick the .o files it needs from them.

 

Also, it's not an issue if you want to pass everything as an .o file or as an .a - it's all a matter of how you want to organise your data.

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

We just released rmac 2.2.24! Head over to http://rmac.is-slick.com/index.html#rmac-2-2-24 for the goods.

 

List of changes since last release:

  • Minor fix for .incbin
  • Removed the external dependency for dirent.h on Windows
  • If ^^filesize could not open the requested file, it would show “(null)” as the filename
  • 680x0 parser would fail with “reached end of line while parsing expression” in certain conditions
  • Improved the handling of calculating expressions with labels in different sections
  • Fixed various 56k illegal combinations of parallel moves
  • Added hex value parsing for -Dsymbol=value command line command
  • 56k short immediate value was not clamped, so negatives would corrupt the opcode. Thanks to Steven Tattersall for the report and fix
  • Added a check for number of parameters in a dcb directive

 

And two announcements:

  1. Starting with this release, the mirror repositories that were announced in the previous post are now the main. The ones used up to this point are now considered out of date and have code up until v2.2.15. We hope to rectify this in the near future, but for now please update your bookmarks and scripts.
  2. Also first for this release is aarch64 builds (for example: Raspberry Pi 5) provided

Happy coding!

  • Like 6
  • Thanks 1
Link to comment
Share on other sites

@ggn Just two notes:
* (c) year does not need to be updated unless someone new comes to the party (for example token.h)

 This makes merging a pain, as it looks like every file differs.

* compiling throws a lot of warning because of using "%lx" instead of "%llx" for 64 values when compiling on AArch64 Mac with Clang

 

Besides this: Great work.

Edited by 42bs
  • Like 1
Link to comment
Share on other sites

4 hours ago, 42bs said:

@ggn Just two notes:
* (c) year does not need to be updated unless someone new comes to the party (for example token.h)

 This makes merging a pain, as it looks like every file differs.

* compiling throws a lot of warning because of using "%lx" instead of "%llx" for 64 values when compiling on AArch64 Mac with Clang

 

Besides this: Great work.

"The compiler throws warnings when it wants to tell you that you're doing a good job!" -- A friend who wishes to remain anonymous.

 

But seriously, every compiler on every system has different sensitivities when it comes to warnings, so my Visual Studio is mostly silent, and then check out what happens when I build the different targets:

- Alpine Linux: https://github.com/ggnkua/rmac-builder/actions/runs/9909857765/job/27378896652#step:3:33

- Ubuntu aarch64: https://github.com/ggnkua/rmac-builder/actions/runs/9909857765/job/27378897277#step:3:1454

- Visual Studio 2019: https://github.com/ggnkua/rmac-builder/actions/runs/9909857764/job/27378896605#step:4:132

- MinGW: https://github.com/ggnkua/rmac-builder/actions/runs/9909857763/job/27378896836#step:3:27 (practically warning free)

- MacOSX 12: https://github.com/ggnkua/rmac-builder/actions/runs/9909857761/job/27378896619#step:2:28

 

I honestly don't know how serious to take this to be honest. I might have a round of fixing all of them, but then again all these casts or whatever can make the code look bloated and hard to understand. So I'll think about it.

 

As for the year bump - did you get merge conflicts? That's strange. If your fork contains changes that could be added back to our repo maybe send us the changes so we can incorporate them?

Link to comment
Share on other sites

Currently my fork contains only fixes for warnings and in the makefile some -Wno-  🙂 where I stopped adding castings:

 

CFLAGS+= -Wno-pointer-sign -Wno-deprecated-non-prototype

 

As for the (c) year, I just ran a "sed -i s/2021/2024/" on all sources in my repo ;-) and then made a diff.

 

 

 

 

Link to comment
Share on other sites

9 hours ago, 42bs said:

* (c) year does not need to be updated unless someone new comes to the party (for example token.h)

In fact, I've heard from lawyer types the copyright year on individual files should only be updated when they have changed "substantially," where substantially is open to interpretation, but generally means something more invasive than whitespace fixes, propagating variable renaming, etc. should correspond to some functional change. Otherwise, someone could theoretically challenge your copyright claim.

 

This contradicts many repository's stupid naive copyright-update CI checks, unfortunately.

Link to comment
Share on other sites

On 7/13/2024 at 3:38 PM, cubanismo said:

In fact, I've heard from lawyer types the copyright year on individual files should only be updated when they have changed "substantially," where substantially is open to interpretation, but generally means something more invasive than whitespace fixes, propagating variable renaming, etc. should correspond to some functional change. Otherwise, someone could theoretically challenge your copyright claim.

 

This contradicts many repository's stupid naive copyright-update CI checks, unfortunately.

Sounds like rubbish to me. You are not even required to include a copyright statement, copyright is simply granted at the creation of something. So the idea it could be challenged merely by an accompanying informal message being incorrect is highly dubious.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...